|
|
Notice: If you prefer the old Vyatta mailing list style you can subscribe to these forums and post/reply via e-mail.
Just click on "Forum Subscriptions" above, select the forums that you'd like to participate in and click "Subscribe" |
|
| View previous topic :: View next topic |
| Author |
Message |
unrouteable
Elite Member
Joined: 01 May 2009
Posts: 83
|
 Posted: Thu Apr 15, 2010 9:12 am Post subject: cisco/vyatta VRRP incompatibility - MAC address |
 |
|
The protocol standards for VRRP (and its Cisco-specific predecessor, HSRP) say that the virtual router IP address should be assigned a special MAC address, so that when there is a transition between the primary and backup routers, the other devices on the network do not need to learn a new MAC address to route traffic.
This is how the protocol is implemented on a Cisco router, and it works just great. When there is a router transition, your network switch learns that the MAC address has moved to a new port, and none of your computers on the network notice any problems.
Alas, Linux does not support using more than one MAC address on the same interface, so the Linux implementation of VRRP (used by Vyatta), keepalived, uses a "trick" instead - it issues gratuitous ARPs to all the hosts on the network whenever keepalived has transited to master or won a router election.
This is nowhere near as reliable as its supposed to be according to the standard - when using the virtual MAC address, only your network switch needs to do anything for a router transition. With the Linux keepalived, every host on your network needs to update their ARP tables for the transition to work.
I'm currently supporting a network that is converting from Cisco to Vyatta - the catch is, during the interim they're using the Cisco as the backup failover if something goes wrong with the Vyatta. But thanks to the non-standard VRRP implementation of Linux/keepalived, there are a few problems:
* when there is a transition from Cisco master to Linux master, some traffic gets lost until all the clients have updated their ARP tables, as the Cisco once it has resigned the master role will not accept traffic on the virtual MAC address that was formerly used for the master. Going the other way is OK as long as the Linux router is still up and routing, since out-of-date clients are sending to the same MAC address as the router's regular interface on that subnet, so it receives the traffic and routes it.
* sometimes the ARP tables of the network devices don't get updated fast enough, or don't get updated at all. If the transition was from the Cisco to the Linux router, then those devices are off the air. I'm still tracking this one down - I think the gratuitous ARP messages from the Linux box are either getting lost or ignored. It varies among different OS's - we haven't seen any Linux boxes fail to update their ARP caches, but have had trouble with Solaris and NetBSD.
Any ideas on how to make the Cisco/Vyatta VRRP work smoother? |
|
| Back to top |
|
 |
stig
Vyatta Employee
Joined: 21 Feb 2008
Posts: 1284
Location: silicon valley
|
|
| Back to top |
|
|
unrouteable
Elite Member
Joined: 01 May 2009
Posts: 83
|
| Posted: Thu Apr 15, 2010 1:12 pm Post subject: Re: cisco/vyatta VRRP incompatibility - MAC address |
|
|
That should work, in theory (although in theory, everything works).
And it all seems doable inside transition scripts.
Looks like first do "insmod macvlan" followed by:
| Code: |
# ip link add link eth0 name eth0_macalias type macvlan
# ip link set eth0_macalias address 00:00:5e:00:01:XX
|
where XX is the hex number of the VRRP group.
Then we need another transition script to destroy the macvlan when the master resigns, which might be this code:
| Code: |
# ip link delete eth0_macalias
|
The above examples seem to work on the command line, but I haven't built the lab environment yet to test it. Will let you know.
Speaking of transition scripts, it doesn't look like there's a way to put parameters in the transition scripts, or any kind of environment vars that tell you what the virtual IP or interface is? As it stands now I have to write a separate transition script for each VRRP group (which gets old quickly, I've got a dozen or more), or do dirty tricks with the name of the script and symlinks. |
|
| Back to top |
|
|
stig
Vyatta Employee
Joined: 21 Feb 2008
Posts: 1284
Location: silicon valley
|
| Posted: Thu Apr 15, 2010 1:31 pm Post subject: Re: cisco/vyatta VRRP incompatibility - MAC address |
|
|
| unrouteable wrote: | | Speaking of transition scripts, it doesn't look like there's a way to put parameters in the transition scripts, or any kind of environment vars that tell you what the virtual IP or interface is? As it stands now I have to write a separate transition script for each VRRP group (which gets old quickly, I've got a dozen or more), or do dirty tricks with the name of the script and symlinks. |
I haven't actually tested this, but perhaps this quick hack would be useful:
| Code: | vyatta@R1:/opt/vyatta/sbin$ diff -u vyatta-vrrp-state.pl.bak vyatta-vrrp-state.pl
--- vyatta-vrrp-state.pl.bak 2010-04-15 14:26:26.000000000 -0700
+++ vyatta-vrrp-state.pl 2010-04-15 14:27:44.000000000 -0700
@@ -88,7 +88,7 @@
}
if (!($vrrp_transitionscript eq 'null')){
- exec("$vrrp_transitionscript");
+ exec("$vrrp_transitionscript $vrrp_state $vrrp_intf $vrrp_group");
} |
|
|
| Back to top |
|
|
unrouteable
Elite Member
Joined: 01 May 2009
Posts: 83
|
| Posted: Thu Apr 15, 2010 7:48 pm Post subject: Re: cisco/vyatta VRRP incompatibility - MAC address |
|
|
| stig wrote: | | unrouteable wrote: | | Speaking of transition scripts, it doesn't look like there's a way to put parameters in the transition scripts, or any kind of environment vars that tell you what the virtual IP or interface is? As it stands now I have to write a separate transition script for each VRRP group (which gets old quickly, I've got a dozen or more), or do dirty tricks with the name of the script and symlinks. |
I haven't actually tested this, but perhaps this quick hack would be useful:
| Code: | vyatta@R1:/opt/vyatta/sbin$ diff -u vyatta-vrrp-state.pl.bak vyatta-vrrp-state.pl
--- vyatta-vrrp-state.pl.bak 2010-04-15 14:26:26.000000000 -0700
+++ vyatta-vrrp-state.pl 2010-04-15 14:27:44.000000000 -0700
@@ -88,7 +88,7 @@
}
if (!($vrrp_transitionscript eq 'null')){
- exec("$vrrp_transitionscript");
+ exec("$vrrp_transitionscript $vrrp_state $vrrp_intf $vrrp_group");
} |
|
Yes, that works very well! Thanks! |
|
| Back to top |
|
|
unrouteable
Elite Member
Joined: 01 May 2009
Posts: 83
|
| Posted: Thu Apr 15, 2010 7:54 pm Post subject: Re: cisco/vyatta VRRP incompatibility - MAC address |
|
|
| unrouteable wrote: |
Looks like first do "insmod macvlan" followed by:
| Code: |
# ip link add link eth0 name eth0_macalias type macvlan
# ip link set eth0_macalias address 00:00:5e:00:01:XX
|
where XX is the hex number of the VRRP group.
Then we need another transition script to destroy the macvlan when the master resigns, which might be this code:
| Code: |
# ip link delete eth0_macalias
|
The above examples seem to work on the command line, but I haven't built the lab environment yet to test it. Will let you know.
|
Yes, it all seems to work, except I also had to do "ip link set eth0_macalias up". So it should be possible to provide Cisco compatibility by adding or removing the VRRP virtual MAC address in a transition script, where the transition script also does "arping -U -I eth0_macalias -s <VRRP-IP> <TARGET-IP>" for every TARGET-IP on different network switch segments (i.e. you don't need to bop every host on the LAN, just send out enough packets so that all your switches map the VRRP virtual MAC to the correct port).
This is still an awful kludge - hopefully the keepalived folks will make this unnecessary by adding the necessary functionality to keepalived. |
|
| Back to top |
|
|
unrouteable
Elite Member
Joined: 01 May 2009
Posts: 83
|
| Posted: Tue Jul 27, 2010 3:48 pm Post subject: Re: cisco/vyatta VRRP incompatibility - MAC address |
|
|
| unrouteable wrote: | | stig wrote: | | unrouteable wrote: | | Speaking of transition scripts, it doesn't look like there's a way to put parameters in the transition scripts, or any kind of environment vars that tell you what the virtual IP or interface is? As it stands now I have to write a separate transition script for each VRRP group (which gets old quickly, I've got a dozen or more), or do dirty tricks with the name of the script and symlinks. |
I haven't actually tested this, but perhaps this quick hack would be useful:
| Code: | vyatta@R1:/opt/vyatta/sbin$ diff -u vyatta-vrrp-state.pl.bak vyatta-vrrp-state.pl
--- vyatta-vrrp-state.pl.bak 2010-04-15 14:26:26.000000000 -0700
+++ vyatta-vrrp-state.pl 2010-04-15 14:27:44.000000000 -0700
@@ -88,7 +88,7 @@
}
if (!($vrrp_transitionscript eq 'null')){
- exec("$vrrp_transitionscript");
+ exec("$vrrp_transitionscript $vrrp_state $vrrp_intf $vrrp_group");
} |
|
|
Will the very effective and highly desirable patch above go into Larkspur? Wasn't there when I checked a couple of weeks ago. |
|
| Back to top |
|
|
stig
Vyatta Employee
Joined: 21 Feb 2008
Posts: 1284
Location: silicon valley
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group |
Forum Subscriptions
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
