Invalid mac adress

Unanswered Question
Jul 6th, 2008

I am receiving the following error message on switch

Jun 15 19:14:28.506: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 4 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Gi2/4 in vlan 100

Port 2/4 is trunk port and connected to other switch, and there are no logs on that switch

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Pravin Phadte Sun, 07/06/2008 - 02:19

Hi,

%C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: Packet received with invalid source MAC address ( [mac-addr] ) on port [char] in vlan [dec]

A packet was received with an all zero or a multicast source address. The packet is treated as invalid and no learning is done. Excessive flow of such packets can waste CPU cycles. This message is rate-limited and is displayed only for the first such packet received on any interface or VLAN. Subsequent messages will display cumulative count of all such packets received in given interval on all interfaces.

Recommended Action: Check the switch configuration file to find the source of these packets on the specified port and take corrective action to fix them at the source end. You can also enable port security on that interface to shutdown the port if the incoming rate of packets with invalid source mac address is too high by issuing the switchport port-security limit rate invalid-source-mac command.

Hope this helps,

Regards

muhammad-furqan Sun, 07/06/2008 - 14:13

Dear i already read this on cisco website, this is not help full at all, i just want to know how can i supress these messages? or how can i trace the source ???

The port on which i recieved this message is a trunk port connected to my distribution switch, i cant issue the invalid-source-mac command on it this will cause the permanent disconnection from network.

I cant find any messages on switch connected to this port

tsillaber Tue, 07/08/2008 - 02:52

Hi,

to find the source generating this packets a sniffertrace will be helpful, but selecting the rigtht port at the right time for monitoring would be a lucky strike. Using VLAN Maps should stop hosts with 00 Mac as source to communicate:

mac access-list extended bad-traffic

hardware statistics

permit host 0000.0000.0000 any

permit any host 0000.0000.0000

!

vlan access-map DATA_FILTER 10

action drop

match mac address bad-traffic

!

vlan filter DATA_FILTER vlan-list 1-2,5,10,20-27

Hope this helps

brgds and have a great day

Thomas

Kevin Dorrell Tue, 07/08/2008 - 04:58

On the switch attached to g2/4, how many ports do you have on VLAN 100? That could narrow it down a bit.

I wonder why the access switch is not logging it as well. It is IOS? If so, there is a different technique. Go to the access switch, and do a show mac-addr addr 0000.0000.0000. It will not tell you where that address was seen, but it should tell you that it is purging that address from the forwarding table.

I often see these zero MAC frames when the server guys create a new virtual server on a VMware platform, but have not configured it yet.

Kevin Dorrell

Luxembourg

tsillaber Tue, 07/08/2008 - 07:26

Hi Kevin,

i had the same problem and the Cat2960,Cat3560,Cat3750 do not log this message.. So it's difficult to find the device sending data with mac of 0... Maybe you see some SMB, NBNS or other higher Layer packets in the sniffertrace. Then it should be easy to find the host... The fast solution was to implement VACLS to filter the unwanted traffic at the Cat6k (here SUP6-e - hits in VACL - no error messages). It was also not possible to configure the same VACL at the access switches (no hits at all and error msg at Cat4k). I also saw no mac addresses with sh mac add add 0.. Looks like the accessswitches know that this mac address is not valid but don't care about it (from the forwarding point of view)

brgds

TS

limtohsoon Sun, 07/20/2008 - 22:49

Hi Kevin,

I received the following error messages on my Catalyst 4507R switch:

Jul 17 03:40:23: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 71 times)Packet received with invalid source MAC address (13:52:53:7F:00:1D) on port Gi3/6 in vlan 93

Jul 17 09:40:48: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 391 times)Packet received with invalid source MAC address (13:52:53:7F:00:1D) on port Gi3/6 in vlan 93

Port Gi3/6 is directly connected to a Cisco 10008 router. The invalid source MAC address 13:52:53:7F:00:1D is not even a multicast MAC address. What is it?

Do these error messages have any implication on the switch performance? The switch can form OSPF neighbor with the C10K and traffic can pass.

Please advise.

Thank you.

B.Rgds,

Lim TS

Kevin Dorrell Mon, 07/21/2008 - 01:32

Hi Lim TS,

In fact, the address 13:52:53:7F:00:1D is a multicast of sorts, but not one that I have ever seen before. What makes it a multicast is the least significant bit of the first byte. (The least significant bit is the first to be transmitted, and it is that which says it is a promiscuous frame.)

If it is directly connected to a router, there must be a reason for it, but I don't know what. It looks to be special for the 10000. Could it be something to do with the non-stop forwarding? Any experts in the 10K series?

In any case, I thought that it was illegal to have a '1' in the least significant bit of the first byte. I found this discussion about it:

http://www.tomshardware.co.uk/forum/20053-17-multicast-source-address-field

Sorry, that's all I have for now.

Kevin Dorrell

Luxembourg

Ryan Carretta Mon, 07/21/2008 - 02:06

1352.537f.00.1d is a multicast MAC, and packets should never be sourced from a multicast (or all-0) MAC address.

The 4k does mac-address learning in software, and has special provisions as a platform to catch these kinds of malformed packets, which I suspect is why you saw this message.

The 6k, for example, does mac learning in hardware, and drops these packets silently.

I'd look for a bad NIC on that network segment to see if there's something out there that is spitting out garbage. CRC calculation is often done separately in HW on NIC cards, so it is possible to have malformed packets that have valid checksums.

limtohsoon Mon, 07/21/2008 - 02:22

Hi Ryan,

The C10K is directly connected to the Cat4507R's interface Gi3/6, using a multimode fiber.

The same C10K router has another direct connection to another Cat4507R. This Cat4507R also received the same error messages.

What's actually the issue? Currently end-users are complaining that network performance is slow for traffic passing between the C10K and Cat4507R. I'm not sure if this error condition has any implication to the slow issue.

Cat4507R#sh proc cpu his

1111111111111111111111111111111111111111111111111111111111

7777000001111111111111110000077777000000000033333111111111

100

90

80

70

60

50

40

30

20 **** *****

10 **********************************************************

0....5....1....1....2....2....3....3....4....4....5....5....

0 5 0 5 0 5 0 5 0 5

CPU% per second (last 60 seconds)

1424141414142414141414241414141424141414142414141414241414

8726656566662667656767366666566625676566662665556665256655

100

90

80

70

60

50 * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

40 * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

30 * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

20 *#********************************************************

10 ##########################################################

0....5....1....1....2....2....3....3....4....4....5....5....

0 5 0 5 0 5 0 5 0 5

CPU% per minute (last 60 minutes)

* = maximum CPU% # = average CPU%

4444444565555556444444444444444444444444444444444444444444444444444444

7678787326943970888888988878888888788888888778988677676787888878878777

100

90

80

70

60 *** ***

50 **********************************************************************

40 **********************************************************************

30 **********************************************************************

20 **********************************************************************

10 ######################################################################

0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.

0 5 0 5 0 5 0 5 0 5 0 5 0

CPU% per hour (last 72 hours)

* = maximum CPU% # = average CPU%

Please advise.

Thank you.

B.Rgds,

Lim TS

Ryan Carretta Mon, 07/21/2008 - 02:30

What kind of switch is connected to Gi2/4 on the first 4k?

Is the other 4k that reported the error also connected (directly or indirectly) in the same vlan to that switch?

The idea here is you need to do some legwork to trace down that packet...this is not always easy because if it is truly a broken NIC, the behavior will likely be inconsistent. Are there any interfaces in that network segment that are reporting any errors or drops?

Actions

This Discussion