{{ summaryTitle }}
{{ summaryValue }}
{{ summaryLine }}
Pass {{ resultsReady ? computation.values.pass_count : '—' }} Watch {{ resultsReady ? computation.values.watch_count : '—' }} Reject {{ resultsReady ? computation.values.reject_count : '—' }}
{{ summaryAnnouncement }}
BGP AS path policy inputs
The checker reads the ordered AS sequence locally. Aggregated AS_SET syntax is outside this parser.
CSV, pipe-delimited, and common router table rows are parsed in your browser.
Use ASNs, commas, spaces, or ranges such as 64512-64520. Leave blank to skip the whole-path allowlist.
Use this to identify origin drift in the pasted route view. Leave blank to skip the origin check.
Adjust this operator policy for lab or private routing contexts before relying on the verdict.
Whole-number ceiling from 1 to 255 ASNs.
ASNs
Examples: permit ^6939_3356_15169$ and deny _23456_. Invalid expressions stop the audit.
Use deny for a strict allow-policy or permit when regex rules define exceptions.
The neutral blank default skips this collector-direction check.
The neutral default is 0, which disables this advisory check.
repeats
{{ tableExportStatus }}
PrefixSourceAS pathLengthVerdictRegex resultOperator actionCopy
{{ row.prefix }}{{ row.source }}{{ row.as_path }}{{ row.length }}{{ row.verdict }}{{ row.regex_result }}{{ row.operator_action }}
{{ tableExportStatus }}
PrefixSeverityCheckEvidenceNext actionCopy
{{ row.prefix }}{{ row.severity }}{{ row.check }}{{ row.evidence }}{{ row.next_action }}
{{ tableExportStatus }}
SequenceActionPatternMatchesStateCopy
{{ row.sequence }}{{ row.action }}{{ row.pattern }}{{ row.matches }}{{ row.state }}
{{ chartExportStatus }}

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.

BGP AS path questions and the part of the path used to answer them
Policy question Evidence used Common caution
Did the expected network originate the route?Rightmost parsed ASNAS_SET aggregation is not covered.
Did the route arrive through the expected neighbor?Leftmost parsed ASNThe answer depends on the collector's direction.
Does every transit ASN belong in this policy?Whole AS sequenceAn allowlist must include legitimate transit ASNs.
Did a special or private ASN leak?Whole AS sequenceLab and private routing can use those values intentionally.
Did the route match an ordered policy?First matching regex ruleA 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.

  1. 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.
  2. Use Allowed ASNs only when every permitted transit and origin ASN is known. Leave the field blank to skip the whole-path allowlist.
  3. Set Expected origin ASNs, review Blocked or special ASNs, and choose a Maximum path length that fits the operator policy.
  4. Add ordered permit and deny regex rules when pattern policy matters. Correct any invalid ASN token or expression before relying on the audit.
  5. Open Advanced for an expected first hop or a prepend watch threshold. A threshold of 0 disables prepend checking.
  6. 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.

BGP AS path policy rules and exact boundary behavior
Check Condition Effect
ParseNo ASN is foundReject
Maximum lengthParsed count > configured maximumReject; equality passes
Whole-path allowlistAny ASN is outside the configured exact values or inclusive rangesReject
Blocked listAny ASN is inside a configured exact value or inclusive rangeReject
OriginRightmost ASN is outside the configured expected setReject
First hopLeftmost ASN is outside the configured expected setReject
RegexFirst matching ordered rule selects denyReject
PrependingEnabled threshold > 0 and longest adjacent run > thresholdWatch 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.