BGP

Overview

The BGP view shows a table with prefixes we receive from you, or that we believe originate on your network.

The IRR column displays the status of Google's IRR validation for this prefix, as seen in your announcements to us at peering. The validation status only takes into account the announcements at peering sessions with your network. The validation status does not take into account announcements received at BGP sessions with GGC nodes or received indirectly at peering from an upstream ASN.

No Route Object: Prefixes that we don't see any Route/Route6 objects for.
No AS-SET Relationship: Prefixes that we see a Route/Route6 object for, but for which we do not see a link of AS-SET records connecting from your peer ASN to the origin ASN.
IRR Not Checked: We did not check this prefix for IRR validation because we do not see this prefix announced directly at peering from one of your peer ASNs.

The RPKI column displays the status of Google's RPKI validation for this prefix. The validation status does not take into account announcements received at BGP sessions with GGC nodes, but it does show a status for prefixes received indirectly at peering.

Invalid RPKI: Prefixes that the origin ASN or prefix length in the RPKI ROA does not match the route announcement we observe.
Unknown RPKI: Prefixes that we do not see any RPKI ROA at all for.
RPKI Not Checked: We did not check this prefix for RPKI validation because we do not see it at peering (only GGC).

The Other Problems column displays warnings per-prefix if it has one or more of the following issues:

Transit Only: Prefixes that Google believes you’re the origin for, but you’re not announcing at any GGC nodes or peering.
Transit Most Specific: Prefixes that Google believes you’re the origin for, but you’re announcing them more specifically over transit than at GGCs or peering.
Inconsistent GNL: Prefixes that aren’t being announced uniformly across all nodes in a Google Network Location (GNL).
Too Specific: Prefixes that are too specific.

The Received By column shows a chip for each session where we directly receive a prefix advertisement:

One or more chips per GGC node (click to expand).
An additional chip, Peering, appears if Google receives the prefix at a non-GGC peering session with one of your ASNs.

The Origin column displays "yes" if Google calculates that the prefix originates at your network.

The Previous Hops column shows an unordered list of the previous hops from the advertisements we see for the prefix. These are the upstreams directly before your network in the ASPATHs we see advertised.

You can filter the list of prefixes: by asset, by AS hop, or by problem type.

IRR Filtering Details

The IRR Filtering Details tab shows details about the IRR validation status of individual prefixes. We display all of the Route/Route6 objects that we see for the prefix, as well as sections with AS-SET objects for each peer ASN where we see your network advertising a given prefix. We also display details about issues causing a prefix to be invalid.

In order for a prefix to be valid, each peer ASN where you announce the prefix must have a link between your top-level AS-SET (named in PeeringDB) to the origin ASN seen in *any* of the Route/Route6 records for the prefix. This page shows any issues we see with that AS-SET Relationship:

AS-SET Found in PeeringDB: For each peer ASN, we check PeeringDB (peeringdb.com/asn/<asn>) to see what your top-level AS-SET name should be (the value in the "IRR as-set/route-set" field). We show this problem if we don't see any value at all for this field.
PeeringDB AS-SET Format Valid: We check our internal IRR validation source for the top-level AS-SET that we have associated with each of your peer ASNs. If we find an AS-SET record name in PeeringDB for your ASN, but we don't have any AS-SET associated with that ASN internally, then the AS-SET record name in PeeringDB is not formatted correctly. A common mistake is to have an AUT-NUM record name listed in PeeringDB, e.g. "AS1234", which is not a valid AS-SET name.
AS-SET Relationship Valid: We check for any of the origin ASN(s) of each prefix (from all of the Route/Route6 IRR records) in the 'members' field of your top-level AS-SETs. We recursively expand AS-SET names listed in the 'members' field when searching for the origin ASN. We show this problem when we can't find the origin ASN starting from your top-level AS-SET.

RPKI Filtering Details

The RPKI Filtering Details tab shows details about the RPKI validation status of individual prefixes. We display all of the RPKI Route Origin Authorizations (ROAs) that we see for the prefix, as well as sections with details about issues causing a prefix to be invalid for each origin ASN we see your network advertising for a given prefix.

In order for a prefix to be valid, each origin ASN in your announcements for the prefix must have a ROA with a max prefix length that covers the prefix, as well as an origin ASN which matches between the ROA and your advertisement. This page shows any issues we see with those ROAs:

ROA Found in RPKI Sources: We look for ROAs which could cover the given prefix, regardless of the max prefix length in the ROA. We show this problem if we can't find any ROA for the prefix, even one with an invalid max prefix length.
ROA Max Prefix Length: We check each ROA we find for a valid max prefix length value which would allow it to cover the given prefix. For example, a ROA for prefix 1.1.1.0/24 with a max length of /30 would be valid for a given prefix of 1.1.1.0/28.
ROA Origin ASN: For each origin ASN we see in your announcements, we check each ROA we find for a matching origin ASN. We show this problem when we can't match the origin ASN from any one of your announcements to an origin ASN in any of the ROAs we see covering the given prefix.

Was this helpful?

How can we improve it?