The packet is treated as invalid and no learning is done?

Answered Question
Jan 4th, 2010

Hello group!

Actual i have the following log-message in a Catalyst 4503.

001247: Jan 3 17:04:32.239: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 51495 times)Packet received with invalid source MAC address (01:50:5A:E7:41:ED) on port Gi3/22 in vlan 65

It's coming from a nokia firewall running checkpoint IPSO cluster. The log message is explained here

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/25ewa/system/message/emsg.html

What i want to know is, what means the sentence "The packet is treated as invalid and no learning is done."? Does it means the packet will be dropped by switch or does it mean the packet will be forwarded but the source MAC-address will not be learned?

Many thanks in advance!

Correct Answer by Ryan Carretta about 7 years 1 month ago

When a frame is ingress on a layer-2 interface on a 4500, the hardware checks the CAM table for both the destination and source ethernet addresses of the frame.

In this case, the source address does not exist in CAM, so a source-address-miss interrupt is generated, and the packet is punted to software (the 4500 does MAC learning in software). This is why you have a host-learning queue, where you see these drops.

While the hardware is responsible for punting the frame due to SA miss, the actual learning is done by software. The software sees the frame is a multicast mac address (least significant bit of the most significant octet is set), and rather than learning the host and forwarding the frame it discards it.

So yes, the switch drops it. This accounts for your host-learning queue drops.

Additionally, as one poster mentioned, a multicast mac is not a valid source-address for an ethernet frame.

-Ryan

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Peter Paluch Mon, 01/04/2010 - 03:02

Hello Marko,

My personal guess would be that the frame will be dropped, basing on the statement that it will be treated as invalid. I don't have any definitive proof of that, though - perhaps other friends here can fill us both in.

What bemuses me is how the Nokia firewall came to the idea of putting a group MAC address into the frame's sender field

Best regards,

Peter

vvasisth Mon, 01/04/2010 - 05:45

It looks like you could be hitting this bug CSCsg10605 ASA:
TCP normalizer spoofs an ACK with all zeroes src MAC address.

Let me know if that helps

Varun

Marko Leopold Mon, 01/04/2010 - 06:18

Hello Varun!

Maybe the right answer for the wrong question ;-). There is no ASA in this constellation and the switch is not complaining about 00:00:00:00:00:00 source MAC-address. It is complaining about 01:50:5A:E7:41:ED as source MAC. I also was looking more closely to the device now and found out that it is NOT a nokia checkpoint firewall. To the port is connected a Cisco IPS 4260. For better understanding the constellation is looking like this. 2 4503 connected together through a 2GB/s portchannel and a pair of 2 IPS (1 IPS connected to 1 switch). I get the log-messages on the interface of the one IPS and i get the messages on the portchannel too.

The question was, what the switch is doing when he treats the packet as invalid. Does he drops it or does he forwards it but not learn the MAC on the port? What i found out by "show platform cpu packet statistics all" is, that there are drops for "Host Learning" on the switch

Packets Dropped by Packet Queue

Queue                  Total           5 sec avg 1 min avg 5 min avg 1 hour avg
---------------------- --------------- --------- --------- --------- ----------
Esmp                                 0         0         0         0          0
L2/L3Control                         0         0         0         0          0
Host Learning                  4933661         0         0         0          0
L3 Fwd High                          0         0         0         0          0
L3 Fwd Medium                        0         0         0         0          0

I can't tell since when those drops happens, but are those drops the dropped invalid packets? And how can i clear the platform cpu packet statistics?

Regards,

Marko

Correct Answer
Ryan Carretta Mon, 01/04/2010 - 16:07

When a frame is ingress on a layer-2 interface on a 4500, the hardware checks the CAM table for both the destination and source ethernet addresses of the frame.

In this case, the source address does not exist in CAM, so a source-address-miss interrupt is generated, and the packet is punted to software (the 4500 does MAC learning in software). This is why you have a host-learning queue, where you see these drops.

While the hardware is responsible for punting the frame due to SA miss, the actual learning is done by software. The software sees the frame is a multicast mac address (least significant bit of the most significant octet is set), and rather than learning the host and forwarding the frame it discards it.

So yes, the switch drops it. This accounts for your host-learning queue drops.

Additionally, as one poster mentioned, a multicast mac is not a valid source-address for an ethernet frame.

-Ryan

Marko Leopold Tue, 01/05/2010 - 04:06

Thank you for your answer Ryan. But this leads me to another question. The multicast MAC-address belongs to the nokia checkpoint cluster on the 2 catalyst 4503, but the switch is seeing the packets at the interface of the cisco IPS sensors. how can this happen? there is an IPSO cluster of 3 nokias on the switche. 2 nokias on 1 switch and 1 nokia at the other switch. they are sending multicast to perform clustering inside the vlan 65. is there a problem in the cisco IPS sensor with this multicast traffic?

Actions

This Discussion

Related Content