入木三分学网络第一篇--VRRP协议详解-----(2)
原帖：http://blog.chinaunix.net/uid-11654074-id-2857385.html
2.4 VRRP通告报文的发送与接收处理流程
2.4.1 当收到一个VRRP通告报文时，执行以下操作：
1． 检查IP包头的TTL是否为255
2． 检查VRRP报文的version字段是否为2
3． 检查VRRP报文的完整性，即是否包含RFC所定义的各字段
4． 检查checksum字段
5． 检查VRID字段是否和本地配置的VRID一致
6． 确保本地路由器不是IP地址拥有者，即优先级不是255（如果自己是IP地址拥有者，那么自己永远都是Master路由器，所以丢弃任何收到的VRRP通告报文）
7． 检查认证类型和认证数据字段，确保和本地一致
如果上面的七项检查有一项不通过，那么就会丢弃该报文，如果配置了网管程序，就会自动记录log并报告错误。
如果以上检查通过，那么可能会检查VRRP通告报文中的Count IP Addrs字段和IP地址字段，确保核本地一致，如果检查结果不一致并且该报文不是由IP地址拥有者产生的，那么丢弃该报文。注意：这里用了可能，所以各厂家在实现VRRP时，可能会检查也可能不会检查该字段，Cisco就不会检查。
如果以上检查均通过，那么接下来会查看Advertisement_Interval是否和本地一致，若不一致，会丢弃该报文。如果配置了网管程序，就会自动记录log并报告错误。
2.4.2 发送一个VRRP报文的时候，需要执行下列动作：
1． 将当前手动或默认的VRRP配置封装进报文的相关字段
2． 计算VRRP校验和，将结果放入checksum字段
3． 设置帧的源MAC地址为虚拟MAC地址（这样就确保了下联交换机可以建立正确的MAC表，即实际端口和虚拟MAC的对应关系，这个对应关系会因为Master路由器的切换而发生变化，所以这个处理对于上行数据帧的正确转发至关重要）
4． 设置IP包头的源IP地址为该物理接口的主IP地址
5． 设置IP头中的protocol字段为0x70，也就是十进制的112，表示上层封住协议是VRRP
6． 将封装好的VRRP通告报文发送出去，目标IP为组播地址224.0.0.18，目的MAC地址为组播MAC ：01:00:5e:00:00:12
好了，以上就是关于VRRP全部的协议实现细节，下面我们来看一下VRRP的应用需求。
3. VRRP的两种应用需求：
冗余备份、负载均衡
3.1我们来看一个具体冗余备份的图例：
图五（VRRP为下行设备提供冗余备份功能）
上图的实例中我们定义了一个虚拟路由器，标识为1（即VRID=1）；其虚拟IP设置为IP A，是Router1的接口IP，所以Router1就是一个IP地址拥有者，系统会将其优先级设置为255，并作为VRID1的Master路由器，而Router2的优先级默认为100，Router2的VRRP实例VRID1将自己设置为Backup路由器；下行的各主机将网关设置为VRID1虚拟路由器的虚拟IP，即IP A。
通过以上设置，即可消除出口路由器的单点故障，假如此时Router1挂掉，那么Router2的VRRP进程经过 Master_Down_Interval =（3*Advertisement_Interval）+ Skew_time，时间之后，就会宣布Master挂掉，将自己设置为Master路由器，并广播免费ARP请求报文，这样下行交换机就能更新虚拟MAC到与Router2接口的对应表项，从而实现不间断转发用户的流量。
但是，实际情况中我们很少这么设置VRRP，因为始终是一台路由器在承担所有流量，不符合物尽其用的原则。
3.2 我们来看一个冗余备份和负担均衡相结合的图例：
图六（VRRP同时实现冗余备份和负载均衡）
上图中的VRID1的设置和图五一样；VRID2的设置将Router2作为Master路由器，Router1作为Backup路由器，然后将一半下行主机的网关设置为VRID1的虚拟IP，即IP A，将另一半主机的网关设置为VRID2的虚拟IP，即IP B。
这样，在两台设备都正常运行的情况下，终端流量一半走Router1，一半走Router2，实现了负载均衡；而当其中一台路由器挂掉时，依靠VRRP的功能，会将另一台路由器设置为Master路由器，继续流量转发，从而实现了冗余备份功能，此时，这台路由器会同时作为VRID1和VRID2的Master路由器。
4. 实例研究
实际组网中，绝大多数情况都是双交换机或双路由器上行，所以图六的VRRP实现具有普遍意义，下面，我们就来看看VRRP在各厂家设备上的配置实现（都以图六作为试验拓扑）：
4.1 VRRP在Cisco路由器上的实现
下面两图是Router1和Router2的VRRP配置及状态：
通过VRRP的运行状态，我们可以知道：
1． 即使为IP地址拥有者配置了优先级，系统也会使用255
2． 若不指定优先级，系统缺省认为是100.
3． 缺省通告时间是1秒
4.2 VRRP在Redback路由器上的实现
下面就是两个VRRP实例在Redback路由器上的配置：
context vrrp
interface downlink
ip address 192.168.10.201/24
vrrp 1 owner-----------------------这表明这个VRRP实例的IP是路由器的接口IP
virtual-address 192.168.10.201—必须是真实interface的IP，否则系统报错
advertise-interval millisecond 100----VRRP通告报文的发送间隔，这里为100毫秒
authentication redback-md5 vrrp-auth—采用MD5方式认证
vrrp 2 backup---------------------这表明这个VRRP实例的IP地址一定不是interface接口
的IP，但是和interface接口IP一定在同一个网段内。
virtual-address 192.168.10.202
advertise-interval millisecond 100-----VRRP通告报文的发送间隔，这里为100毫秒
priority 120----------------------------本地VRRP优先级为120
init-wait 1------------------------------VRRP实例2启动后，等待接收VRRP通告报文的时间
track interface uplink vrrp decrement 100---VRRP实例监控上行链路的状态，若为down，则将本地VRRP优先级降低100
authentication simple vrrp-authentication----VRRP实例2采用明文认证
!
interface uplink----------------------上行端口，连接骨干网
ip address 10.1.1.1/30
!
key-chain vrrp-auth key-id 1----------VRRP1采用MD5方式认证
key-string encrypted DC2C32F335F4113A949FEF2997659B974A70687575316125
!
下面我们来看看两个VRRP实例的状态：
Redback路由器上VRRP实现特性：
1． 将VRRP的owner角色与backup角色从配置层次上区分开，这样做的好处就是非常清晰。而其他厂家没有关键字来区分这两种角色，只是依靠virtual-address是否和本地接口IP地址相同来判断本地VRRP实例是owner角色还是backup角色。
2． 若配置VRRP实例为owner角色，那么virtual-address必须是interface的IP地址，否则系统报错，并且此时不能配置priority，因为系统为owner角色永远分配255的优先级；反之若配置VRRP实例为backup角色，那么virtual-address绝对不能是interface的IP地址，否则系统报错，并且此时不能配置priority为255，因为255是系统为owner保留的优先级。
3． 只有backup状态的VRRP实例才能够配置preempt，因为master无需抢占。
4． Track：这是个非常有用的特性，它是用来快速检测上行链路的连通性并作出反应的命令。我们来假设这样一种情况，此时本地路由器作为VRRP实例2的master角色，假如路由器的上行接口uplink挂掉了，那么本地的所有上行流量都将被丢弃，对下行设备来讲形成了路由黑洞，这是不可接受的。所以，依靠这个track特性来监控指定链路，当检测到指定链路down掉后，立刻将本地VRRP实例的优先级降低100.，从而让其他路由器抢占master角色。
我们把uplink认为down掉，来看看路由器的反应：
大家应该可以看到，当VRRP实例2，检测到uplink不通之后，将VRRP2的优先级降低100,120-100=20，所以我们在上图中看到VRRP2的优先级为20。
5． 对show vrrp的显示结果做一下简单说明，Last Adv Source是指VRRP通告报文的发送者的IP，所以此处总是置为0，并且VRRP报文中也不包含此字段，只不过是Redback方便网管的一个处理方式。
6． Last Event：是指VRRP导致发生状态转化的事件，可能是配置了虚拟地址、端口UP，主路由器超时，被别人抢占了Master角色等等，可以作为网管的一个辅助判断手段。
4.3 VRRP在Juniper路由器上的实现
Juniper路由器上VRRP的实现和cisco差不多，下面来看看具体配置：
mm# show interfaces ge-0/0/0 ----------在当前接口的unit10子接口上起了两个VRRP实例
unit 10 {
family inet {
address 192.168.10.201/24 {-----------------------物理接口IP地址
vrrp-group 1 {----------------------------------VRID = 1
virtual-address 192.168.10.201;--------虚拟IP地址为物理接口IP
priority 120;-------------------------------虽然配置了120，但是系统会改为255
fast-interval 100;--------------------------快速发布VRRP通告报文
preempt {
hold-time 0;----------- ----实时抢占，因为这里是owner，所以无意义
}
accept-data;----------------接受目的IP是虚拟IP的报文
track {------------------------监测上行端口
interface em1.0 {
bandwidth-threshold 100m priority-cost 100;--监测上行端口带宽
}
interface em2.0 {----------------监测上行端口UP、down状态
priority-cost 100;
}
}当监测到em1的带宽不满100M或em2 挂掉后，将本地优先级降低100
}
vrrp-group 2 {
virtual-address 192.168.10.202;
priority 100;
fast-interval 100;
preempt {
hold-time 0;-------------------当发现Master挂掉后，执行实时抢占，而不是等待Master-down-interval
}
}
}
}
}
看一下VRRP运行状态：
5. VRRP的安全性
当前各厂家对VRRP的实现主要是依据RFC2338，采用sample、MD5、无认证，这三种方式，但最新的RFC3768已经取消了所有安全选项，这主要是因为在具体实施中遇到的问题，说白了就是上面的三种方式都无法提供实际的安全性，下面我们来具体分析一下：
这和VRRP的实现原理有关，虽然Master的VRRP通告报文经过MD5方式加密，但是攻击者可以截获、复制并发送同样的加密报文，从而导致出现多个Master，使下行交换机无法正确上传流量；另外一种情况，即使攻击者不复制发送VRRP通告报文，它也可以通过复制发送免费ARP报文，或者响应下行设备的ARP请求报文，从而误导下行交换机的流量选择，同样造成了路由黑洞。
基于以上情况，RFC4768取消了这些在其位不谋其政的安全选项，只是为了向RFC2338兼容，仍然保留了这些安全字段。
6. 一个典型的VRRP故障分析
前期有同事从事IMS项目，其中需要在Juniper路由器上设置VRRP，基本拓扑如下：
图（IMS项目当中的VRRP部署拓扑）
两台Juniper路由器各连接两台交换机，然后两台路由器之间做VRRP备份组。遇到的问题是，所有配置完成以后，两台路由器的VRRP实例均显示自己是Master，如下图：
图（Router-1的VRRP状态）
图（Router-2的VRRP状态）
通过上面两个图可以看到，对于VRID分别为1、2、3、4、5、6这六个VRRP备份组来说，两台路由器均认为自己是Master，而正常情况是：对于每一个VRRP备份组，都会有一台路由器是Master路由器，其它路由器全部是Backup路由器。
通过比对IMS项目的CND设计，排除了配置错误的可能性，来看一下VRRP的统计信息：
图（Router-1的VRRP统计信息）
图（Router-2的VRRP统计信息）
很明显可以看到各个VRRP备份组只有VRRP通告报文的发送，而完全没有接受，这是不正常的，而上面的故障现象就是没有收到VRRP通告报文所导致的。
两台Juniper路由器J2350的每一个VRRP进程都没有收到任何一个Advertisement数据包，所以均不知网络中其它VRRP路由器的优先级，所以始终认为自己是master。
注：当一个VRRP进程启动以后，会自动将自己切换为backup状态，如果经过3个Advertisement interval，这里是3*100s=300s，没有收到更高优先级的Advertisement数据包，则将自己切换为master状态。
将关注投向了具体拓扑，这个拓扑和常规实现有所差异，两台路由器不是连接到同一台交换机上，而是分别连接到两台交换机，靠交换机之间的链路来交换VRRP通告报文，以及上行流量的冗余备份，所以断定VRRP通告报文被阻断了。
综上所述：
1． 查看各端口及链路是否正常
2． 需要查看下行的互联交换机之间是否能够正常通信（即J2350与下行交换机的接口是否与两台交换机互联接口处于同一个VLAN之中）。
3． 查看是否是下行交换机的安全策略阻止了VRRP通告报文的转发
经过实际判断，最终确认是下行交换机的安全策略阻止了VRRP通告报文的转发，添加如下策略后，两台路由器的VRRP状态恢复正常：set security zone security-zone trust interfaces ge-0/0/0.10 host-inbound-traffic protocols vrrp
至此，故障解决。
7.后记
一年多没好好写篇文档了，其实写文档是一个对自己学习很好的总结手段，希望以后能够坚持下去，另外，本文基于个人对RFC3768的理解，可能存在疏漏，甚至错误，请大家不吝赐教。
张蒙
http://zmouc.cublog.cn
2010/7/23