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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
R4 <-> R5 v6: 7, 11, 18 ipv6.addr==2003:de:2016:1ff::14 && ipv6.addr==2003:de:2016:1ff::15 Palo <-> R4 v4: 0, 13 ip.addr==192.168.255.1 && ip.addr==192.168.255.14 v6: 5, 10 ipv6.addr==2003:de:2016:1ff::1 && ipv6.addr==2003:de:2016:1ff::14 Palo <-> R5 v4: 6, 20 ip.addr==192.168.255.1 && ip.addr==192.168.255.15 v6: 2, 17 ipv6.addr==2003:de:2016:1ff::1 && ipv6.addr==2003:de:2016:1ff::15 Forti <-> R4 v4: 4, 12, 15 ip.addr==192.168.120.24 && ip.addr==192.168.120.33 v6: 8, 9, 14 ipv6.addr==2003:de:2016:120::24 && ipv6.addr==2003:de:2016:120::f02:443 Forti <-> R5 v4: 3, 19, 22 ip.addr==192.168.120.25 && ip.addr==192.168.120.33 v6: 1, 16, 21 ipv6.addr==2003:de:2016:120::25 && ipv6.addr==2003:de:2016:120::f02:443 |
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, …):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
R4#show bgp ipv4 unicast BGP table version is 53, local router ID is 192.168.255.14 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path r>i0.0.0.0 192.168.255.1 100 0 ? *>i192.168.100.0 192.168.120.33 100 0 i * i192.168.120.0 32.3.0.222 0 100 0 ? *> 0.0.0.0 0 32768 ? * i192.168.121.0 32.3.0.222 0 100 0 i *> 0.0.0.0 0 32768 i * i192.168.122.0/30 32.3.0.222 13 100 0 ? *> 192.168.121.42 13 32768 ? * i192.168.124.0 32.3.0.222 20 100 0 ? *> 192.168.121.42 20 32768 ? * i192.168.127.0 32.3.0.222 20 100 0 ? *> 192.168.121.42 20 32768 ? * i192.168.128.0/23 32.3.0.222 20 100 0 ? *> 192.168.121.42 20 32768 ? * i192.168.255.11/32 32.3.0.222 2 100 0 ? *> 192.168.121.42 2 32768 ? * i192.168.255.12/31 32.3.0.222 20 100 0 ? *> 192.168.121.42 20 32768 ? |
Anyway. Have fun. ;)
Featured image “Binoculars V” by Chase Elliott Clark is licensed under CC BY 2.0.
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
Uh, you are absolutely correct!!! Shame on me. ;)
I corrected the text and the screenshot. Thanks for that.