Subject: [VRRP] conflicting MAC addresses

From: jamal <[email-masked]>
Date: Tue, 27 Aug 2002 21:53:58 -0400 (EDT)

This might have been discussed in the past although scanning
the list since 1998 doesnt seem to provide an answer.

Has anyone thought about the effect of having two pairs of routers VRRPing
for different IPs with an end result of the same VMAC address being used
by two routers on the same broadcast domain? Actually not concerned
about VRRP perse; rather say VRRP and HSRP.

Is there a simple way to work around this via dynamic discovery (sure easy
to do via static configs)?

cheers,
jamal

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: danny mitzel <[email-masked]>
Date: Tue, 27 Aug 2002 19:42:41 -0700 (PDT)

--- jamal <[email-masked]> wrote:
>> Has anyone thought about the effect of having two
pairs 
>> of routers VRRPing for different IPs with an end
result 
>> of the same VMAC address being used by two routers
on the 
>> same broadcast domain?

the vrrp protocol receive processing (rfc2338 section
7.1)
specifies:
>      - MAY verify that the IP address(es) associated
with 
>	the VRID are valid
>   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.
if the implementation you're using follows this
recommendation
and encounters two vrrp virtual routers using same
vrid with
different addresses then you should at least get some
type of 
notifications to help debug the misconfiguration and
minimize 
impact.  if not supported then debugging may take a
bit more 
efforts.

>> Actually not concerned about VRRP perse; rather say
VRRP 
>> and HSRP.

vrrp calculates its vmac using a range of mac
addresses
assigned from official ietf OUI.  I can't remember the

hsrp algorithm from memory but I can say it doesn't
use
addresses from the ietf OUI.  also there are no other 
official Internet standards that have conflicting 
address assignment.

if you're using some vendor value added feature to 
override mac address and end up with conflicting
address usage then I believe that's called ``shooting
yourself in the foot'' and only solution is DON'T
DO IT.

>> Is there a simple way to work around this via
dynamic 
>> discovery (sure easy to do via static configs)?

I don't understand the question here.

later,danny

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: jamal <[email-masked]>
Date: Tue, 27 Aug 2002 22:59:39 -0400 (EDT)

> the vrrp protocol receive processing (rfc2338 section

[..]

> addresses from the ietf OUI.

00-00-5E-00-01-{VRID}

A CISCO running HSRP on the same network is 00-00-5E-00-01-1F;

> I don't understand the question here.

The solution you described about logging and alerting someone
to do something is what i would call static resolution.
Think IP address conflict resolution via something like grat apps.
Send an arp to find if someone else has that address and maybe switch
to some other address if already taken; what would be an equivalent way to
do it for MAC addresses?
Two routers can still receive the same packet; one of them will possibly
junk it. That may be unnecessary work unless it is design intent.

cheers,
jamal

---

From: danny mitzel <[email-masked]>
Date: Tue, 27 Aug 2002 20:34:48 -0700 (PDT)

> A CISCO running HSRP on the same network is

the original rfc submitted to document hsrp
(rfc2281) states the hsrp mac is from the cisco 
oui (00:00:0c:07:ac:{hsrp group number}).  from
the latest ios 12.2 docs online this still seems
unchanged.  my only guess would be that someone
has used a 'value add' ios feature 
[e.g. standby mac-address <mac-address>] to 
utilize non-standard hsrp group mac address.  
not a very smart idea IMO.

later,danny

---

From: jamal <[email-masked]>
Date: Wed, 28 Aug 2002 08:28:33 -0400 (EDT)

Danny,
I agree with your point view in general;
Apart from the "value-adding" crowd, this could be a result of a
misconfiguration; the problem is clearly avoided when the OUIs are
known to be owned by vendors who take a lot of care ensuring they dont
get rotated in decade time-frames. How do you do the same for a
MAC address which is reusable like the VRRP ones are? The dangers of
conflict are pretty high as we have seen.

cheers,
jamal