Subject: Re: two questions about keepalived and vrrp
Newsgroups: gmane.linux.keepalived.devel
Date: 2005-05-13 10:09:25 GMT (3 years, 7 weeks, 3 days, 17 hours and 40 minutes ago)
Hi Philip,
> I've got keepalived running for just vrrp router failover. I'm writing
> an article about keepalived and vrrp for publication and I realized
> there are a couple things I'm still unclear on:
Ok, let's go :)
> 1. What's a virtual MAC address? I assume that involves assigning a
> second mac address to an ethernet port. I see some references to that
> but I haven't found a good explanation. If you use vmacs with vrrp,
> does a mac address move between the master and backup?
As specified in VRRP rfc2338.7.3 each VIP of a VRRP instance must use a
VMAC (Virtual MAC) address. In very first implementation of VRRP, I used
a very hacky stuff to provide support to those VMAC but only able to use
one VMAC per physical interface, this is why I decided to remove this
very hacky and nasty stuff IMHO.
Next, we discussed this VMAC with Julian Anastasov and Jamal Hadi. The
point is that Linux kernel doesn't provide kind of api to use multiple
MAC per physical interface. There is hacky stuff provided by netfilter
team using multicast MAC hack, but doesn't the best way to handle IMHO.
The point with VMAC is that, we need to deal with 2 differents traffics,
first handling ARP traffic and next traffic itself to alter MAC address
in ethernet header. Julian provided some time ago a nice iparp patch
that deal with the first point, for the second point Jamal provided
extended traffic engeneering 'pedit' facilities to handle traffic stream
at egress. So we have both, but while I can make it work unitary, I
failed making it work all together :/. The point is that I really want
to produce code that doesn't need kernel patch since it is much more
maintenable for me, so the point is to merge iparp to kernel, but as
Julian stated, since arptable is already merged, this will no be easy to
merge a new arp stuff, so from now, I just need to look at arptable to
look the way they are handling traffic. Here is the full point for VMAC
support.
OTOH, gratuitous ARP are well supported in recent constructor switching
firmware. So currently VRRP code support gratuitous arp to notify layer2
neighbor. So, during each takeover, gratuitous ARP are sent over all VIP
of a VRRP instance. This design just produce a loose of one packet
during transition, so for the moment this is acceptable. VMAC is a plus,
but really not needed...
> 2. How fast is the failover between master and backup? Are there any
> config options that control this? I haven't found any.
As specified in VRRP rfc2338.6.1.2, Master_Down_Interval is equal to
(3 * Advertisement_Interval) + Skew_time (Skew_time is here to introduce
kind of temporal derivation)
Keepalived of the possibility to modify the Advertisement_Interval
('advert_int' keyword), by default the value is 1. The a BACKUP router
detect MASTER loose in a time interval of around [0..3]s, so 3s is the
max and most of the time you have a detection of aroung 1s.
Fill free to send a link to the article ;)
Best regards,
Alexandre
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click