BGP AS Path Policy Checker
Audit pasted BGP route paths for policy conflicts and trace each pass, watch or reject verdict before changing production router filters.{{ summaryTitle }}
| Prefix | Source | AS path | Length | Verdict | Regex result | Operator action | Copy |
|---|---|---|---|---|---|---|---|
| {{ row.prefix }} | {{ row.source }} | {{ row.as_path }} | {{ row.length }} | {{ row.verdict }} | {{ row.regex_result }} | {{ row.operator_action }} |
| Prefix | Severity | Check | Evidence | Next action | Copy |
|---|---|---|---|---|---|
| {{ row.prefix }} | {{ row.severity }} | {{ row.check }} | {{ row.evidence }} | {{ row.next_action }} |
| Sequence | Action | Pattern | Matches | State | Copy |
|---|---|---|---|---|---|
| {{ row.sequence }} | {{ row.action }} | {{ row.pattern }} | {{ row.matches }} | {{ row.state }} |
The chart renderer is unavailable. Route verdicts and policy findings remain available in the tables.
A Border Gateway Protocol (BGP) route carries an AS path showing the autonomous systems attached to that route. In the route-table form operators usually read, the left side is closest to the observing neighbor or collector and the rightmost autonomous system number (ASN) is treated as the origin for a plain AS sequence.
The path is evidence about routing policy, not merely a length. An unexpected origin can indicate a leak, misconfiguration, or changed upstream relationship. A private-use or reserved ASN in public-route evidence may show that an internal value escaped. Repeated ASNs can be intentional traffic engineering, while an unexpected first hop can mean the sample came from the wrong vantage point or import policy.
| Policy question | Evidence used | Common caution |
|---|---|---|
| Did the expected network originate the route? | Rightmost parsed ASN | AS_SET aggregation is not covered. |
| Did the route arrive through the expected neighbor? | Leftmost parsed ASN | The answer depends on the collector's direction. |
| Does every transit ASN belong in this policy? | Whole AS sequence | An allowlist must include legitimate transit ASNs. |
| Did a special or private ASN leak? | Whole AS sequence | Lab and private routing can use those values intentionally. |
| Did the route match an ordered policy? | First matching regex rule | A permit match does not override other reject checks. |
Path length is an operator-defined warning or rejection condition, not a universal measure of route quality. A longer path may be legitimate, and a short path can still have the wrong origin. Likewise, prepending repeats one ASN to make a route less attractive to some neighbors; the repeat count only becomes suspicious when it exceeds the policy chosen for that review.
Policy checks should use route rows from a known vantage point and a policy written for that context. A customer edge, route server, upstream router, and public collector can display different leftmost ASNs for the same prefix. Mixing views can create false first-hop findings even when the underlying route is normal.
An AS-path review does not validate Route Origin Authorizations (RPKI), Internet Routing Registry objects, prefix ownership, reachability, local preference, communities, or what a router will install. It is a pre-change or incident-review aid that should be paired with live device and origin-validation evidence.
How to Use This Tool:
Start with pasted routes from one known observation point, then enable only the policy checks that apply to that view.
- Paste one route per line in Observed BGP routes. Plain sequences, CSV or pipe-delimited rows, and common BGP table lines are accepted; AS_SET syntax is not.
- Use Allowed ASNs only when every permitted transit and origin ASN is known. Leave the field blank to skip the whole-path allowlist.
- Set Expected origin ASNs, review Blocked or special ASNs, and choose a Maximum path length that fits the operator policy.
- Add ordered permit and deny regex rules when pattern policy matters. Correct any invalid ASN token or expression before relying on the audit.
- Open Advanced for an expected first hop or a prepend watch threshold. A threshold of 0 disables prepend checking.
- Review each Route verdict with its Policy findings and Rule trace. Confirm the source view and raw route on the target router before applying a policy change.
Interpreting Results:
- Pass means no enabled reject or watch condition fired for that parsed sequence. It does not certify the route as legitimate.
- Watch means the longest consecutive run of one ASN is greater than the nonzero prepend threshold and no reject condition fired.
- Reject means at least one parse, length, allowlist, blocked-ASN, origin, first-hop, or regex-deny rule failed. Multiple findings can apply to the same route.
- A regex permit affects only the regex check. Blocked ASNs, an unexpected origin, or another reject condition still produces Reject.
Technical Details:
The parser extracts ordered ASN values from up to 200 non-empty route rows. It accepts plain decimal ASN values, an optional AS prefix, and asdot notation. Common next-hop addresses, route-table numeric fields, and trailing origin codes are removed before the AS sequence is evaluated.
Rule Core:
Each route follows the same decision order. The checks accumulate evidence rather than stopping at the first problem, and any reject finding overrides a watch finding.
| Check | Condition | Effect |
|---|---|---|
| Parse | No ASN is found | Reject |
| Maximum length | Parsed count > configured maximum | Reject; equality passes |
| Whole-path allowlist | Any ASN is outside the configured exact values or inclusive ranges | Reject |
| Blocked list | Any ASN is inside a configured exact value or inclusive range | Reject |
| Origin | Rightmost ASN is outside the configured expected set | Reject |
| First hop | Leftmost ASN is outside the configured expected set | Reject |
| Regex | First matching ordered rule selects deny | Reject |
| Prepending | Enabled threshold > 0 and longest adjacent run > threshold | Watch unless another check rejects |
ASN policies accept comma-, space-, or semicolon-separated values and inclusive ranges. Values run from 0 through 4294967295. The default blocked list includes reserved, documentation, transition, and private-use values, but it is an operator policy rather than a universal ban. For example, private-use ASNs are expected in some labs and private fabrics.
Regex rules use a JavaScript-compatible expression after the permit or deny action. An underscore is translated to an AS boundary, so _23456_ matches AS23456 as a complete path element rather than as digits inside a larger ASN. The first matching rule wins. The configured default applies only when at least one valid regex rule exists and all of them miss; with no regex policy, the regex check permits by default.
The final verdict is Reject when any reject finding exists, Watch when no rejection exists but a prepend finding does, and Pass otherwise. The length profile groups those final verdicts by exact parsed ASN count.
Accuracy Notes:
All parsing and policy evaluation stays in the browser; no router session or external route lookup is performed. Keep these boundaries in mind:
- Only flattened AS sequences are evaluated. AS_SET segments and full wire-format path segment semantics are outside the parser.
- The rightmost-AS origin rule is appropriate for a final AS_SEQUENCE, but aggregate paths containing AS_SET do not have the same determinate origin.
- Common route-table formats are recognized heuristically. Compare normalized rows with the source before trusting a large pasted batch.
- The checker does not know which ASN ranges are appropriate for a particular private, lab, or public context. Review the blocked list instead of accepting its sample defaults blindly.
- Use RPKI origin validation and live routing data for authorization and current-state questions.
Worked Examples:
Permit rule with a blocked transit ASN
The path 6939 65001 15169 ends at the expected origin, but AS65001 falls outside an allowlist containing only AS6939, AS3356, and AS15169 and also matches the sample private-use block. Even if a permit regex matched, the route would still be rejected because independent reject findings take precedence.
Prepend exactly at the boundary
With a prepend watch threshold of 3, the path 6939 3356 3356 3356 15169 has a longest run of 3 and does not trigger the watch. A fourth adjacent AS3356 makes the run 4, which is greater than the threshold and produces Watch unless another policy check rejects the route.
References:
- RFC 4271: A Border Gateway Protocol 4 (BGP-4), IETF, January 2006.
- RFC 6483: Validation of Route Origination Using the Resource Certificate PKI and ROAs, IETF, February 2012.
- RFC 6996: Autonomous System Reservation for Private Use, IETF, July 2013.
- Special-Purpose Autonomous System Numbers, IANA.
- How to query an ASN with whois, Simplified Guide.