6509 MAC behaviour

Hi,
Why would I have a different port for a same MAC-address on a different linecard?
For example this MAC is going to Te2/5 on all linecards except Linecard 7 that is going to Te7/5.

sh mac add add 0014.4fcb.b15a
Legend: * - primary entry
age - seconds since last seen
n/a - not available
S - secure entry
R - router's gateway mac address entry
D - Duplicate mac address entry
Displaying entries from DFC linecard [2]:
vlan mac address type learn age ports
----+----+

* 126 0014.4fcb.b15a dynamic Yes 0 Te2/5

Displaying entries from active supervisor:
vlan mac address type learn age ports
----+----+

126 0014.4fcb.b15a dynamic Yes 35 Te2/5

Displaying entries from standby supervisor:
vlan mac address type learn age ports
----+----+

126 0014.4fcb.b15a dynamic Yes 35 Te2/5

Displaying entries from DFC linecard [7]:
vlan mac address type learn age ports
----+----+

* 126 0014.4fcb.b15a dynamic Yes 0 Te7/5

Find more posts tagged with

Comments

EdTheLad

Is it an SVI interface? For vlan 126 do you have multiple SVI's as in:

sw1

sw2

sw3

sw1
int vlan 126
ip address 10.0.0.1 255.255.255.0

sw2
int vlan 126
ip address 10.0.0.2 255.255.255.0

sw2
int vlan 126
ip address 10.0.0.3 255.255.255.0

Dieg0M

It is not an SVI, it is the MAC of a server. There has been no MAC flapping notifications sent. In fact, we do not even see the MAC beeing learned on that downlink (Te7/5).

networker050184

So is it possible to learn that MAC on that port? Have you cleared the table on that card to see if it's just out of sync?

Dieg0M

We have cleared the MAC for that specific MAC as clearing the table would be too intrusive. The Linecard 7 switched back to correct behaviour for 1 second (Te2/5) and then switched back to Te7/5. Also the aging is always 0 suggesting that this MAC is beeing relearned constantly.

networker050184

My next steps would be to figure out where 7/5 goes and if it is indeed actually learning the MAC there or if it is some kind of control plane issue.

Dieg0M

We followed 7/5 and it is not learning the MAC.

Edit:*I should also mention there is no static MAC configured on any of these switches. Only dynamic MAC's are learned.

networker050184

With both DFCs showing aging time of 0 it seems unlikely traffic sourced with that MAC isn't arriving at both ports often. If you know 100% (I'd do a packet capture) that frames are not hitting that port with the source MAC then I guess a Cisco case would be my next move.

Dieg0M

Cisco is already all over this.

Scales

Dieg0M wrote: »

Cisco is already all over this.

Are you doing some sort of NIC teaming on the server?

Dieg0M

Scales wrote: »

Are you doing some sort of NIC teaming on the server?

Yes we are doing standby/hot on the servers.

Scales

Dieg0M wrote: »

Yes we are doing standby/hot on the servers.

Ok, I don't know alot about the NIC teaming software however, i have run into a lot of problems with it in the past.

What software is it? Who is the manufacturer?

Dieg0M

Found out this was caused by the bonding protocol (IPMP) that wasn't properly set up on these servers. The reason we didn't see it before is because we had a topology on our access and distribution layer that masked the problem and we recently made a change in this topology.

Scales

Dieg0M wrote: »

Found out this was caused by the bonding protocol (IPMP) that wasn't properly set up on these servers. The reason we didn't see it before is because we had a topology on our access and distribution layer that masked the problem and we recently made a change in this topology.

Thats the NIC Teaming software on the server right?