Sanity check - monitoring LACP protocol

Unanswered Question
Feb 12th, 2010

I need a quick sanity check.  I am having problems setting up EtherChannel between an HP server and a Cat 2960G switch.  I have the switchports in "active", and 802.3ad configured on the server.  I can get the bundling working, but whenever the server re-boots, the EtherChannel goes into an inconsistent state: the switch believes the two links are bundled correctly, but the server does not.  If I then shut and no shut the Po interface, the bundle comes up correctly on both sides.  But clearly I cannot be on hand every time the server guys want to reboot their server.

The HP support guy wants me to moinitor the LACP during the re-boot.  I set up debug lacp all, and sent him the results, but he is not happy with that ... he wants a Wireshark trace.  Now, is that possible?  As far as I can see, LACP uses the IEEE Slow_Protocols_Multicast 01:80:C2:00:00:02, which is link-constrained.  That is, it will not be forwarded by any MAC bridge.  So presumably that means I will not see it on a SPAN or RSPAN monitor.  (That makes sense, because if a link-constrained protocol were seen outside its proper link, it could play havoc with the topology, unless it were hidden inside some encapsulation.)

So, excuse me if I am being thick, but has anyone here ever successfully done a 2-way trace of LACP using Wireshark?  If so, how did you do it?  Is there some sort of two-ended probe you can put in the cable or something?

Kevin Dorrell


P.S.  It is so long since I was last on this forum that everything has all changed.  It feels like going back to your native country after a 20-year absence.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Jon Marshall Fri, 02/12/2010 - 03:59


It's been a while since i saw you on here. NetPro has changed quite a bit i guess compared to the old site Hope your'e well and enjoying the benefits of being a CCIE.

As for SPAN, i must admit my understanding was that SPAN was fairly dumb in that it simply sent a copy of every packet to the destination span port. I have never captured LACP packets but i can't see why they should be any different. Indeed some of the config guides explicitly state that you can capture LACP packets with SPAN -

2970 SPAN traffic

Having said that not all config guides state this explicitly.

Sorry i couldn't be more help.


Kevin Dorrell Fri, 02/12/2010 - 04:17

Hi Jon, it's good to hear ffrom you, and congratulations on all those points you have built up.  I am relieved to see so many familiar names here.  So even if the geography of the "country" has changed, my old friends are still my friends.

Sorry, revised this posting.  Clicked before fully engaging brain.

Is it possible that the layer-2 link-local stuff can be monitored by SPAN but not by RSPAN?  I did an RSPAN of the ports I was interested, but I could not see any CDP, for example, even though CDP is actually running on the monitored ports.

Kevin Dorrell


Jon Marshall Fri, 02/12/2010 - 06:25


RSPAN is indeed different to SPAN. RSPAN does not support montoring of BPDUs or as the doc puts it "other layer 2 switch protocols" which probably means CDP/PaGP/VTP/DTP/LACP etc -

RSPAN restrictions

The config guides across switches and even the different release config guides for the same switch are not consistent in their information. Some talk only about BPDUs not being able to be monitored whilst some talk of BPDUs + other L2 switch protocols. But i would assume this is why you did not see any CDP packets in your RSPAN.


Kevin Dorrell Fri, 02/12/2010 - 06:49


OK, that makes sense.  It's irritating, 'cos it means I have to dig out the laptop and spend time in the cold and noisy data centre.  I suppose at least it is nearer the server rack.

I'll let you know what I find.

Kevin Dorrell


Kevin Dorrell Tue, 02/16/2010 - 06:11

OK, I've got it now.  On the 2960, layer-2 control protocols (LACP, STP, etc.) are not replicated into a SPAN session unless you include the keywords encapsulation replicate in the monitor destination, like:

monitor session 1 destination interface G0/15 encapsulation replicate

If the destination is an RSPAN VLAN (monitor session 1 destination remote vlan 40), then you are not offered any of the encapsulation options.  That way, the replicated packets cannot confuse the topology on their way from the monitored point to the monitorng point.

Thank you for your support Jon.

Kevin Dorrell



This Discussion

Related Content