Subject: RE: [VRRP] trouble VRID based MAC address vs. "smart" switch?

From: William Flusek <[email-masked]>
Date: Thu, 24 Oct 2002 17:03:21 -0500

Maybe I misread the original note, but I was took the statement to mean 
that we had router A up and running as active.  router B was coming up 
and attempting to dislodge router A and become active.  Router B was 
attempting to communicate with router A using the shared MAC.

 >I've discovered that the switch I'm using (Netgear) refuses
 >to forward packets with a given MAC address down the link
 >on which the switch has learned that same MAC address.
 >So when two systems are "negotiating" VRRP -- for example,
 >the Virtual Address owner comes on line and tries to
 >dislodge a backup -- neither hears the other's packets
 >because both are using the same source MAC address.

It would seem that what should be happening is that router B should be 
attempting to dislodge router A using its BIA and not until they have 
established which should be active and handed off control should router 
B be using the shared MAC to send traffic.  Otherwise you have a problem 
with two systems having the same MAC which the switch should think is a 
problem or loop, shouldn't it?

Just my two cents.

Bill Flusek
[email-masked]

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

---

From: danny mitzel <[email-masked]>
Date: Thu, 24 Oct 2002 17:02:11 -0700 (PDT)

--- William Flusek <[email-masked]> wrote:
>> Maybe I misread the original note, but I was 
>> took the statement to mean that we had router 
>> A up and running as active.  router B was
>> coming up and attempting to dislodge router A 
>> and become active.

that's basically my take on the original description.

>> Router B was attempting to communicate with
>> router A using the shared MAC.

vrrp protocol packets are never sent to the vmac 
address.  for router B to talk vrrp protocol to 
router A (or any other vrrp router) packets are 
sent to an IP multicast address (224.0.0.18), 
which gets mapped into an ethernet L2 group 
address.  an ethernet group address is never 
``learned'' (i.e., there'll never be an associated 
entry in the switch station learning cache).  the
ieee802.3 forwarding algorithm for unknown mac.dst
is broadcast on all interfaces in state=Forwarding
except the interface the packet came in on.

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Don Provan" <[email-masked]>
Date: Fri, 25 Oct 2002 10:38:34 -0700

First, let me make clear that the shared MAC address is being
used by both nodes as the *source* MAC address. I'm pretty sure
that's what you meant, but Mr. Mitzel seems to have interpreted
your comments as meaning the shared address being used as the
destination.

The idea of not using the shared address until you have some
reason to believe you "own" it makes a lot of sense, but of
course it's specifically against the spec. The spec is designed
so that the entire takeover operation, including the switch
learning, is accomplished by the very first VRRP packet.

In addition, it wouldn't help in the rare case where, for
whatever reason, two nodes both believe they own the virtual
address. They'd both continue advertising forever without ever
hearing each other.

-don provan
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
William Flusek
Sent: Thursday, October 24, 2002 3:03 PM
To: [email-masked]
Subject: RE: [VRRP] trouble VRID based MAC address vs. "smart" switch?

Just my two cents.

Bill Flusek
[email-masked]

---

From: danny mitzel <[email-masked]>
Date: Fri, 25 Oct 2002 12:59:41 -0700 (PDT)

--- Don Provan <[email-masked]> wrote:
>> First, let me make clear that the shared 
>> MAC address is being used by both nodes as 
>> the *source* MAC address. I'm pretty sure
>> that's what you meant, but Mr. Mitzel seems 
>> to have interpreted your comments as meaning 
>> the shared address being used as the
>> destination.

I certainly don't remember making any comments
to the effect that vmac is used as mac.dst.

here are some statements I will make:
- all vrrp protocol messages are sent to an
  IP multicast destination address.
- IP multicast address are mapped to 
  'group' mac address when sent on
  ethernet/802.3 media.
- 'group' mac address are never ``learned''.
- the switch forwarding algorithm for 
  mac.dst not found in the station learning 
  cache is [broadcast on all ports in
  state=Forwarding except the port the
  frame came in on].

conclusion: vrrp protocol packets will 
always be delivered to all segments in a
properly functioning extended ethernet lan.

alternate conclusion: use of mac.src=vmac
by multiple stations has no effect on vrrp 
protocol convergence.

---

From: "Don Provan" <[email-masked]>
Date: Fri, 25 Oct 2002 14:15:20 -0700

>to the effect that vmac is used as mac.dst.

Sorry, I misunderstood your statement, then.
I thought you were suggesting that such behavior
might be the problem. (I certainly did NOT think
you were saying it was correct behavior.)

>  IP multicast destination address.

Agreed.

>  'group' mac address when sent on

Agreed.

>- 'group' mac address are never ``learned''.

Agreed. Of course, no group address is being
used as a source address anywhere, so whether
or not it should be learned is never an issue,
but I think you're just being thorough by pointing
out that such hypothetical learning couldn't
possibly be a factor.

>  state=Forwarding except the port the

I agree this is the expected behavior. My
theory is that, completely unrelated to this
normal forwarding procedure, there is an
anti-loop procedure overriding that decision.

So the question is whether this anti-loop
procedure is proper. Mr. Smith's comments
suggest that there are actually a wide
range of actions that a properly functioning
switch could take against packets arriving
from the "wrong" port. He also provided the
IEEE pointer, I'll go see for myself and let
everyone know what I find.

-don provan
[email-masked]