|
Hi christian,
> My new Problem is that we have an Router (Bintec XL2) which does not react
> on "Gratious ARP". And the Network guys say they can not change the
> ARP-Timeout. So at the moment I am looking at 20-30 minutes timout :(
> ARP-Proxy would be to much for the Router as it has a lot to do.
>
> Has anybody got an idea ?
In fact this depend of the code your switch is running... grrr... (wonderful
answer :) )
Some switch are not compliant with RFC and implements extension Gratuitous ARP
recognation. The problem you seem to have is that your switch doesn t recognize
VRRP gratuitous ARP. The problem can be :
1. Too many Gratuitous ARP are sent per VRRP VIP. Currently Keepalived code
implements a 5 gratuitous ARP broadcast per VRRP VIPs. So you switch can
consider this like a flood and put the port or VIP into its firmeware blocker
table... Personnaly I really don t think the problem is here.
2. The gratuitous ARP broadcasted are not compliant with your switch firmeware
code, it doesn t recognize the gratuitous ARP since it is not complete.
According to RFC (and many constructor firmware specs) Gratuitous ARP are sent
using 'ARPOP_REQUEST' option flags. This is what Keepalived code implements a
broadcast of ARP-Request over each VRRP VIP. But some constructor with their
mystic proprietary consideration want in addition a 'ARPOP_REPLY' that will
validate the previous ARP-Request. So to sum the GARP code need to send
ARP-Request + ARP-Reply... grrrrr very noisy, I agree...
=> I have tested the Keepalived/VRRP GARP code with 3Com,CISCO & Enterasys
switch and they only need ARP-Request msg. So I implemented the code that way
considering that those hardware were mostly used.
=> Your Bintec (I don t know this hardware) seems to handle Gratuitous ARP with
the ARP-Reply need.
So I can see 2 solutions :) :
1. You go into the network room and burn the Bintec switch :). Replacing with
another switch. You can even implement a topology with another network network
segment. You put a HUB/Switch into one port of the Bintec core-switch and then
you plug your Linux/Keepalived box into this new ethernet segment. That way
Gratuitous ARP will not be sent to another Bintec-switch port, all GARP
broadcast will be sent to the same Bintec-switch port.
2. I slightly enhance the Keepalived/VRRP code to extend it to the ARP-Reply.
But this can be possible that your Bintec doesn t handle GARP that way too...
But we can test. If this work I will apply into the new code.
=> I personaly prefer the 2. I am currently preparing the code to the next
release, I have done many code-cleanup... I plan the publication for this week.
So, when I will publish the new code, I will send you a patch to enable
ARP-Reply into the VRRP Framework... And we will try.
> I have read here
> http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO.failover.html#
> keepalived_vrrpd about VRRPD that it uses an Soft Ethernet with a MAC-Adress
> from the Private Range.
No. The current Keepalived/VRRP code doesn t handle VRRP Virtual-MAC (VMAC)
support since this is not easy to do with Linux Kernel. It only deal with
Gratuitous ARP that work nice and is quite enought since upper level topology
mostly implements proxy-arp...
=> So to not complecate the code and keep it as portable as possible, I have
decided to not spend time on this.
> I am a bit confused - is that a seperate Package ? I Found something here :
> http://www.linuxvirtualserver.org/~acassen/
> As far as I can see it is almost the same as in keepalived.
Ok. In fact on www.linux-vs.org/~acassen/ you can find 2 VRRP implementations.
the vrrpd-0.6.tar.gz that is only a proof of concept tool and must be
considered as unstable and not secure. And Keepalived. Keepalived implements a
strong VRRP framework, I have spent long time debugging and secure auditing the
code.....
=> If someone plan to use VRRP, Keepalived is hightly recommanded. I have leave
the old previous code but, please, use Keepalived instead.
> Is somebody using this in Prodution ?
Yes. I cannot give a list (to protect user) but I have a huge list of people
running the Keepalived code in production.
Best regards,
Alexandre
|
