On 03/21/2013 06:14 PM, David Hubbard wrote:
I've read that at least on the ipv4 side, many
Windows servers will not accept the gratuitous arp
when vrrp is brought up so they'll just sit there
happily talking to the dead hsrp MAC. I can't find
That has not been my experience. In fact, quite the opposite - when
moving from non-HSRP to HSRP, or HSRPv1 to HSRPv2, we've never seen an
outage except on some really old SunOS boxes, and both procedures rely
on the grat. arp to update end-hosts.
You will need to sequence it correctly of course, and there will be a
brief window where the virtual IP doesn't exist, so you'll probably take
a few seconds outage at minimum.
much of any info on how they'd deal with the change on
the ipv6 side. Not a huge deal either way since
the Windows stuff is minimal but would like to go
in knowing what to expect and what needs to be done.
On the linux side, I'm pretty sure it will accept the
arp and update the ipv4 default gateway mac; at least
it does when testing MITM attacks. Would love to
hear real world experience with this though. For
ipv6, I can't find much on what it does if its
previously learned router's link local address goes
unreachable, if it will replace the neighbor table
entry with the new vrrp advertised entry, do a
solicitation on its own, etc.
v6 is more tricky.
What you'll see is a new RA with the same prefix but a different router
address. The question is whether IOS will *first* send an RA with
lifetime=0 to "de-advertise" the HSRP virtual router, than send an RA
with the VRRP virtual router.
In the past when we've gone from non-HSRP to HSRPv6, this seems to have
happened. In that case, end-hosts will update their router more or less
immediately. But converting from one protocol to another might not
trigger the same behaviours.
I would test it on a dummy SVI if I were you; I don't think you need to
test with the full gamut of hosts/OS combos, just watch what ICMPv6
packets the IOS box emits as you do the transition - as long as the HSRP
router is de-advertised, you should be ok.
One final note: obviously none of this works if the grat. arp or ICMPv6
packets are missed by a busy host, or just plain dropped. You could
write a script using scapy to forge the relevant grat. arp / ICMPv6
packets and send multiple tries - this is a technique I've successfully
used to de-b0rk vlans after I've had an "accident" with emitting a rogue
RA during testing...
Broad recipie for sending an RA withdraw is, from my notes:
"""
You need to send an RA with:
Router lifetime=0
A prefix option with preferred lifetime=0 and valid=7200 (you CANNOT
send valid <7200 or it will be ignored)
$ ./run_scapy
>>> fix = Ether() / IPv6() / ICMPv6ND_RA(prf='Low', routerlifetime=0) /
ICMPv6NDOptPrefixInfo(prefix='2001:db8:1::', prefixlen=64,
validlifetime=7200, preferredlifetime=0)
>>> sendp(fix, iface='eth0', loop=0)
"""
...obviously spoofing the relevant IPv6 source address too.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
