场景 在被攻击的时候，当入口无法承受巨大的流量时大家采用的方式是切换业务IP，然后把之前的IP做黑洞。在与ISP对接时，每个ISP都有自己的BGP配置规范。接入方可以参考commuity属性对自己的路由做很多设置，包括MED,Localpref，AS-PATH 添加、路由定向宣告等，另外一个常用的就是黑洞某条路由 模拟拓扑 测试的环境有4个路由器：– R1：企业路由器– R2：ISP路由器– R3：其他ISP的路由器– R4: 其他ISP的客户 测试的方案 先把R1-R4的BGP调通，然后分别按下属操作：1. R1上添加prefix-list把5.5.5.6/32这个明细路由直接发送给R2，并设置community属性4134:666(电信的黑洞属性).2. R2上添加对community 4134:666的匹配操作 ip community-list standard cm-blackhole permit 4134:666 route-map out-filter permit 20 match community cm-blackhole set local-preference 10 set ip next-hop 172.20.20.1 set community additive no- export route-map out-filter permit 30 set local-preference 30 set metric 30 可以观察在R1-R4上的路由情况： R1 路由 094846cab3a9# show ip bgp BGP table version is 0, local router ID is 10.10.0.22 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete ...

以下图为例 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 ...

9.11 中增加了多EDNS Client Subnet（ECS）的支持。但是目前网上都还没有相关的测试，仅仅在邮件列表有点没配置成功的咨询。在9.11中需要开启ECS需要在编译的时候指定Geoip yum install -y GeoIP ./configure –with-geoip=–with-geoip=/usr/share/GeoIP/ 目前bind的ACL中是把ECS 带的Client地址作为一个独立的特征做匹配 单ECS本身还是做IP地址匹配，非常容易与现有的地址匹配混淆。最开始以为可以这样搞 acl zone1 { ecs 10.0.0.0/8 ; 10.0.0.0/8; }; acl zone2 { ecs 172.0.0.0/8; 172.0.0.0/8; }; view "zone1" { match-clients {zone1; }; zone "test.org" { type master; file "zone/test.org" ; }; }; view "zone2" { match-clients {zone2; }; zone "test.org" { type master; file "zone2/test.org" ; }; }; 发现走10.0.0.0/8内的源地址带172.0.0.0/8的subnet时始终命中zone1，无法到达预期的效果。目前测试OK的配置只能是把ECS的ACL做独立的view匹配。而且鉴于bind acl并非是最精确匹配，只是线性匹配，配置的时候必须要把ecs view写在最前面，否则即使请求带了ECS OPTION，也会因为源地址先匹配到其他view而达不到效果。。 acl zone1 { ecs 10.0.0.0/8; 10.0.0.0/8; }; acl zone2 { ecs 172.0.0.0/8;172.0.0.0/8; }; acl ecs-zone1 { ecs 10.0.0.0/8; }; acl ecs-zone2 { ecs 172.0.0.0/8;}; ...

最近开启了评论，存在大量机器自动填的垃圾评论。网上找了下一些验证插件，要么是使用还得把评论发到其服务端过滤，要么是像myQaptcha这样的太久不更新早已不能使用。网上找了个方案是直接把wp-comments-post.php文件改一下名字，先试试效果吧。 mv wp-comments-post.php wp-comments-post-gnuer.php sed -i 's/wp-comments-post.php/wp-comments-post-gnuer.php/g' $(grep wp-comments-post.php * -R|cut -d: -f1)

有几个场景需要使用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的路由在几个月维护时才动一次，然后恢复原状。

前几天同事反馈有个2000多个域名指向了自己的一台服务器，但是查询对应机器的PTR记录时发现只有1700多个。dig -x 查询了一下发现确实只有1700多个，检查了对应的zone文件内PTR记录是有2000多个的。偶然发现dig返回的MSG SIZE到了65519 在RFC1035中提到了DNS的几个限制：labels 63 octets or lessnames 255 octets or lessTTL positive values of a signed 32 bit number.UDP messages 512 octets or less整个UDP的消息被限制在512，不过随着后来EDNS0扩展协议（rfc2671），UDP的报文是可以到4096的(最大可以到65535)。在查询同事提供的PTR记录时，请求本身被TC置位走了TCP，因次这个UDP的限制无关的。DNS的限制实际在协议上 All RRs have the same top level format shown below: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NAME an owner name, i.e., the name of the node to which this re source record pertains. TYPE two octets containing one of the RR TYPE codes. CLASS two octets containing one of the RR CLASS codes. TTL a 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be ...