MP-BGP Capture

For those who are interested in analyzing basic BGP messages: I have a trace file for you. ;) It consists of two session establishments as I cleared the complete BGP session on two involved routers for it. Refer to my previous blog post for details about the lab, that is: MP-BGP with IPv6 and legacy IP, neighbouring via both protocols as well, with and without password. The involved routers were 2x Cisco routers, one Palo Alto Networks firewall, and one Fortinet FortiGate firewall.

Again, refer to my earlier blog post about all details for the lab itself. Here you can download the pcap file (zipped):

I captured it on the switch ports connecting to R4 and R5. Hence all BGP sessions from/to those two routers are present in the trace file, while the connection between the Palo Alto and the FortiGate is NOT included. During the capture I cleared all BGP sessions on routers R4 and R5:

  • At 16:43:46 UTC: R4#clear bgp all 64512
  • At 16:45:32 UTC: R5#clear bgp all 64512

In order to use the display filter in Wireshark you can either use the tcp.stream eq <nr> or any pairs of IP addresses. Here is a list of all communication partners with their TCP stream indices as well as their IP filters:

 

For example, looking at TCP stream 10 you have the BGP session establishment for IPv6 between R4 and the Palo Alto firewall:

 

Note the MD5 hash/digest used for authentication within the TCP (and not BGP) messages. After looking at the RFC (2385) I found it within the TCP header itself. If the “TCP MD5 signature” is not present, a BGP neighborship is not formed. That is, even the three-way handshake does not succeed. Here you can see this option in the very first SYN packet:

 

The Wireshark version at the time of writing (2.4.4) marks many BGP NLRI path attributes as invalid. I am not quite sure why. I can see some of my IPv6 addresses in it, so I suppose a protocol decoding error within Wireshark (?):

[UPDATE 07.11.2018] In the meantime the Wireshark dissector for BGP was fixed to support those NLRI attributes, as you can see in the following screenshot (Wireshark development version 2.9.0-2392-g98e4aedf):

Also, note that I have some problems understanding the BGP messages for “address-family ipv4” over an IPv6 neighborship. While the NLRI shows a correct IPv4 network, the next-hop value lists an unknown IPv4 address which looks like the first two hextets out of my IPv6 addresses. Curious:

I am too lazy to read the whole RFCs right now. Maybe someone can help me out? At least the same wrong looking IPv4 addresses are displayed in the Cisco router, too (lines 10, 12, 14, …):

 

[UPDATE] During the Troopers 18 conference in Heidelberg, Germany, I asked Ivan Pepelnjak himself about this issue. It turned out that this is kind of a bug in IOS. Or a workaround. The neighbouring router must know the ARP entry / MAC address of the next-hop router. Probably Cisco tries to fake this entry by using some extra functionality. In any case, the NLRI part of the BGP update should contain the 32 bit IPv4 address and it simply uses the first 32 bit out of the IPv6 addresses. I was kind of lucky that I did not run into issues with those routes since they were never the best ones. All IPv4 routes were installed from other iBGP neighbours and never from the Cisco neighborship. Anyway, Ivan strictly advised me to use IPv6 neighbours for only IPv6 routes, and IPv4 neighbours for only IPv4 routes, which is different from the CCNP books that describe this single neighborship as an advantage.[/UPDATE]

Anyway. Have fun. ;)

For more posts about routing/switching you can follow the Routing” or “Switching” categories concerning various firewall/router vendors, or the “Cisco Router“/”Cisco Switch” tags for posts related to Cisco stuff.

Featured image “Binoculars V” by Chase Elliott Clark is licensed under CC BY 2.0.

2 thoughts on “MP-BGP Capture

  1. Hi Johannes,

    small correction from my side. The next hop address in your Wireshark trace, which you referred to as the first 8 hextets of your IPv6 address, is not really 8 hextets. In fact, a hextet is by definition 16 bits according to Wikipedia.
    So they are the first two hextets of the IPv6 address (4 bytes -> 2×16).

    Other than thant, thanks for posting the Wireshark capture!

    Grüße
    Wassim

Leave a Reply

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