|
Hello,
On Fri, 23 Nov 2001, Alexandre CASSEN wrote:
> > Is it VRRP really working with LVS because I see that LVS
> >works only with PACKET_HOST packets.
>
> Currently it's work with gratuitous ARP updating remotes caches (5
> gratuitous ARP on each VIP during VIPs takeover). But it is not RFC
> compliant. PACKET_HOST yes ... For LVS VRRP VIP(s) are simple secondary
> IP(s) address(es). To simulate VRRP VIP takeover it consist of :
>
> 1. If backup router doesn't receive the MASTER multicast VRRP advert
> 2. Then transition to MASTER state
> 3. So BACKUP router become MASTER and set VIP using netlink call (the same
> as : ip address add 192.168.200.10X dev ethX)
>
> => And in our LVS configuration LVS VIP(s) = VRRP VIP(s)
>
> >What I understand from the kernel
> >sources is that by using VRRP we will receive packets to VIP marked
> >as skb->pkt_type = PACKET_MULTICAST (due to the VRRP VMAC prefix) but
> >rt_type = RTN_LOCAL (VIP is local).
>
> VRRP packet advert source IP header is primary IP address of remote MASTER.
Oh, yes. I thought the MAC is 01:00:5E but it is only
for VRRP proto. For other traffic it is 00:00:5E:00:01:VRID which
is PACKET_HOST.
> So skb->pkt_type = PACKET_MULTICAST will be set only for a non VRRP VIP =
> MASTER interface primary IP address. Only primary IP address interface join
> VRRP_MULTICAST_GROUP.
>
> so for VIP skbuf pckt type will be PACKET_HOST & as VIP is RTN_LOCAL, LVS
> can handle traffic on VRRP VIP ? are you agreed ?
Yes, the multicast traffic (the VRRP protocol) uses the
multicast MACs. The traffic to VIP uses normal MACs.
> /* complete the VMAC address */
> vsrv->hwaddr[0] = 0x00;
> vsrv->hwaddr[1] = 0x00;
> vsrv->hwaddr[2] = 0x5E;
> vsrv->hwaddr[3] = 0x00;
> vsrv->hwaddr[4] = 0x01;
> vsrv->hwaddr[5] = vsrv->vrid;
>
> => The VRID identify an VRRP Instance. If we run multiple VRRP Instance all
> VRID are defferents.
I now see it, this is not a PACKET_MULTICAST, sorry. But
then 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. The question is: are these replies equal,
i.e. containing same src MAC? I don't see the word "switch" or "hub"
in the RFC. Are the authors using such devices? :) At least, Linux.
It seems one VIP should be served via many VRIDs? Or may be I'm
missing something?
> >I prefer we to keep the VIP-VMAC table device independent
> >or we have to duplicate the VIP->VMAC list for each device.
>
> Agreed....
>
> >Because we
> >can receive ARP probe "who-has VIP1 tell UNIQUE_IP" from many devices
> >and we have to send same reply through all of them. This is different
> >from the normal behavior for PACKET_HOST IPs because we send the ARP
> >replies always with the device's MAC. But replying with same VMAC
> >through all devices can cause problems with the switch?
>
> Yes because switch can place a VMAC into a "blocker_table switch" since
> switch can understand a MAC loop (for example cabletron/enterasys switch
> securefast code will do this...)... or must deal with spaning trees....
> (but still swiss army knife solution :))
But then the required behavior is to reply with 3 different
MACs if we have 3 NICs? 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. I now read the pdf
file and don't see the switch and how many NICs from the VRRP
routers are connected to same switch. May be they will need
different VRID 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?
> > If we reply through each device with a different VMAC for
> >same IP then we can end up with "ARP race": the remote hosts will
> >see how each VIP changes frequently its MAC because all these devices
> >in our VRRP router are attached to same hub. Nothing different from
> >the current behavior. So, it seems each device needs its own VMAC
> >and then a global VIP->VMAC table or may be this is not possible.
> >What is the current state in keepalived?
>
> keepalived use the same MAC for all VRID (VRRP Instances) this MAC is the
> manufactured physical NIC MAC. So all VRRP Instances use the same MAC @.
This is what we are trying to solve, right?
> >I remember something for
> >different instances per device but how is that related to the ARP?
> >Do we know with what MAC we should send our ARP reply considering
> >the requested IP and the input device where the ARP probes was
> >received?
>
> Yes we can know... Using the VRRP Instance state. If a VRRP Instance is in
> BACKUP state it doesn't reply ARP request with VMAC of its VRID. So
Yes, BACKUP must not reply.
> symetrically in MASTER state it reply to ARP request using VMAC VRID.
Still not but by RFC - yes.
Hm, then we have to find a way to reply with VMACs instead of
the physical MACs.
> Regards,
> Alexandre
Regards
--
Julian Anastasov <ja@xxxxxx>
|
