BGP Path Modeling
Infracast models BGP (Border Gateway Protocol) routing to give you accurate, path-level visibility into dynamic routing — not just what's in the RIB at scan time.
What we collect
When scanning supported network devices, Infracast pulls the full BGP table (equivalent to show ip bgp on Cisco or show route protocol bgp on Juniper) and extracts:
| Attribute | Description |
|---|---|
| Prefix | Destination network |
| AS-path | Sequence of AS numbers the route traversed |
| Next-hop | IP address of the next-hop router |
| Local-pref | Preference value (higher = preferred, default 100) |
| MED | Multi-Exit Discriminator (lower = preferred) |
| Origin | igp / egp / incomplete |
| Weight | Cisco-only, local to the router (higher = preferred) |
| Communities | BGP community tags |
| Status | best / backup / invalid |
For cloud BGP sessions (AWS Direct Connect VIFs, Azure ExpressRoute peerings, GCP Cloud Router), we pull advertised and received routes via cloud APIs.
Best-path selection
Infracast implements standard BGP best-path selection (RFC 4271) with vendor extensions for Cisco, Juniper, and Palo Alto. The winning path is used for reachability computation; backup paths are retained for visibility.
Graph representation
BGP paths are represented as typed edges in the topology graph, capturing prefix, AS-path, local preference, and path status. This enables reachability queries and finding rules to reason about BGP routing at the path level.
Path-tracer integration
When the path-tracer walks a route, it annotates each hop with BGP status:
- Best path: shown normally
- Backup path: shown with a "failover" indicator
- Failover paths are visible in the "Active Routing Paths" tab of path results
Finding rules
| Rule ID | Severity | Description |
|---|---|---|
NETWORK-BGP-001 | MEDIUM | BGP session established but no routes received |
NETWORK-BGP-002 | MEDIUM | Asymmetric routing detected (A→B path differs from B→A) |
NETWORK-BGP-003 | LOW | Long AS-path suggests unintended transit provider |
NETWORK-BGP-004 | HIGH | Customer prefix received from unexpected peer (route hijack indicator) |
NETWORK-BGP-005 | MEDIUM | Default route advertised by non-edge device |
Supported vendors
| Vendor | Collection method | BGP attributes |
|---|---|---|
| Cisco IOS/IOS-XE | show ip bgp via SSH | Full (weight, LP, MED, AS-path, community) |
| Juniper JunOS | NETCONF RPC or show route protocol bgp | Full (LP, MED, AS-path, community) |
| Palo Alto | XML API Virtual Router BGP table | LP, MED, AS-path, community |
| AWS Direct Connect | DescribeVirtualInterfaces API | Advertised/received prefixes, BGP ASN |
| Azure ExpressRoute | ARM API peering routes | Advertised/received prefixes, BGP peer ASN |
| GCP Cloud Router | Compute API | BGP session state, peer config |
Limitations
- Convergence simulation is not performed — we model the current best-path state, not post-failure convergence
- BGP communities are collected but not semantically interpreted (e.g., blackhole communities are noted but not acted upon)
- Full-table routers (internet edge with 900K+ prefixes) are handled via prefix aggregation —
/32s are collapsed under shorter covering prefixes for visualization