Re: VRRP and the kernel

To: Alexandre CASSEN <alexandre.cassen@xxxxxxxxxxxxxx>
Subject: Re: VRRP and the kernel
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 23 Nov 2001 18:39:51 +0200 (EET)

On Fri, 23 Nov 2001, Alexandre CASSEN wrote:

> >I see big problems for setups where the VRRP routers have
> >two or more devices attached to same hub. When the normal hosts
> >try to resolve the VIP via ARP they will receive many ARP replies
> >from the current MASTER.
> => Yes the same MASTER.

        After reading your next words it seems the hosts will
receive only one ARP reply, from the device where the MASTER is bound.

> >The question is: are these replies equal, i.e. containing same src MAC?
> Yes : A MASTER mean a VRRP Instance in MASTER state, which mean VRRP VIPs
> owned on the LVS director where VRRP Instance are in MASTER state. We know
> that VRRP Instance state are uniq and identified by a uniq VRID on the
> whole VRRP topology.

        IMO, there is also another question: why we restrict packets
to VIP to come only through once device (switch port)? Of course,
this is not true for all network stacks but Linux can do it: one
subnet reachable through many devices (at least the packets can
be received through many devices) but there is a way to send through
many devices. Anyways.

> >It seems one VIP should be served via many VRIDs? Or may be I'm
> >missing something?
> Nope, one VRRP Instance can only be active at a time => in MASTER state =>
> ARP reply, for VIPs owned by this VRID, will came from the same VRRP
> Instance currently in MASTER state. So if a LAN hosts request ARP for a
> specific VIP => so VMAC => VRID the response will came from a single source
> => from the VRRP Instance in MASTER state for the VRID corresponding to the
> VIPs ARP requested.

        Sure it will come from one host but it seems we (VRRP) resrtict
it also to come only through one device.

> >    But then the required behavior is to reply with 3 different
> >MACs if we have 3 NICs?
> => hmmm, is to reply with VMAC associated with a specific VIP. A specific
> VIP belong to the VRID in MASTER state owning this VIP. And only on VRID is
> active at a time. Agreed ?

        May be I don't fully understand the VRRP terms and internals
but as your hands are durty with VRRP, do you see any variant to
allow we to reply for one VIP through many devices with different
VMAC (of course, the VRRP protocol may be will use only one device
but for me, this is also questionable).

> > The MACs should be unique (they shouldn't
> >be advertised to 2 or more switch ports) while for the source
> >IP addresses that is not required (this is the way DR method works).
> >The rule is "Unique MACs at any time" which is not true when
> >the routers connect to many ports in a hub.
> => "MAC for VIP is uniq at a time" and reply on physical NIC where VRRP
> Instance in MASTER state run.

        Hm, this breaks the advanced routing, this is a restriction,
one subnet to use only one network.

> > with all consequences for the ARP race which
> >are successfully handled with rp_filter/arp_filter? Or the setups
> >are very secure and use one hub per network?
> => In my mind we run one Layer2/3 equipment on each network.
> Physical topology is :
>              WAN SIDE
>                 |
>     +-----------------------+
>     |      SWITCH/HUB       |
>     +-----------------------+
>       |                   |
>       | eth0              | eth0
>      +-----+           +-----+
>      | LD1 |           | LD2 |
>      +-----+           +-----+
>       | eth1              | eth1
>     +-----------------------+
>     |      SWITCH/HUB       |
>     +-----------------------+
>                  |
>                LAN SIDE

        This explains everything :))) Only one ARP reply per request.

> Regards,
> Alexandre


Julian Anastasov <ja@xxxxxx>

<Prev in Thread] Current Thread [Next in Thread>