search

t2mune / mrtparse

MRT format data parser
Apache License 2.0
136 stars 39 forks source link

IPv4 addresses decoded as IPv6 in print_all.py #21

Closed Zahaib closed 4 years ago

Zahaib commented 4 years ago

Hi,

I used print_all.py to print the output of a MRT file from RIPE RouteCollector rrc21 (http://data.ris.ripe.net/rrc21/2020.04/updates.20200422.0125.gz). It seems that IPv4 prefixes at the end of BGP message are getting decoded as IPv6. For example, following is an example taken from the output of print_all.py:

MRT Header

 Timestamp: 1587518739(2020-04-22 01:25:39)
  Type: 16(BGP4MP)
  Subtype: 4(BGP4MP_MESSAGE_AS4)
  Length: 267
BGP4MP_MESSAGE_AS4
  Peer AS Number: 42275
  Local AS Number: 12654
  Interface Index: 0
  Address Family: 2(IPv6)
  Peer IP Address: 2001:7f8:54::1:204
  Local IP Address: 2001:7f8:54::1:99
BGP Message
  Marker: -- ignored --
  Length: 223
  Type: 2(UPDATE)
  Withdrawn Routes Length: 0
  Total Path Attribute Length: 111
  Path Attribute Flags/Type/Length: 0x40/1/1
      ORIGIN: 0(IGP)
  Path Attribute Flags/Type/Length: 0x40/2/30
      AS_PATH
          Path Segment Type: 2(AS_SEQUENCE)
          Path Segment Length: 7
          Path Segment Value: 42275 25091 57463 263444 6762 16509 14618
  Path Attribute Flags/Type/Length: 0x40/3/4
      NEXT_HOP: 85.208.68.1
  Path Attribute Flags/Type/Length: 0xc0/8/64
      COMMUNITY: 0:8304 0:49981 16:1134 6762:1 6762:31 6762:40 6762:10150 24115:57463 25091:22414 25091:24115 64700:57463 64704:1300 65400:0 65400:65400 65444:102 65444:2000
  NLRI: 305::/20
  NLRI: 305::/24
  NLRI: 305:1000::/21
  NLRI: 305:1000::/24
  NLRI: 350::/12
  NLRI: 3e0::/12
  NLRI: 3d0::/12
  NLRI: 305:400::/24
  NLRI: 305:900::/24
  NLRI: 305:1100::/24
  NLRI: 305:1200::/24
  NLRI: 305:a00::/24
  NLRI: 305:b00::/24
  NLRI: 305:700::/24
  NLRI: 305:1300::/24
  NLRI: 305:200::/24
  NLRI: 305:600::/24
  NLRI: 305:300::/24
  NLRI: 305:1500::/24
  NLRI: 305:500::/24
  NLRI: 305:800::/24
  NLRI: 305:100::/24
  NLRI: 305:1400::/24

It seems that the parser is using the AFI (IPv6) provided in the BGP4MP_MESSAGE header to decode the prefixes at the end of the BGP message whereas RFC 6396 under 4.4.2 states that:

The Address Family value only applies to the IP addresses contained in the MRT header. The BGP4MP_MESSAGE Subtype is otherwise transparent to the contents of the actual message that may contain any valid AFI/SAFI values. Only one BGP message SHALL be encoded in the BGP4MP_MESSAGE Subtype.

Zahaib commented 4 years ago

For more context, the issue here is that the peering session for this BGP update message was over IPv6 (both peer and local addresses are IPv6)

Peer IP Address: 2001:7f8:54::1:204 Local IP Address: 2001:7f8:54::1:99

However, peering session doesn't necessarily mean that NLRI will follow the same AFI. In fact, NLRI at the end of BGP message should always be decoded as IPv4. RFC4760 for multiprotocol extensions also confirms this. Under 1. Introduction first paragraph, it states that:

The only three pieces of information carried by BGP-4 [BGP-4] that
are IPv4 specific are (a) the NEXT_HOP attribute (expressed as an
IPv4 address), (b) AGGREGATOR (contains an IPv4 address), and (c)
NLRI (expressed as IPv4 address prefixes).
t2mune commented 4 years ago

Hi,

Thank you very much for reporting this issue. I fixed it, so could you confirm that it works correctly? In my environment, the result is as follows:

--- updates.20200422.0125.out.before    2020-04-24 19:23:31.974871626 +0900
+++ updates.20200422.0125.out.after 2020-04-24 19:43:59.898189564 +0900
(...snip)
@@ -1160977,29 +1160977,29 @@
         NEXT_HOP: 85.208.68.1
     Path Attribute Flags/Type/Length: 0xc0/8/64
         COMMUNITY: 0:8304 0:49981 16:1134 6762:1 6762:31 6762:40 6762:10150 24115:57463 25091:22414 25091:24115 64700:57463 64704:1300 65400:0 65400:65400 65444:102 65444:2000
-    NLRI: 305::/20
-    NLRI: 305::/24
-    NLRI: 305:1000::/21
-    NLRI: 305:1000::/24
-    NLRI: 350::/12
-    NLRI: 3e0::/12
-    NLRI: 3d0::/12
-    NLRI: 305:400::/24
-    NLRI: 305:900::/24
-    NLRI: 305:1100::/24
-    NLRI: 305:1200::/24
-    NLRI: 305:a00::/24
-    NLRI: 305:b00::/24
-    NLRI: 305:700::/24
-    NLRI: 305:1300::/24
-    NLRI: 305:200::/24
-    NLRI: 305:600::/24
-    NLRI: 305:300::/24
-    NLRI: 305:1500::/24
-    NLRI: 305:500::/24
-    NLRI: 305:800::/24
-    NLRI: 305:100::/24
-    NLRI: 305:1400::/24
+    NLRI: 3.5.0.0/20
+    NLRI: 3.5.0.0/24
+    NLRI: 3.5.16.0/21
+    NLRI: 3.5.16.0/24
+    NLRI: 3.80.0.0/12
+    NLRI: 3.224.0.0/12
+    NLRI: 3.208.0.0/12
+    NLRI: 3.5.4.0/24
+    NLRI: 3.5.9.0/24
+    NLRI: 3.5.17.0/24
+    NLRI: 3.5.18.0/24
+    NLRI: 3.5.10.0/24
+    NLRI: 3.5.11.0/24
+    NLRI: 3.5.7.0/24
+    NLRI: 3.5.19.0/24
+    NLRI: 3.5.2.0/24
+    NLRI: 3.5.6.0/24
+    NLRI: 3.5.3.0/24
+    NLRI: 3.5.21.0/24
+    NLRI: 3.5.5.0/24
+    NLRI: 3.5.8.0/24
+    NLRI: 3.5.1.0/24
+    NLRI: 3.5.20.0/24
Zahaib commented 4 years ago

Thanks for the update, I took a look at your change and it looks good to me. I can also confirm that IPv4 are now getting decoded correctly.