[c-nsp] switch mac address learning

Jon Lewis jlewis at lewis.org
Sat Nov 5 17:44:45 EST 2005


Someone emailed me privately asking for config from all the interfaces 
involved, and I didn't realize until I was about to send it that it was a 
private message.  Here's what I wrote, minus their reply.

Actually, someone else already mentioned this, and I only just 
realized/confirmed it, but the 6509 uses the same MAC address on every 
interface[1].  I thought it had a large range of MAC addresses and used unique 
ones on each interface.

[1] This isn't entirely true.  It does seem to use the same MAC address on all 
SVI's, and all L3 interfaces, which are effectively treated like SVIs. L2 
interfaces get unique MAC addresses, but these aren't used in arp replies...the 
SVI MAC address is used.  IOS will let you change the MAC address of an 
interface...but in doing so, you change the MAC address for every SVI/L3 
interface.  That was kind of scarey to find out the hard way.

So the problem I ran into seems to be a limitation of the 6509 and probably a 
result of the switch in my (7609) router rearing its ugly head.  Routers 
typically have a unique MAC address per ethernet interface.

> From: cisco-nsp-bounces at puck.nether.net on behalf of Jon Lewis
> Sent: Fri 11/4/2005 8:21 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] switch mac address learning
> 
> 
> 
> I've got the following network right now as part of a transition in which
> we'll be replacing switch1 (a 2924xl) with switch2 (a 3550).
> 
> 6509a-L3-FE-port---|switch1|---L3-FE-port-6509b
> |                      |                   |
> |                      |                   |
> L3-GE            FE crossover            L3-GE
> |                      |                   |
> |                      |                   |
> -------------------|switch2|----------------
> 
> Each 6509 has a layer 3 port in a /27 talking through switch1 to each
> other and a bunch of routers hanging off switch1.  To test the new fiber
> runs for the 6509/3550 connections, I brought up layer 3 gigE ports on the
> 6509s using a /30 with the intent of pinging one 6509 from the other.
> That works, but while doing it, I noticed an unreasonably large amount of
> traffic flowing between switch1 and switch2 and %RTD-1-ADDR_FLAP: messages
> on switch1.
> 
> For some reason, switch1 is learning about the 6509 GigE interface mac
> addresses via the FE connections it has to them.  Switch2 then learns
> these mac addresses from switch1, and AFAICT, is then sending a portion of
> the traffic I expected it to switch from g0/1 to g0/2 through switch1.
> 
> The explanations I found for %RTD-1-ADDR_FLAP: all talk about switch port
> loops...and though my current setup looks like a loop, I would have
> thought making all the involved 6509 interfaces layer 3 ports would have
> avoided this.  Is there a proper way to do this setup other than shutting
> off the 6509-2924 FEs?
> 
> What I planned to do after testing was make the 6509/2924 connections
> SVI's instead of L3 ports, then bring up the 6509/3550 GigE interfaces as
> switchports in those same SVIs.  Then move routers one at a time from
> switch1 to switch2, and eventually shut down switch1 once there are no
> devices left on it (other than the 6509s).
> 
> ----------------------------------------------------------------------
>  Jon Lewis                   |  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> 
>

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


More information about the cisco-nsp mailing list