cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1512
Views
18
Helpful
10
Replies

Mac Notification Trap Format Problem

jhilfiker
Level 1
Level 1

I have a 2960 running IOS12.2(46)

I'm having a problem with MAC Notification traps. I have all ports configured to send MAC notification traps. When I connect my HP Laptop I get a trap with the cmnHistMacChangedMsg in the following format :

<action><vlan><MAC><dot1dPort>

Which is correct according to the MIB.

When I connect a DELL desktop to the same device on the same ports I get a cmnHistMacChangedMsg with the following format :

<action><VLAN><MAC><???><dot1dPort>

That <???> appears to be two mystery bytes. I haven't had any luck tracking down what those could be.

Any thoughts?

10 Replies 10

Joe Clarke
Cisco Employee
Cisco Employee

Please post the actual data you're seeing. The pattern itself might make more sense than the description of it.

Disecting the mac notification message you get the following :

My laptop :

| action | 2byte Vlan | 6Byte MAC | 2Byte Port | N/A |

---------------------------------------------------------------------------

1 0.2 0.26.75.108.66.49 0.7 0

Dell Desktop :

| action | 2Byte Vlan | 6Byte MAC | 2 Byte ?? | 2 Byte Port | N/A|

-----------------------------------------------------------------------------------------

1 0.2 0.33.112.28.79.239 191.189 0.4 0

Here is the tcpdump : I have to admit I didn't get much from this..

16:37:09.026907 IP (tos 0x0, ttl 254, id 69, offset 0, flags [none], proto: UDP (17), length: 133) 192.168.102.13.55686 > qa205.bradfordnetworks.com.snmptrap: { SNMPv1 { Trap(90) E:cisco.9.215.2 192.168.102.13 enterpriseSpecific s=1 27036018 [|snmp] } }

0x0000: 4500 0085 0045 0000 fe11 cef7 c0a8 660d E....E........f.

0x0010: c0a8 05cd d986 00a2 0071 2d83 3067 0201 .........q-.0g..

0x0020: 0004 0670 7562 6c69 63a4 5a06 0a2b 0601 ...public.Z..+..

0x0030: 0401 0909 8157 0240 04c0 a866 0d02 0106 .....W.@...f....

0x0040: 0201 0143 0401 9c89 7230 3a30 1f06 0f2b ...C....r0:0...+

0x0050: 0601 ..

thanks

You truncated the raw packet right before the good part. I couldn't find a bug on this, but there were some changes in 12.2(46)SE with regard to these traps. I tried to reproduce on one of my switches, and good not. All of my MAC add operations produced 12-byte messages. I take it your Dell's MAC is 00:21:70:1c:4f:ef?

Ok.. I re-did the tcp dump and this is as verbose as I could make it.. I think this particular trap is from the remove, but it's suffering from the same problem.

10:11:38.595151 IP (tos 0x0, ttl 254, id 188, offset 0, flags [none], proto: UDP (17), length: 133) 192.168.102.13.55686 > qa205.bradfordnetworks.com.snmptrap: { SNMPv1 { Trap(90) E:cisco.9.215.2 192.168.102.13 enterpriseSpecific s=1 33362977 [|snmp] } }

0x0000: 0030 488c fbac 0001 e6ee 2200 0800 4500 .0H......."...E.

0x0010: 0085 00bc 0000 fe11 ce80 c0a8 660d c0a8 ............f...

0x0020: 05cd d986 00a2 0071 0f6d 3067 0201 0004 .......q.m0g....

0x0030: 0670 7562 6c69 63a4 5a06 0a2b 0601 0401 .public.Z..+....

0x0040: 0909 8157 0240 04c0 a866 0d02 0106 0201 ...W.@...f......

0x0050: 0143 0401 fd14 2130 3a30 1f06 0f2b 0601 .C....!0:0...+..

And yes, 00-21-70-1c-4f-93 is the mac address of my Dell.

Thanks again for your help.

My decode yielded a last octet of 0xEF not 0x93. Something is not right. And this dump is still truncated. Can you run tcpdump in the following way, then post the resulting outfile:

tcpdump -w outfile -s 1518 host IP_OF_SWITCH and udp port 162

That way I will be sure to have the full raw packet.

Here is the output of the command you sent me :

You are correct about the MAC address.. I hadn't noticed that before either.. The last octet of the MAC address should be 93 and we decode it as EF as well. Interesting.

All of these varbinds are correct. Here is what I see from an octet perspective:

01 00 02 00 21 70 1c 4f 93 00 06 00

-- ----- ----------------- ----- --

Op VLAN MAC Address Port Op

(Two of the above, then one 02 op for a delete.)

I don't know where you're seeing those other bytes.

hmm.. you said before that your decode of the packet yielded a final octet of EF for the MAC address. That's what were seeing along with the extra 2 bytes after the MAC. What changed about this decode? Sorry about my inexperience with decoding tcp packets.

I'll run through our code which decodes the traps and see if I can see anything strange going on there. Though, I can't imagine why it would work fine for one device ( my laptop ) and not another..

Thanks so much for your time. You have been very helpful.

I previously decoded the data based on what you provided (already extracting from the trap PDU), not the raw data. The raw data is correct, so the problem must be with your NMS decoding the data incorrectly. However, after going through these frames, I'm not exactly sure where your NMS could be getting messed up. I'm not seeing the byte patterns you reported previously.

I found the issue. It was a problem with the NMS decode of the trap packet. Thank you for all your help. I'm sorry to have wasted your time.

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: