cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2538
Views
0
Helpful
5
Replies

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

Marko Leopold
Level 1
Level 1

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!

1 Accepted Solution

Accepted Solutions

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

View solution in original post

5 Replies 5

Peter Paluch
Cisco Employee
Cisco Employee

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
Level 1
Level 1

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

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

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

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?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: