01-04-2010 12:01 AM - edited 03-06-2019 09:08 AM
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!
Solved! Go to Solution.
01-04-2010 04:07 PM
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
01-04-2010 03:02 AM
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
01-04-2010 05:45 AM
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
01-04-2010 06:18 AM
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
01-04-2010 04:07 PM
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
01-05-2010 04:06 AM
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?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide