The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
Can IPv6 Neighbor Discovery Provide High Availability?
By stretch | Monday, April 18, 2011 at 2:33 a.m. UTC
This question has been in the back of my mind for some time, and recently popped up in a thread on networking-forum.com. There are three first-hop redundancy protocols (FHRPs) available for IPv4 on IOS: HSRP, VRRP, and GLBP. While some of these protocols now support IPv6, IPv6's own neighbor discovery feature seems well-suited to the task. In this post we'll see whether it's possible to achieve sub-second failover times using native IPv6 functionality.
The tests below are performed on Cisco 1841s running IOS 12.4(24)T.
NDP Router Failover
The client pictured above is attached to a LAN with two upstream IPv6 routers, R3 and R5. Both routers advertise themselves as default routers for the subnet. The client device installs both as valid choices for its default router:
Client# show ipv6 routers
Router FE80::3 on FastEthernet0/0, last update 0 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:0:1::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Router FE80::5 on FastEthernet0/0, last update 1 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:0:1::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
The command show ipv6 routers default shows that the client has chosen R3 as its default router (we could also verify this by examining the next-hop address for the client's default IPv6 route):
Client# show ipv6 routers default
Router FE80::3 on FastEthernet0/0, last update 2 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium, trustlevel = 0
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:0:1::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
We'll begin a continuous ping to the upstream address 2001:db8:0:9::1 and then quickly disconnect R3 from the network to simulate an outage of the default router. (It is worthwhile to note that the shutdown interface command should not be used on R3 as it would result in a final "goodbye" RA with a lifetime of zero seconds, gracefully informing the client that the router is no longer available and thwarting our experiment.)
Client# ping 2001:db8:0:9::1 repeat 1000 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 2001:DB8:0:9::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!....................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 97 percent (980/1000), round-trip min/avg/max = 0/0/4 ms Client#
We can see that the disruption lasted about 40 seconds (20 dropped packets with a 2-second timeout each). Below is the output of debug ipv6 nd running on the client during the outage:
00:49:16: ICMPv6-ND: STALE -> DELAY: FE80::3 00:49:16: ICMPv6-ND: ULP indication FE80::3 00:49:16: ICMPv6-ND: DELAY -> REACH: FE80::3 00:49:30: ICMPv6-ND: Received RA from FE80::5 on FastEthernet0/0 00:49:30: IPv6-Address: intfid_algo is notactive on intf 4 00:49:30: IPv6-Address: intfid_algo is active on intf 4 00:49:30: IPv6-Address: Generating IntfID rc 0, prefix: 2001:DB8:0:1::/64, address 2001:DB8:0:1:213:C3FF:FEDF:AE18 00:49:30: IPv6-Address: Prefix change 0x1 -> 0x1 00:49:30: IPv6-Address: Updating prefix 2001:DB8:0:1::/64 to FastEthernet0/0 00:49:30: ICMPv6-ND: Autoconfiguring 2001:DB8:0:1:213:C3FF:FEDF:AE18 on FastEthernet0/0 00:49:45: ICMPv6-ND: REACH -> STALE: FE80::3 00:49:46: ICMPv6-ND: STALE -> DELAY: FE80::3 00:49:51: ICMPv6-ND: DELAY -> PROBE: FE80::3 00:49:51: ICMPv6-ND: Sending NS for FE80::3 on FastEthernet0/0 00:49:52: ICMPv6-ND: Sending NS for FE80::3 on FastEthernet0/0 00:49:53: ICMPv6-ND: Sending NS for FE80::3 on FastEthernet0/0 00:49:54: ICMPv6-ND: PROBE deleted: FE80::3 00:49:54: ICMPv6-ND: PROBE -> DELETE: FE80::3 00:49:54: ICMPv6-ND: DELETE -> INCMP: FE80::3 00:49:54: ICMPv6-ND: Selected new default router FE80::5 on FastEthernet0/0 00:49:54: ICMPv6-ND: Removed default to FE80::3 on FastEthernet0/0 00:49:54: ICMPv6-ND: Installed default to FE80::5 on FastEthernet0/0 00:49:54: ICMPv6-ND: Sending NS for FE80::3 on FastEthernet0/0 00:49:54: ICMPv6-ND: Resolving next hop FE80::3 on interface FastEthernet0/0 00:49:55: ICMPv6-ND: Sending NS for FE80::3 on FastEthernet0/0 00:49:56: ICMPv6-ND: Sending NS for FE80::3 on FastEthernet0/0 00:49:56: ICMPv6-ND: STALE -> DELAY: FE80::5 00:49:56: ICMPv6-ND: ULP indication FE80::5 00:49:56: ICMPv6-ND: DELAY -> REACH: FE80::5 00:49:57: ICMPv6-ND: INCMP deleted: FE80::3 00:49:57: ICMPv6-ND: INCMP -> DELETE: FE80::3 00:49:57: ICMPv6-ND: Selected new default router FE80::3 on FastEthernet0/0 00:49:57: ICMPv6-ND: Removed default to FE80::5 on FastEthernet0/0 00:49:57: ICMPv6-ND: Installed default to FE80::3 on FastEthernet0/0
Oddly, R3 remains the client's default router even after a path is found via R5, evidenced by the last few debug lines and by examining the IPv6 routing table.
Client# show ipv6 route
IPv6 Routing Table - Default - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S ::/0 [2/0]
via FE80::3, FastEthernet0/0
C 2001:DB8:0:1::/64 [0/0]
via FastEthernet0/0, directly connected
L 2001:DB8:0:1:213:C3FF:FEDF:AE18/128 [0/0]
via FastEthernet0/0, receive
L FF00::/8 [0/0]
via Null0, receive
Repeated attempts to contact 2001:db8:0:9::1 through R3 from this point on result in the first packet always being dropped. Successive pings are forwarded reliably via R5. This is similar to the behavior caused by an initial ARP lookup under IPv4; however, it occurs which every individual iteration of the ping command, not just the first.
Client# ping 2001:db8:0:9::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:DB8:0:9::1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 0/1/4 ms Client# ping 2001:db8:0:9::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:DB8:0:9::1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 0/1/4 ms
Although R3 is still considered by the client to be a valid router with an unexpired RA, it is not listed in the neighbors table:
Client# show ipv6 routers
Router FE80::3 on FastEthernet0/0, last update 13 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:0:1::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Router FE80::5 on FastEthernet0/0, last update 0 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:0:1::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Client# show ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
FE80::5 0 0013.6050.acf4 REACH Fa0/0
Because the lifetime of R3's router advertisement is set to 1800 seconds, it will remain in the table (and as a default router) for up to thirty minutes before expiring.
Achieving Faster Failover
We can modify the router advertisement (RA) lifetime and advertisement interval to achieve substantially faster failover. Router advertisement attributes are configured per interface. There are two timers we need to consider: the RA interval (how often RA packets are generated) and the RA lifetime (how long a client device should consider the RA valid without it being refreshed).
For our first test, we'll choose moderate RA interval and lifetime timer values of one and three seconds, respectively. These timers should result in a three-second failover window.
R3(config-if)# ipv6 nd ra interval ?
RA Interval (sec)
msec Interval in milliseconds
R3(config-if)# ipv6 nd ra interval msec 1000
R3(config-if)# ipv6 nd ra lifetime ?
RA Lifetime (seconds)
R3(config-if)# ipv6 nd ra lifetime 3
These commands command should be applied on both R3 and R5.
We'll repeat the test by pinging 2001:db8:0:9::1 as we did earlier.
Client# ping 2001:db8:0:9::1 repeat 1000 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 2001:DB8:0:9::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 99 percent (998/1000), round-trip min/avg/max = 0/0/8 ms
Success! We lost only two pings with a two-second timeout each, which means our failover time was at most four seconds. We can also see that R5 became the new default router immediately.
Client# show ipv6 routers
Router FE80::5 on FastEthernet0/0, last update 0 min
Hops 64, Lifetime 3 sec, AddrFlag=0, OtherFlag=0, MTU=1500
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:0:1::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Client# show ipv6 route
IPv6 Routing Table - Default - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S ::/0 [2/0]
via FE80::5, FastEthernet0/0
C 2001:DB8:0:1::/64 [0/0]
via FastEthernet0/0, directly connected
L 2001:DB8:0:1:213:C3FF:FEDF:AE18/128 [0/0]
via FastEthernet0/0, receive
L FF00::/8 [0/0]
via Null0, receive
How much further can we reduce our failover time? Router advertisement includes a lifetime measured in whole seconds; the shortest lifetime which can be advertised is one second. This means that although we cannot technically achieve a deterministic sub-second failover time, we can get pretty close. We'll configure an RA interval of 300 msec; anything lower seems unnecessary.
interface FastEthernet0/0 ipv6 address 2001:DB8:0:1::3/64 ipv6 nd ra lifetime 1 ipv6 nd ra interval msec 300
Again, these timers should be configured on both R3 and R5.
Repeating the test once more, this time with a ping timeout of just one second, we see that only a single packet is lost.
Client# ping 2001:db8:0:9::1 repeat 1000 timeout 1 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 2001:DB8:0:9::1, timeout is 1 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 99 percent (999/1000), round-trip min/avg/max = 0/0/8 ms
Conclusion
Because IPv6 router advertisements have a minimum lifetime of one second, it's not possible to achieve deterministic sub-second failover. Traditional FHRPs including HSRP, VRRP, and GLBP, when available, remain the optimal solution for that. However, if none of the FHRPs are available or if you're willing to settle for slightly slower but functional failover, NDP is worth looking into. As with any feature, be sure to test failover timers in a lab environment before configuring them on production gear.
Posted in IPv6
Comments
April 18, 2011 at 3:45 a.m. UTC
Is the IPv6 RA function responsible for actually installing a static default route here on the client router with an AD of 2?
Client# show ipv6 route
IPv6 Routing Table - Default - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S ::/0 [2/0]
via FE80::3, FastEthernet0/0
April 18, 2011 at 1:29 p.m. UTC
@Joe: Yep (on IOS at least).
April 18, 2011 at 6:14 p.m. UTC
"There are three first-hop resolution protocols (FHRPs) available for IPv4 on IOS: HSRP, VRRP, and GLBP."
As far as I know these are first-hop redundancy (not resolution) protocols
Cheers :)
April 18, 2011 at 6:42 p.m. UTC
It would be interesting to see how this works with MS/*nix as a client.
April 18, 2011 at 7:28 p.m. UTC
Wow....
April 18, 2011 at 7:31 p.m. UTC
@man: Good catch, thanks.
April 19, 2011 at 6:29 p.m. UTC
What is the behavior if you set the lifetime to 0? Does it result in never dying?
April 20, 2011 at 5:17 p.m. UTC
When the client receives an RA with a lifetime of zero it removes the router from the list of default gateways. As a matter of fact, when configuring 'ipv6 nd ra suppress all' (>= 15.1M4), the Router sends out 3 unsolicited RAs with a lifetime of 0, so the host can delete the router from it's default gateway table.
I don't know if this is RFC compliant, but the Routers and (at least) Windows-Hosts are behaving like this.
Use 'ipv6 nd ra suppress' with caution:
In 12.4 releases, 'ipv6 nd ra suppress' suppresses both unsolicited and solicited RAs.
In 15.x releases, 'ipv6 nd ra suppress' suppresses only unsolicited RAs. To suppress solicited RAs you need the 'ipv6 nd ra suppress all' feature (>= 15.1M4, CSCth90147) or filter incoming RS'.
May 2, 2011 at 11:42 p.m. UTC
"Repeated attempts to contact 2001:db8:0:9::1 through R3 from this point on result in the first packet always being dropped. Successive pings are forwarded reliably via R5. This is similar to the behavior caused by an initial ARP lookup under IPv4;"
Can you elaborate on this ? isn't the router that transitions to the active state supposed to send a gratuitous ARP (so presumably the bridges are able to learn about it). In that case why would the first ping after a router failure fail ?
Jasmeet
May 10, 2011 at 1:38 p.m. UTC
I don't think that tuning the interval-timers of RAs is a good or elegant way to reduce failover-time in such a setup. Not only that it increases load of network and routers, it also leads to the undesired effect of constantly changing default-gateways on end-hosts (yes, it does; i tested with Windows 7).
A better way to achieve it is using the router-preference within the router announcments.
R1(config-if)#ipv6 nd router-preference ?
High High default router preference
Low Low default router preference
Medium Medium default router preference
Using this approach, the neighbor unreachability detection (NUD) of ipv6 comes into play. As soon as the neighbor state machine of IPv6 on the client checks that the neighbor is unreachable, it will use the next available gateway.
May 10, 2011 at 3:58 p.m. UTC
@airflow: Simply setting a router preference doesn't lower failover time. It is useful for achieving more deterministic failover, but you still need to lower the RA times to achieve faster failover. Also, this should not constantly change the next-hop router for hosts; if it does you've likely set your RA lifetime too low relative to your RA interval.
June 20, 2011 at 3:12 p.m. UTC
Hi, I have tried the same scenario using GNS3, running IOS 12.4(15)T14 in all routers and the "client" does not install the default route in its table even though both router link-local addresses appeared in the output of show ipv6 routers command. Maybe the weak point of using RA instead of HSRP v2 in IPv6 is that not all possible hosts S.O. would install the default route in all cases.
I also have another question? When you say "...and then quickly disconnect R3 from the network to simulate an outage of the default router" do you mean you disconnect the LAN interface facing the client, the "wan" interface or both? Because I was wondering if the RA mechanism works well if the outage is in the wan side (line drop) and not in the preferred router itself. Provided the outage is in the wan side, would the preferred router still be announcing the default-route to the client? As in my test the client router never install the default route I cannot check it.
Thanks.
July 28, 2011 at 12:10 p.m. UTC
nice demo, thanks. I was trying to implement v6 VRRP on my juniper routers but found it still isn't supported on the platform we're using so I will play around with this instead (Junos strangely has max and min advertisement interval parameters - not sure why)
@Chema - with VRRP etc you can track an upstream interface or route in order to cope with failure of a WAN link, obviously v6 RAs are not designed to do this. If your 2 "redundant" routers are directly connected and sharing routes you should still be able to route out (ie client->R3->R5->WAN)
August 18, 2011 at 1:44 p.m. UTC
@Liam
The reason why Junos has max and min is because they are following the RFC standard, Cisco allowing these minimum values does not conform to RFC4861
MaxRtrAdvInterval
The maximum time allowed between sending
unsolicited multicast Router Advertisements from
the interface, in seconds. MUST be no less than 4
seconds and no greater than 1800 seconds.
Default: 600 seconds
MinRtrAdvInterval
The minimum time allowed between sending
unsolicited multicast Router Advertisements from
the interface, in seconds. MUST be no less than 3
seconds and no greater than .75 *
MaxRtrAdvInterval.
Default: 0.33 * MaxRtrAdvInterval If
MaxRtrAdvInterval >= 9 seconds; otherwise, the
Default is MaxRtrAdvInterval.
December 15, 2012 at 4:29 p.m. UTC
Nice testing, but I´ll keep VRRPv3
October 1, 2014 at 4:30 p.m. UTC
Excellent article. Thanks a lot!
May 31, 2016 at 6:49 p.m. UTC
Nice post Jeremy. It opens up discussion of the various issues one can run into using IPV6 with these FHRPs.