Stephen Nadas | 7 Apr 2009 00:11
Picon
Favicon

May, should, must confusing section 7.1 vrrp

Hi Don, 

I'm trying, once again, to clean this up.   Been busy elsewhere... 

Mark H. pointed out: 

> Section 7.1:
> 
> - MAY verify that "Count IPvX Addrs" and the list of IPvX Address
>       matches the IPvX Address(es) configured for the VRID
> 
>    If the above check fails, the receiver SHOULD log the event and MAY
>    indicate via network management that a misconfiguration 
> was detected.
>    If the packet was not generated by the address owner (Priority does
>    not equal 255 (decimal)), the receiver MUST drop the packet,
>    otherwise continue processing.
> 
> This combination of MAY, SHOULD and MUST is confusing.  Also 
> it's not clear if the second "If" is conditional on the first 
> "If".  It seems like you may have a mandatory action that you 
> can't do unless you do an optional action.
> 

So I agree it's confusing.  The text (from rfc, and -v6 and from
combined) all say the same.  In particular the immediately prior text
isn't much better: 

      - MUST verify that the VRID is configured on the receiving
        interface and the local router is not the IPv6 Address owner
(Continue reading)

Stephen Nadas | 7 Apr 2009 01:13
Picon
Favicon

Is virtual mac a parameter?


Don,

One last item - Mark H mentioned:

> Section 6.1.  Should the VR MAC address be a parameter?  I
> think it should.
>

Your thoughts please.

Thanks,
Steve 






_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Cathy Zhou | 16 Apr 2009 23:22
Picon

question about the primary IP address

Hi,

I am trying to understand how this primary IP address works. In the draft 
(vrrp-unified-spec-02), it says this IP address is "selected from the set 
of real interface addresses". But this IP address is also used as the 
source IP address for the VRRP protocol advertisement packets (multicast) 
in which the mac address is set to the virtual MAC address.

I don't understand how this would work without causing any confusion. If 
this is a real interface address, can it be used by any other application 
other than the VRRP protocol? Do we suppose to respond to an ARP for this 
IP address using the real physical MAC address? But the neighbor bridges 
would already learnt that this IP maps to the virtual MAC address from the 
VRRP advertisement packet...

Thanks
- Cathy
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Cathy Zhou | 17 Apr 2009 02:36
Picon

Re: question about the primary IP address

Don,

Thanks very much for your reply. See more inline:

> ARP packets involving the VR IP address should always, always map
> it to the VR MAC address, never ever to the physical MAC address.
> My implementation went out of its way to avoid any ARP packets
> mapping it to the physical MAC during system initialization before
> VRRP was started because such errant mappings caused us so much
> trouble.
> 
> The VR IP address owner can use the address normally. It turns out
> that it can (and I would say should) use its physical MAC address as
> the source in all ethernet packets *except* the VRRP advertisements.
> In VR advertisements, it must use the VR MAC address as the source.
> 
> Bridges will learn about both MAC addresses, but all IP traffic will
> be sent to the VR MAC address.
> 
I see.

> By the way, personally, when I deployed VRRP, I found that an "owner"
> was more trouble than it was worth, so I always invented a new VR IP
> address that no one used except when they were the VR master, i.e.,
> an address that *wasn't* a real interface address anywhere.
> 
... and the only purpose of this IP Address is being used as the source IP 
address in the VR advertisement?

What exactly problem did you see when you use one of the "owned" addresses 
to send the advertisement?

One more question regarding the read of section 7.4. In the IPv6 case, the 
primary link local IPv6 address used as the VR advertisement source 
address should be formed by the physical MAC addresses, is this correct? 
Also, it sounds like that the first protected IPv6 address embedded in the 
advertisement can be formed by the virtual MAC address?

Thanks
- Cathy

> -don
> 
> -----Original Message-----
> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of
> Cathy Zhou
> Sent: Thursday, April 16, 2009 2:22 PM
> To: vrrp <at> ietf.org
> Subject: [VRRP] question about the primary IP address
> 
> Hi,
> 
> I am trying to understand how this primary IP address works. In the
> draft 
> (vrrp-unified-spec-02), it says this IP address is "selected from the
> set 
> of real interface addresses". But this IP address is also used as the 
> source IP address for the VRRP protocol advertisement packets
> (multicast) 
> in which the mac address is set to the virtual MAC address.
> 
> I don't understand how this would work without causing any confusion. If
> 
> this is a real interface address, can it be used by any other
> application 
> other than the VRRP protocol? Do we suppose to respond to an ARP for
> this 
> IP address using the real physical MAC address? But the neighbor bridges
> 
> would already learnt that this IP maps to the virtual MAC address from
> the 
> VRRP advertisement packet...
> 
> Thanks
> - Cathy
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Cathy Zhou | 17 Apr 2009 20:50
Picon

Re: question about the primary IP address


> It turns out that the VR IP address should *not* be the source IP
> address
> in the VR advertisement: an address the router owns should be used.
> (Obviously these overlap for the VR IP address owner.) 

That is exactly what confuses me: For the VR IP address owner, can we 
or can we not use that VR IP address as the source IP address of VR 
advertisement?

Thanks
- Cathy
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp


Gmane