Capturing – because I can: IS-IS, GLBP, VRRP

I am constantly trying to add more protocols to the Ultimate PCAP. Hence I used some time in my (old) Cisco lab to configure and capture the following protocols: IS-IS, GLBP, and VRRP. And since Alexis La Goutte sent me some CAPWAP traffic, this protocol is also added. All packets are now found in another update of the Ultimate PCAP. Here are some details:

Lab

This was my lab for those captures:

IS-IS

Haha, to be honest, I have not worked with the Integrated Intermediate System to Intermediate System routing protocol anytime in my life. ;) I just used Google and some tutorials to configure it on routers R1, R4, and R5. The goal was to propagate the default route from R1 to R4 & R5, and the networks (IPv6 and legacy IP) from VLAN 42 to R1.

I captured between R1 and the switch. Right before the capture, I removed the cable from R4 gi0/0, while I plugged it in again during the capture. You can use “isis” as the display filter in Wireshark. This “Integrated IS-IS” is neither a TCP/UDP nor an IP protocol. Yep, no IP addresses here. Hence Wireshark displays the source/destination MAC addresses of the Ethernet frames:

Here are my configs from the three involved routers:

And some show commands from those three routers as well:

 

GLBP

I configured the Cisco proprietary first-hop redundancy protocol Gateway Load Balancing Protocol on routers R4 and R5 to have a redundant connection to the Internet from the network in which the Raspberry Pi resides. I captured right before the Raspberry Pi and performed the following steps:

  1. started the capture
  2. booted the Raspi
  3. started pinging “netsec.blog” via v6 and v4
  4. NOW I rebooted R4 in order to have some GLBP changes

Using “glbp” as the display filter you can see both sessions for each Internet protocol. (Don’t know why the red coloring rules from Wireshark for GLBP with IPv4 kicks in. To my mind, this shouldn’t be the case. Will discuss this later.)

These are the GLBP states before the reload of R4:

Log messages from R5 during the reload of R4:

And after the reload:

Configuration and some show commands of both routers:

 

VRRP

Instead of GLBP, I used the Virtual Router Redundancy Protocol this time. Unluckily it was only available for legacy IP on my routers. Hence I used HSRP for IPv6 as well. Following procedure:

  1. Start of the capture in front of the Raspi
  2. boot of the Raspi
  3. ping “netsec.blog” via v6 and v4
  4. now: R4 reload (R5 was active for both IPs)
  5. wait (R5 was still active for both IPs)
  6. R5 reload (R4 became active, of course)
  7. wait
  8. R5 was now again active for VRRP (preempt) while not for HSRP

Display filter “vrrp”. That’s how it looks like:

(Oh no, I am not quite sure whether or not I missed some VRRP packets which are possibly direct Ethernet traffic between the two routes, as I captured on the Raspi. Shit. Ok, at least I have VRRP traffic. ;))

Syslogs at R4 during the reload of R5:

Final config and show commands:

 

CAPWAP

Again, thanks to Alexis for the packets. ;) Wireshark uses two different display filters for CAPWAP: “capwap” for the control channel on UDP port 5246 and “capwap.data” for the data on UDP port 5247:

Full Ethernet Frame Capturing

For the captures, I used my ProfiShark from Profitap. This time I enabled the “capture full frames” option which includes the Ethernet preamble, the SMD, and the CRC for each frame:

Photo by Mael BALLAND on Unsplash.

Leave a Reply

Your email address will not be published. Required fields are marked *