|
Hello,
>the multicast traffic (the VRRP protocol) uses the
>multicast MACs. The traffic to VIP uses normal MACs.
Exactly...
>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.
>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.
>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?
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.
>> >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?
=> 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 ?
> 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.
>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
Yes, all VRRP Instance are identifyed by a uniq & 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?
=> 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
>> > 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?
Yes exaclty to be able to reply with VMAC associated with VIP (a specific
VRRP Instance VRID in MASTER state).
>> >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.
Exactly you got it... :)
Regards,
Alexandre
|
