Frames forwarded to wrong access port

f.alessandro · ‎11-23-2014

Hi,

my problem is quite simple:

I have an access port of my switch 3750 that receive frames that aren't for his mac-address -.-

System image file is "flash:c3750e-universalk9-mz.122-40.SE/c3750e-universalk9-mz.122-40.SE.bin"

Here the config:

interface GigabitEthernet1/0/11
description Server fisico test LACP
switchport access vlan 103
switchport mode access
spanning-tree portfast
end

Acc-Dev-SAP02#show mac address-table interface GigabitEthernet1/0/11
Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
103    000a.e481.1b90    DYNAMIC     Gi1/0/11
Total Mac Addresses for this criterion: 1

The switch correctly show the mac-address of my ethernet port:

[root@server ~]# ifconfig management0 | grep -i ether
ether 00:0a:e4:81:1b:90 txqueuelen 1000 (Ethernet)

Now I assume that if I try to sniff the traffic on my ethernet card eth0 (I renamed it with udev) I should see only frame that have in the dest_ether my mac address but it is not so! Here a little sniff with tcpdump:

tcpdump -e -n -i management0 not port 22
14:43:52.434489 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 321: 172.25.240.27.57917 > 192.168.130.23.https: Flags [P.], seq 151:418, ack 1242, win 253, length 267
14:43:52.472355 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 113: 172.25.240.27.57917 > 192.168.130.23.https: Flags [P.], seq 418:477, ack 1242, win 253, length 59
14:43:52.473597 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 907: 172.25.240.27.57917 > 192.168.130.23.https: Flags [P.], seq 477:1330, ack 1301, win 253, length 853
14:43:52.479279 d8:67:d9:7a:c2:44 > 01:00:5e:00:00:66, ethertype IPv4 (0x0800), length 114: 192.168.130.3.hsrp > 224.0.0.102.hsrp: HSRPv1
14:43:52.479813 00:00:0c:9f:f0:67 > 01:00:5e:00:00:66, ethertype IPv4 (0x0800), length 114: 192.168.130.2.hsrp > 224.0.0.102.hsrp: HSRPv1
14:43:52.484884 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 74: 172.25.68.48.ldap > 192.168.130.23.36075: Flags [S.], seq 4028131841, ack 1191200232, win 8192, options [mss 1380,nop,wscale 8,sackOK,TS val 33737784 ecr 871056973], length 0
14:43:52.487582 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 88: 172.25.68.48.ldap > 192.168.130.23.36075: Flags [P.], seq 1:23, ack 39, win 513, options [nop,nop,TS val 33737784 ecr 871056973], length 22
14:43:52.488874 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 1974: 172.25.68.48.ldap > 192.168.130.23.36075: Flags [P.], seq 23:1931, ack 142, win 512, options [nop,nop,TS val 33737784 ecr 871056974], length 1908
14:43:52.489376 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 60: 172.25.68.48.ldap > 192.168.130.23.36075: Flags [R.], seq 1931, ack 149, win 0, length 0
14:43:52.491508 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 74: 172.25.68.48.ldap > 192.168.130.23.36076: Flags [S.], seq 3174971581, ack 1333951668, win 8192, options [mss 1380,nop,wscale 8,sackOK,TS val 33737785 ecr 871056974], length 0
14:43:52.493522 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 88: 172.25.68.48.ldap > 192.168.130.23.36076: Flags [P.], seq 1:23, ack 69, win 513, options [nop,nop,TS val 33737785 ecr 871056974], length 22
14:43:52.494018 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 66: 172.25.68.48.ldap > 192.168.130.23.36076: Flags [.], ack 77, win 512, options [nop,nop,TS val 33737785 ecr 871056975], length 0
14:43:52.494061 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 60: 172.25.68.48.ldap > 192.168.130.23.36076: Flags [R.], seq 23, ack 77, win 0, length 0
14:43:52.533119 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 74: 172.25.68.48.ldap > 192.168.130.23.36079: Flags [S.], seq 3291750511, ack 1947665179, win 8192, options [mss 1380,nop,wscale 8,sackOK,TS val 33737789 ecr 871056985], length 0

Anyone could explain to me because I receive traffic that should be for 00:0c:29:98:ee:48? It seems like the switch is working like an hub -.-

Thanks for help!

acampbell · ‎11-24-2014

Hi,

MAC address 000a.e481.1b90 is a Wistron LAN card
MAC address 00:0c:29:98:ee:48 is a VMWare server address.

The VMWare address my be for the Servers team address if one is set up.

Can you look on your LAN switch for MAC address 00:0c:29:98:ee:48

show mac address-table address 000c.2998.ee48

Find out what the address table thinks the port/interface is for that address

Regards
Alex

Regards, Alex. Please rate useful posts.

f.alessandro · ‎11-24-2014

Actually I dont have that macaddress in my arp table, but I try with these macs:

14:02:47.165432 d8:67:d9:7a:c2:44 > 00:0c:29:98:ee:48, ethertype IPv4 (0x0800), length 891: 172.25.240.23.61296 > 192.168.130.23.https: Flags [P.], seq 477:1314, ack 1301, win 507, length 837

Acc-Dev-SAP02#show mac address-table | i ee48

no results!

Acc-Dev-SAP02#show mac address-table | i c244
103 d867.d97a.c244 DYNAMIC Po7
449 d867.d97a.c244 DYNAMIC Po7

interface Port-channel7
description verso N7K
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-4047
switchport mode trunk
end

That is the uplink to main distribution switch!

What do u think about it? Thanks for reply, regards.

f.alessandro · ‎11-25-2014

UPDATE: I see (sniff with tcpdump) the same frame in two access port (same vlan) of two different 3750, the destination mac-address is connected to a FEX device of N7K -> 101 FEX101 Online N2K-C2232PP-10GE

It's like the N7K broadcast certain frames to all access port :(

Anyone have notice a similar problem?

Richard Burts · ‎11-25-2014

I believe that there is insight into this issue when we consider part of your output

Acc-Dev-SAP02#show mac address-table | i ee48

no results!

One of the basic behaviors of an Ethernet switch is that if it is attempting to forward a frame and the destination mac address is not in the switch table then it will forward that frame to all access ports in the vlan. It sounds to me like that is what is happening here. A frame had destination mac ee48, could not identify the specific destination port and so forwards to all ports in the vlan.

HTH

Rick

HTH

Rick

Joseph W. Doherty · ‎11-25-2014

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Rick, I'm sure, has simplified "... so forwards to all ports in the vlan.", but just to note, that excludes the ingress port.

f.alessandro · ‎11-26-2014

Thanks for the good insight! I thinked about it and I decide to check the source NOT the destination!

Example:

14:26:28.526466 02:a0:98:46:48:fc > 00:19:99:ef:66:76, ethertype IPv4 (0x0800), length 230: 192.168.130.252.nfs > 192.168.130.28.925: Flags [P.], seq 19024:19188, ack 1240161, win 33580, options [nop,nop,TS val 2180190379 ecr 855906291], length 164: NFS reply xid 828332787 reply ok 160

N7K-001-DEV# show mac address-table | i 48fc
103 02a0.9846.48fc dynamic 0 F F vPC Peer-Link

I've checked the source address of several frames and all of them came from vpc peer link or vpc link.

Now I'm thinking to a possible problem with vpc configuration|