Net

背景 有需要要对vxlan的流量做过滤，只允许特定vxlan id的流量访问。 方案调研 通过iptables支持各种策略过滤，但是并没原生的任何插件可以直接支持vxlan报文过滤。后来就想到了2个方案 U32模块本身支持取报文的特定字段做匹配，因此就想到了使用U32。 现在7U的服务器上的iptables是支持bpf的，可以支持使用’-m bpf –bytecode’ 添加编译好的字节码做过滤。 但实际上使用bpf需要单独弄一个工具去生成这个二进制的代码，长期的维护性不是太好，所以虽然最终2个方案都走通了 还是支持选了u32. 我们都知道一个IP报文 里 IP 头是20字节，TCP是20字节，UDP是8个字节，VXLAN是8字节。vxlan的包头如下 ，VXLAN报文本身是封装在UDP报文内，因此一个针对vxlan报文简单的U32匹配可以按下面的逻辑来生产 20 ip+ 8 UDP + 1 VXLAN flags +3 Reserved =32的位置就是VNID左边，因此下面的表达式就可刚好是VNID的区域 -p udp -m udp -m u32 –u32 “32»8=xxxx” 考虑到可能IP头有option，因此也有一个改进的版本 –u32 “0»22&0x3C@12»8=xxx” 详细的原因可以参考：https://netfi lter.org/documentation/HOWTO/netfi lter-extensions-HOWTO-3.html 2. https://ask.wireshark.org/question/10372/sniffi ng-vxlan-traffi c/ 3. https://support.huawei.com/enterprise/en/doc/EDOC1100004365/f95c6e68/vxlan-packet-format 4. https://man7.org/linux/man-pages/man8/iptables-extensions.8.html 5. https://netfi lter.org/documentation/HOWTO/netfi lter-extensions-HOWTO-3.html

以下图为例 R1 配置 在R1给R2发送路由时，把6.6.6.0/24去掉。对应的配置为 log file /var/log/quagga/bgpd.log password bgp router bgp 65001 distance bgp 250 200 150 bgp router-id 10.10.0.22 neighbor 10.10.0.23 remote-as 65010 neighbor 10.10.0.23 password DOCKER neighbor 10.10.0.23 ebgp-multihop neighbor 10.10.0.23 prefix-list r1-out out neighbor 10.10.0.23 next-hop-self redistribute connected metric 121 access-list all permit any ip prefix-list r1-out seq 5 permit 4.4.4.0/24 ip prefix-list r1-out seq 6 permit 5.5.5.0/24 !ip prefix-list r1-out seq 10 permit 6.6.6.0/24 ip prefix-list r1-out seq 11 permit 8.8.8.0/24 ```bash ip prefix-list r1-out seq 15 permit 100.100.100.0/23 ge 24 le 32 ip prefix-list r1-out seq 25 permit 10.0.0.0/8 ip prefix-list r1-out seq 50 deny any 可以看到R1给R2发送的路由中把本地的 6.6.6.6去掉了 094846cab3a9# show ip bgp neighbors 10.10.0.23 advertised-routes ...

有几个场景需要使用BGP Looking Glass。1. 确认某个区域/ISP的用户访问自己的服务时走的路线。2. 在使用自己的BGP网络对外宣告地址时，需要看看自己的ISP是否真的接受了对应的路由。 目前国外主流的Tier1 /Tier2都提供了Looking Glass可以查看路由。网上有整理好的looking glass列表 http://www.bgplookingglass.com/。 以Level 3的为例，可以打开http://lg.level3.net/bgp/lg_bgp_main.php。 输入自己要看的网段后即可看到

前面有多次介绍Anycast的相关内容。这几年伴随每次cloudflare被大规模DDOS，Anycast被越来越多的人关注。根据cloudflare的blog和公开的PPT，大致可以猜出其CDN的部署模式是下图因为Cloudflare单个节点基本都在300G以上，全球就几十个节点。因此一般几百G的DDOS在网络层对Cloudflare无法构成威胁。cloudflare的风险点主要还是应用层的防护性能。部署TCP的anycast时，需要注意的点：1. 交换机的hash规则配置，节点内单个机器维护时hash结果会变，会引起闪断。这对于一般的HTTP服务影响不大，但是如果想改善体验，可以在应用服务器上同步好TCP session。2. 隐藏自己的网络接口地址，不然traceroute找到中间网络接口地址，攻击者攻击中间链路是没法阻止的。3. 各服务使用独立的anycast 地址，各服务异常时不会相互影响，服务异常时能自动撤销路由，但是注意得设置好quota，不热一些异常可能导致所有节点的路由都撤销了。4. 确保global节点的具备足够的接入带宽，某些区域性的攻击过大，如果global节点能抗住可以把流量攻击引入到global节点处理。

接着上一篇文章中的图要想IBGP内各路由器内都有完整的路由信息，可以做的方案：1. 做full mesh，也就是改一下R1/R2的配置，将对方做peer。2. 将R3设置为路由反射器（Route-Reflector）3. 使用BGP联盟，把内部各路由器划到不同分子AS。 路由反射的配置比较简单，R1/R2的配置不变，R3的配置只需要添加一行 log file /var/log/quagga/zebra.log log file /var/log/quagga/bgpd.log ! password bgp ! interface eth0 ipv6 nd suppress-ra link-detect ! interface eth1 ipv6 nd suppress-ra no link-detect ! interface lo no link-detect ! router bgp 65000 bgp router-id 10.1.0.4 redistribute connected metric 121 neighbor IBGP peer-group neighbor IBGP remote-as 65000 neighbor IBGP password DOCKER neighbor IBGP route-reflector-client neighbor 10.1.0.2 remote-as 65001 neighbor 10.1.0.2 password DOCKER neighbor 10.1.0.2 ebgp-multihop 255 neighbor 10.1.0.3 peer-group IBGP neighbor 10.1.0.5 peer-group IBGP distance bgp 250 200 150 exit ! access-list all permit any ! ip forwarding ipv6 forwarding ! line vty ! end ...

BGP相对OSPF来说在骨干网络上使用的比较多，是目前域间路由协议的事实标准。通常在服务器上直接使用BGP的场景不多（内部网络大家都倾向使用OSPF这类IGP）。其实BGP的配置也很简单，从以下的拓扑来看4个机器的BGP配置 各路由配置文件 R1 配置 ! log file /var/log/quagga/zebra.log log file /var/log/quagga/bgpd.log ! password bgp ! interface eth0 ipv6 nd suppress-ra link-detect ! interface eth1 ipv6 nd suppress-ra no link-detect ! interface lo no link-detect ! interface tunl0 ipv6 nd suppress-ra no link-detect ! router bgp 65000 bgp router-id 10.1.0.5 redistribute connected metric 121 neighbor 10.1.0.4 remote-as 65000 neighbor 10.1.0.4 password DOCKER neighbor 10.1.0.4 next-hop-self distance bgp 250 200 150 exit ! access-list all permit any ! ip forwarding ipv6 forwarding ! line vty ! end ...

Anycast在国内应用现状 Anycast本身是个古老的技术，但是在国内互联网公司内都使用的不多。其原因如下：1. 普通的互联网服务的高可用可以通过DNS层切换，业务恢复时间最短可以控制在5分钟内，满足国内绝大部分企业的需求了。2. Anycast实施的网络接入要求比较高，国内企业具备有自己BGP网络的屈指可数。在公有云业务发展起来之前，国内大规模使用BGP网络为主营业务提供服务除了阿里之外别无二家,鹅厂和熊厂长期以来还是用智能DNS配合多线机房的静态带宽来提供服务。究其原因主要还是BGP带宽的成本比较高，中小企业根本没有人力与财力与大运营商在多个城市做BGP接入。 anycast在国外的应用其实在几年前也不多，主要的应用范围还是在DNS这类使用UDP的无状态的业务上。因此之前国外使用Anycast的场景主要是以下几种：1. 各厂商承建的13组 ROOT DNS server。2. 各DNS GTLD Server。3. 国外的互联网巨头（Google，facebook，MS,Akamai,Amazon）的DNS server4. 国外流行的DNS服务厂商，比如NSone,DYN之类的5. 国外的新兴CDN厂商（微软Azure、Cloudflare、MaxCDN等）的Cache server。 国内使用anycast的主要场景:1. BAT的这类有数十个IDC以上的公司的内部基础服务。2. 各运营商内部的DNS的跨城部署（绝大部分是各省份内部） 总结一下，之前绝大部分anycast都是用在UDP的业务，少量CDN公司的Cache 节点使用了Anycast。 TCP业务的Anycast实施难点 从anycast的RFC内可以看到，只推荐使用anycast应用在无状态的业务上。对于HTTP之类的使用TCP的业务都不推荐部署。主要是在IP报文在被路由转发时，当存在ECMP（等价路由）的时候只是机械的按每个IP包随机丢到多个下一跳中的一跳，可能导致TCP连接都无法建立。一般情况下公网上的路由，只有宣告方触发或者中途链路异常时才会做变化，对于常规的非长连接业务其实都是无影响的。 TCP 业务实施Anycast的关键因素 这两年，随着移动业务的快速发展，各手机APP都在不断优化自己的使用体验。因为国内之前长期大量移动网络用户还停留在2/3G网络，无线业务的网络条件查，通过传统的DNS查询几十个域名对用户体验影响巨大。慢慢地大家开都搞起了HTTPDNS，绕过ISP的DNS，走HTTP批量做域名的查询。然后大家又发现鸡生蛋 蛋生鸡的问题出来了，HTTPDNS自己的访问绕不过DNS。因此这两年腾讯、阿里云提供的HTTPDNS又开始把服务地址改成Anycast地址了。这也算是国内第一批有状态业务的Anycast部署。TCP业务部署Anycast的参考几方面：1. 自己是否具备BGP网络。2. 自己使用真的有那么高的业务要求、或者是不想走DNS。3. 多点宣告后广域网内各地是否稳定优选到”就近点“（一般情况下BGP路由在各地优选是固定就行）。4. 接入层的交换机能支持一致性hash(一般是根据源IP/源端口/目标IP/目标端口/协议做hash，目前入门的3层交换机都支持)。5. 单个业务的request/response时间，一般HTTP请求的业务都是适用的，相反一些push类的长连接业务不适用。6. 各区域是否在大部分时候路由到固定节点，这块有论文做过研究，大部分anycast CDN的路由在几个月维护时才动一次，然后恢复原状。

使用calico的ipam dirver创建网络 如果使用docker默认的ipam创建calico网络，则不支持访问策略控制。1. 创建pool 创建network 更新profile增加2个互相访问 创建容器测试 1. 使用vnet1/vnet2分别创建2个容器docker run --name vnet1 -d --net vnet1 acs-reg.sqa.alipay.net/min.peng/minios /sbin/initdocker run --name vnet2 -d --net vnet2 acs-reg.sqa.alipay.net/min.peng/minios /sbin/init 说明 1. 可以直接使用默认的docker的ipam-driver 创建网段，但是那样就没法做策略了,且nat-outgoing和ipip的选项实际是全开的。比如docker network create --driver calico --opt nat-outgoing=true --opt ipip=false --subnet=10.20.0.0/22 vnet1docker network create --driver calico --opt nat-outgoing=true --opt ipip=false --subnet=10.30.0.0/22 vnet2 使用了ipam-driver calico的话，内部的服务没法对外暴露端口。。但是nat-outgoing和ipip的配置是生效， 3. 参考文档http://docs.projectcalico.org/v1.5/getting-started/docker/tutorials/basic

公司内有1个巨老的系统，一直访问着我们提供的老API。当我们的API升级后因为新接手这个老系统的人都没法去升级调用API的接口。因为自己这边负责的API回滚的代价太大，临时在老的服务器上换了1个端口把老的API启动起来。并提供了1个iptables供对方服务器重定向访问的端口。源ip：10.1.1.1API IP：192.168.1.1API port: 8888API port(run old api):2222 iptables -t nat -A OUTPUT -p tcp -d 192.168.1.1 --dport 8888-j DNAT --to-destination 192.168.1.1:22222 让对方在服务器上添加以上的规则，可以让对方机器访问192.168.1.1:8888的请求被重定向到192.168.1.1:22222

前段时间为了测试bind递归时的SRTT算法效果,使用netem模拟了一下到几个NS的任意延迟.简单的脚本如下 tc qdisc add dev eth1 handle 1: root htb tc class add dev eth1 parent 1: classid 1:1 htb rate 100Mbps quantum 40000 tc class add dev eth1 parent 1:1 classid 1:11 htb rate 100Mbps quantum 40000 tc class add dev eth1 parent 1:1 classid 1:12 htb rate 100Mbps quantum 40000 tc class add dev eth1 parent 1:1 classid 1:13 htb rate 100Mbps quantum 40000 tc class add dev eth1 parent 1:1 classid 1:14 htb rate 100Mbps quantum 40000 tc qdisc add dev eth1 parent 1:12 handle 20: netem delay 200ms tc qdisc add dev eth1 parent 1:13 handle 30: netem delay 300ms tc qdisc add dev eth1 parent 1:14 handle 40: netem delay 400ms tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip dst xx.xx.3.19/32 flowid 1:12 tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip dst xx.xx.5.19/32 flowid 1:13 tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip dst xx.xx.7.19/32 flowid 1:14 通过在本机设置到几个NS的不同延迟,对本地的bind发请求,抓包查看Bind到不同NS的请求量,可以对比出不同版本的bind的SRTT行为差异.