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 ! key-chain vrrp-auth key-id 1----------VRRP1采用MD5方式认证 key-string encrypted DC ! 下面我们来看看两个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 } interface em2.0 {----------------监测上行端口UP、down状态 priority-cost 100; } }当监测到em1的带宽不满 } 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的理解，可能存在疏漏，甚至错误，请大家不吝赐教。 张蒙
|
|
|
