Anycast：手把手教你搭建私人“骨干网”
好久没有发文章了，一方面最近没有发现好玩的东西，另一方面也不希望整一些乱七八糟的东西去糊弄少的可怜的读者们。 这应该是手把手教你搭建私人“骨干网”系列的第二篇了，第一篇的连接在这里：
SR：手把手教你搭建私人“骨干网”
Ray(任老板)，公众号：竹子的响声 SR：手把手教你搭建私人“骨干网”
最近，通过朋友新申请了一个ASN，可以让我把玩上一阵了，曾经作为“网工”的任老板也算对BGP有些熟悉，可是在申请ASN的时候填写的各种RIR的object也是搞的我一头雾水（强烈建议不熟悉的朋友先去DN42练个手）。
既然有了ASN就可以跟一些ISP运营商peer（建立BGP的邻居，然后相互发布路由，牵引流量）了，这里再啰嗦一句，AS代表一个个大大小小的网络，这个网络可大可小，比如google，aws，Azure，Aliyun等OTT以及公有云公司都有自己的网络，在比如At&T，NTT，KDDI，Singtel，中国电信（CN2的AS4809，163骨干网的AS4134）等ISP也有自己的网络。
当然，任老板也可以有自己的网络，比如AS205947（不知道请自行google，https://bgp.he.net/AS205947），整个互联网就是这样一个个大大小小的网络通过peer的方式或者一些IXP的交换机连接到了一起，最后实现了互联互通。在申请ASN的时候，LIR也送了一段48长度的IPv6地址，这样我就可以用这段地址组建自己的网络了，然后跟一些ISP建立peer，实现网络可达（用户可以通过互联网访问这些地址上面提供的服务）。
那什么是anycast呢，如果是学过一些网络知识的同学应该知道网络中有单播，组播，广播，未知单播等几种流量，那这里的anycast是什么呢？anycast是一种在全球互联网中比较常用的流量调度技术，举个比较常见的例子，就是DNS，我们经常的配置DNS比如114.114.114.114，或者8.8.8.8，就是利用了anycast技术（有些是为了其他的目的，感兴趣的可以私下沟通），我们都知道8.8.8.8是google的DNS，那为什么有时候在大陆ping这个地址的时候，为什么只有十几ms，有时候甚至只有几个ms，往返一趟北美至少也要100ms以上。
如果一次DNS请求的时间在几百ms以上，用户的上网体验是非常差的，为了改善这种状况，google就在全球主要的城市部署了DNS服务器，然后所有的DNS服务器的IP地址都配置成8.8.8.8（当然国内的8.8.8.8是不是google部署的我就不知道了），然后通过BGP宣告到骨干网中，我们知道在互联网中是根据路由的as path属性来优选路由的，对同样一条路由比如8.8.8.8/32，as path的长度短的会被采纳。
互联网通常有区域性这样一个属性，就是说一个区域的几个网络会直接建立peer比如大陆的三大运营商之间，也有区域性的IXP交换中心，一些小的ISP网络会通过IXP进行互联互通，这样就会让用户访问到距离比较近、网络质量相对比较好的DNS服务器。
这里再啰嗦一句（难道真的是年龄大了），刚才有说anycast是属于一种流量调度技术，用来提升用户的上网体验，在实际的生产环境中，还有很多中流量调度技术，尤其是在CDN网络中，比如常见的智能DNS技术，根据用户的IP地址的地理位置信息，来响应不同的解析IP地址，这里有个关键技术就是需要有一个相对准确的IP地理位置信息库，这点就需要找老高了。也有CDN公司根据用户的IP地址信息采用302的方式重定向到地里位置比较近的web服务器，来提升用户体验，都是需要依赖这个IP地址库。
当然这个库不是百分之百准确的，或者说地理位置近并不代表网络质量就好，为了解决这个问题，有些公司就在自己的客户端app里面埋了各种探针，来探测客户端到服务端的网络质量，选择合适的节点来提供服务。
开始动手吧
前提条件：准备一个ASN以及一点可以发布到互联网的IP地址段，如果想要申请的话，主要有两种途径，一种是直接申请RIR的会员，比如亚太地区的APNIC，欧洲的RIPE，但是会费会比较高，每年可能至少要大几千，当然既然交了会费也还是有些福利的；还有另外一种方式就是找LIR帮忙申请，有些LIR会申请一段ASN用来贩卖，这种是比较便宜的，可以私下联系我，推荐一些便宜的渠道。
网络是用来给应用提供服务的，如果没有应用，网络通了又能用来干啥呢（放在那里让你ping？）
我们假设一个场景，就是你搭建了个小web网站（或者websocket）， 至于网站用来提供什么服务，我就不管了，一定要注意遵守当地的法律。为了让全球的用户可以体验比较好的访问到这个服务，我们做一个额外的工作，当然这部分工作你也可以不做，以至于部分用户不能感受你的网站的魅力，如果不care的话。
这里我们采用anycast的方式来优化网络。
我们先在全球选择几个重要的节点（可以拿一个公有云分布在世界各地的可用区或者POP点来类比），这里我们参考一下第一篇文章中的图：
这里我们选择了东京，新加坡，悉尼，洛杉矶，纽约，法兰克福，阿姆斯特丹这7个城市，部署了公有云的虚拟机或者裸金属（如果你是土豪的话），这里有个技巧就是一定选择可以建立BGP Peer的公有云提供商，比如V开头的公司就可以提供，正好他们家有首月赠送100刀的优惠，就够我们玩一个月了。
然后在每个节点部署软件的BGP，比如frr（熟悉cisco朋友可以选择这个），搞IT的朋友可以选择bird，并跟上游的公有云服务商建立BGP Peer，这里给出一个frr的配置实例：
router bgp 205947
bgp router-id ipv4地址
no bgp default ipv4-unicast
neighbor 2001:19f0:ffff::1 remote-as 64515
neighbor 2001:19f0:ffff::1 password xxxooo
neighbor 2001:19f0:ffff::1 ebgp-multihop 255
!
address-family ipv6 unicast
network 2a09:4c2:2e::/48 (RIPE分配给你的ipv6地址段)
neighbor 2001:19f0:ffff::1 activate
neighbor 2001:19f0:ffff::1 soft-reconfiguration inbound
exit-address-family
!将RIPE分配给你的ipv6地址段通过这个BGP session宣告给你的上游， 然后ipv6地址段中选一个IP地址，比如2a09:4c2:2e:6666::/128, 配置在每个节点的dummy0接口上面
ip link add dummy0 type dummy
ip link set dummy0 up
ip add add 2a09:4c2:2e:6666::/128 dev dummy0接下来就开始搭建之前提到的web服务了，如果只是测试的话，最简单的方式就是部署个NGINX了
yum install nginx
or
apt install nginx
然后在每个节点将本节点的名称放入默认页面
比如，
echo "Los Angeles" > /var/www/html/index.html然后在本地测试一下
curl 127.0.0.1
or
curl [2a09:4c2:2e:6666::]如果在输出中看到了本节点的名称，就说明nginx部署成功了。
到这里，基础的配置就算完成了，如果感觉累的话，可以先去冲个咖啡，喝口水了。
来调试一下吧
现在，我们可以找一个ipv6环境，测试一把了，现在基本4G网络都会自动分配ipv6网络了，如果你实在找不到就用手机共享一下网络吧。
然后在你自己的笔记本上面，执行一下
curl [2a09:4c2:2e:6666::]:80看一下返回的是那个节点的名字呢？
然后在可以换个ipv6环境再试一下，是不是返回了另外一个节点的名字？
如果想让其返回一个固定节点名称，怎么办呢 ？这个也简单，as-path prepend 这个工具可以搞定，网工们应该对这个很熟悉的，基本原理就是在路由发布时，增加额外的as-path(至于增加一个as number，你就自己随意发挥吧)，使其发布的路由变成次优的，从而，让上游的服务商而选择其他节点发布的路由
route-map out-policy permit 1
set as-path prepend 205947 205947 205947
!
router bgp 205947
!
address-family ipv6 unicast
network 2a09:4c2:2e::/48
neighbor 2001:470:17:d1::1 route-map out-policy out在除制定节点以外的所有节点，增加上述配置后，再来curl一下，有咩有达到制定的预期呢 ？
好了，游戏到此为止吧！
还是让我们来思考一下吧！
上面的配置实验究竟有多大的优化效果，结果可能会让部分人失望，除非你在每个城市都部署了自己的“CDN”节点或者websocket（这个可以干啥，就不要问了）。
这里我们采用了anycast的方式来优化网络，基本模型就是所有的节点使用相同的IP地址，并发布到了骨干网中，这种模型在实际生产中落地场景相对还是比较少的，主要是一些无状态的应用，比如DNS。
在实际的生产需求中，点对点的加速或者点对多点的网络加速需求是比较旺盛的。就需要用到另外一种模型，就是每个节点发布不同的IP地址作为加速地址，节点直接需要有优质的互联网链路或者专线（比如海缆），并在节点构建自己的虚拟的（或者overlay）内部网络，然后在节点内部配置流量转发，将从客户端收到的流量通过节点内部配置的端口转发（比如DNAT），重定向到靠近目的地址的加速节点，然后在该节点再次进行端口转发，将数据包的目的地址变成真正的目的节点的IP地址，同时源地址也要变成加速节点的地址，以让回程流量通过加速网络。
这里有个问题，就是如果你的公网的IP地址是有限的，然后需要加速的用户有非常多怎么办呢？有些同学可能会说，一个IP地址可以监听好多端口啊，一个端口代表一个应用，但是如果所有的用户都想用同一个端口怎么办呢，比如22（说着这里，聪明如我的你可能已经知道我在说什么了，是的，你的想的没有错，不过借助这个服务还可以做很多有意思的事情，欢迎私聊），我们可以基于五元组的DNAT，在复用端口，如果借助iptables丰富的match属性，复用的变量会增加很多，当然，我相信公有云公司是不会用iptables这么庸俗的东西的。
下一次，等任老板有钱了，租的起海缆了，可以给大家演示一下这用模型。