Extreme Networks Homepage Extreme Networks Homepage

MAC show fdb listing wrong port for a PC

C
I was looking for a device on a x460 switch by mac. I ran sh fdb . The return listed the machine's mac on our gateway port. I found the correct port by using the phone's mac which showed the correct port that the device was connected. The machine had no physical connection to the gateway port !!!! Anyone have any ideas how this could happen. The device port was a netlogin configured port.

9 replies

K
Rank
Userlevel 5
A topology diagram showing your network layout particular is there are any redundant links would help better answer your question. Also, do you have CDP enabled devices communicating through the switch or sending CDP packets to the switch?
"if it matters to you, let's find a way"
C
The gateway port connects to Cisco routers. How can CDP affect a locally connected mac table entry?
K
Rank
Userlevel 5
I have seen the behavior outlined in the following knowledge base article in https://gtacknowledge.extremenetworks.com/articles/Solution/CDP-packets-may-cause-packet-loss-in-con...
"if it matters to you, let's find a way"
A
Rank
Userlevel 1
We did resolve an issue with fdb learning with netlogin, see the following article:-
https://gtacknowledge.extremenetworks.com/articles/Solution/FDB-learning-issues-on-switch-with-netlo...
C
Anderson Vaughan wrote:

We did resolve an issue with fdb learning with netlogin, see the following article:-
https://gtacknowledge.extremenetworks.com/articles/Solution/FDB-learning-issues-on-switch-with-netlo...

The examples show no learning. Are there other reference showing the MAC being associated with another port?
* Slot-1 switch37 # sh fdb port 4:4

Mac Vlan Age Flags Port / Virtual Port List

------------------------------------------------------------------------------

*:00:3f:cd Default(0001) 0044 d m 4:4

*:47:ed:61 Default(0001) 0044 d m 4:4

*****:13:d2:dd Default(0001) 0104 d m 4:4 this shouldn't be here

*:60:38:51 Default(0001) 0044 d m 4:4
K
Rank
Userlevel 3
Anderson Vaughan wrote:

We did resolve an issue with fdb learning with netlogin, see the following article:-
https://gtacknowledge.extremenetworks.com/articles/Solution/FDB-learning-issues-on-switch-with-netlo...

Most likely switch recieved packet on port 4:4 with SMAC *:13:d2:dd. Do you always see the issue or it happened once? What happenes when FDB entry ages out?
C
Anderson Vaughan wrote:

We did resolve an issue with fdb learning with netlogin, see the following article:-
https://gtacknowledge.extremenetworks.com/articles/Solution/FDB-learning-issues-on-switch-with-netlo...

It's not something you normally look for. I have never observed this before. I disconnected the machine and cleared the MAC table, then it disappeared. I watched it for a about 10 minutes prior and it was persistent.

I'm writing a macro to check switch ports from a dump to see if this happens frequently. It may happen a lot on Extreme switches and no one notices.
K
Rank
Userlevel 3
Anderson Vaughan wrote:

We did resolve an issue with fdb learning with netlogin, see the following article:-
https://gtacknowledge.extremenetworks.com/articles/Solution/FDB-learning-issues-on-switch-with-netlo...

I would use ACL counters to see if switch receives packets from source mac *:13:d2:dd on port 4:4.
So if you can detect any packets with source mac *:13:d2:dd on port 4:4 then FDB entry will be legitimate.

You can use following policy as a template:
entry count_smac {
if {
ethernet-source-address ;
} then {
count smac_pkts;
}
}[/code]
K
Rank
Userlevel 3
Anderson Vaughan wrote:

We did resolve an issue with fdb learning with netlogin, see the following article:-
https://gtacknowledge.extremenetworks.com/articles/Solution/FDB-learning-issues-on-switch-with-netlo...

Just wanted to share a link on KB article which describes how to create and apply ACLs.

Reply

    Back to top