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

From: "Don Provan" <[email-masked]>
Date: Wed, 23 Oct 2002 16:50:39 -0700

Gee, I thought this list was fairly active, but I didn't
get any response to my first try. Oh, well, let's try a
different topic:

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.

The switch drops each packet as the "learned" MAC address
ping-pongs back and forth between the two links. I imagine
the switch is trying to avoid a forwarding loop, and I
guess I can't blame it. I find it hard to believe I'm the
first one to run into this, so am I doing something wrong?

-don provan
[email-masked]

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

---

From: Mark Smith <[email-masked]>
Date: 24 Oct 2002 11:34:09 +1000

Hi Don,

> first one to run into this, so am I doing something wrong?

I haven't seen this, but I've only run VRRP through a couple of Cisco
Catalyst 2900XL switches.

Is some sort of port security switched on ? This might prevent the
switch accepting / forwarding frames from two ports with the same MAC
source address.

Regards,
Mark.

---

From: "Don Provan" <[email-masked]>
Date: Thu, 24 Oct 2002 14:01:12 -0700

>> ping-pongs back and forth between the two links.
>

That was my first thought, but it's just a simple 24 port
Netgear switch with no controls. So whatever the security
is, it's built in.

-don provan
[email-masked]

---

From: danny mitzel <[email-masked]>
Date: Thu, 24 Oct 2002 14:40:04 -0700 (PDT)

sounds like a broken switch to me.  I don't
have any ieee 802 specs in front of me.    
I would guess for mac.dst == group address
algorithm for a 'dumb' bridge would be 
[forward on all ports except the one frame
came in on].  and for a 'smart' switch
(running spanning tree & station learning)
algorithm is [forward on all ports marked
as state=Forwarding except the one frame
came in on].  mac.src should have no effect
on the forwarding.
 
but when you throw in switch vendor value    
added features such as snooping IGMP group 
membership reports, parsing L3 and higher
protocols, various port filtering, redirection,
load balancing, ... could certainly lead
to vrrp [and many other protocol&application] 
breakage.

__________________________________________________
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: Mark Smith <[email-masked]>
Date: 25 Oct 2002 11:10:53 +1000

Hi Don,

> Netgear switch with no controls. So whatever the security

I'd doubt it has any specific security built in in that case - its
probably too dumb. I also have a netgear 8 port switch, it doesn't do
spanning tree protocol so I'm guessing security features such as this
probably haven't been implemented either.

It would be interesting to see how the switch acts if you plugged it
into another switch, and then had your VRRP master and backups plugged
into each switch separately. Ideally, this is how VRRP should be
implemented in a network, at least with lower end / commodity switches
that don't have redundant power supplies, backplanes etc.

I've had a gloss through the sections of the 802.1D spec (you can
download a number of ieee specs for free now from
http://standards.ieee.org/getieee802/).

As far as I can see, Sections 7.8 and 7.9.2 deal with dynamic learning
of MAC addresses. The underlying assumption seems to be that for a
single unicast MAC address, the only reason it will move to a different
port is that it is unplugged, in which case the default 5 minute Max Age
will timeout the station cache entry, or there is a failure in the
spanning tree topology, and the 15 second Forward Delay timer will be
enabled for the station cache MAC address aging while the STP topology
change flag is on.

There doesn't seem to be an explicit procedure for dealing with updating
an existing station cache entry with a different port. But then again,
the spec is 373 pages, I haven't read them all, so I could easily be
wrong.

On face value, your switch seems to be acting within the 802.1D
specifications.

Interesting problem. Might be worth sending an enquiry to netgear about
this behaviour.

Mark.