A prefix can appear in the global BGP table and still have a routing problem. The route may originate from the wrong ASN. Its ROA may also authorize a shorter prefix but reject the advertised prefix length. Checking each part normally means pulling data from several routing tools.
The J2SW Prefix Advertisement Checker, my 3rd application in the network series, checks the exact prefix against live routing data and reports the origin ASN seen by RIPE RIS collectors. The results also include RPKI status and matching IRR route objects.
Three Apps for Network Engineers
The first app was the MTU and Encapsulation Calculator. It calculates the packet and frame sizes left after adding PPPoE, GRE, VXLAN, MPLS, or IPsec overhead.
The second was the BGP Community Builder. It takes documented provider communities and generates scoped policy fragments for MikroTik RouterOS 7 and Cisco IOS-XE. It also supports Juniper Junos and FRRouting.
The Prefix Advertisement Checker handles the other side of BGP operations. It checks what collectors see after a prefix has been advertised. A route can pass the visibility check while still failing its origin or RPKI check.
How to Check a Prefix
Enter an IPv4 or IPv6 prefix in CIDR notation (ie 1.1.1.0/24). The application will correct the address to the correct network boundary, so an entry such as 1.1.1.4/24 is checked as 1.1.1.0/24.
The expected origin ASN is optional. If you enter it, the application compares that ASN with the origin seen in BGP. A prefix-only lookup still returns the observed origin. This works well when you are investigating a route and do not know which ASN currently originates it.
BGP Visibility and Collector Agreement
The BGP check looks for the exact prefix across RIPE RIS collectors. It reports how many collectors currently see the route and lists the origin ASN found in their data. Sample AS paths provide another view of how the advertisement is reaching the collectors. A route seen across many collectors has wider reach, although individual networks may still filter it.
The checker does not treat a covering route as proof that the exact prefix is advertised. If you enter a /24, it looks for that /24. A visible covering aggregate does not make the more-specific route visible.
RPKI and ROA
The RPKI result reports whether the origin and prefix length match a published ROA. A valid result means the ROA authorizes that ASN to originate the route at its current prefix length.
An invalid result can come from the wrong origin ASN. It can also come from the ROA maximum length. For example, a ROA for a /23 does not authorize a /24 unless its maximum length permits the more-specific route.
A route with no ROA returns a not-found state instead of valid or invalid. The prefix may still propagate across the Internet, but networks using strict RPKI-based filtering have no authorization record to validate against.
Checking IRR Route Objects
The IRR section looks for route or route6 objects matching the exact prefix. It reports the registered origin and the database containing the object. Multiple records may appear when the prefix exists in more than one IRR database.
J2SW Prefix Advertisement Checker
j2networks family of siteshttps://j2sw.com
https://startawisp.info
https://indycolo.net
#packetsdownrange #routethelight
Discover more from Justin Wilson (j2sw)
Subscribe to get the latest posts sent to your email.