Route Leaking
Recognize export beyond an intended business boundary and enforce the appropriate route scope.
Start with routing relationships
R2 and R3 buy transit from R1, peer with each other, and serve their own downstream customers. These are business roles between ASes, not different BGP session states. A network may be a customer on one connection and a provider on another.
| Learned route source | Typical permitted export |
|---|---|
| Own or authorized customer route | Customers, peers and providers under the agreed policy. |
| Peer route | Customers; not another peer or provider. |
| Provider route | Customers; not another peer or provider. |
The table describes a common valley-free policy model, not every possible commercial agreement. Explicit contracts and exceptions determine the intended scope.
Distinguish the leak patterns
| RFC 7908 category | Example failure |
|---|---|
| Type 1: hairpin | A multi-homed customer announces one provider’s route to another. |
| Type 2: lateral | A peer-learned route is exported onward to another peer. |
| Type 3: provider to peer | Transit-provider routes are exported to a peer. |
| Type 4: peer to provider | Peer-learned routes are exported to a transit provider. |
| Type 5: re-origination | A route is re-originated while a data path still leads to the legitimate origin. |
| Type 6: internal/more-specific leak | Internal or unintended more-specific prefixes escape their boundary. |
A leak can retain a correct origin AS. Origin validation alone therefore cannot identify every leak. A route hijack and a route leak can overlap, but are not interchangeable terms.
Reproduce a customer hairpin in isolation
Use a separate three-router test: R1 is the customer, R2/ISP1 and R3/ISP2 are providers. The downloadable baseline originates one customer /24 and one test /25 at each provider. Without customer export filters, each provider learns the other’s /25 through R1.
Complete baseline configurations
R1
hostname R1
ip cef
interface Loopback0
ip address 10.255.0.1 255.255.255.255
exit
interface Loopback10
ip address 198.51.100.1 255.255.255.0
exit
interface GigabitEthernet1
ip address 192.0.2.1 255.255.255.252
no shutdown
exit
interface GigabitEthernet2
ip address 192.0.2.5 255.255.255.252
no shutdown
exit
router bgp 65001
bgp router-id 10.255.0.1
no bgp default ipv4-unicast
neighbor 192.0.2.2 remote-as 65002
neighbor 192.0.2.6 remote-as 65003
address-family ipv4 unicast
no auto-summary
neighbor 192.0.2.2 activate
neighbor 192.0.2.6 activate
network 198.51.100.0 mask 255.255.255.0
exit-address-family
endR2
hostname R2
ip cef
interface Loopback0
ip address 10.255.0.2 255.255.255.255
exit
interface Loopback10
ip address 203.0.113.1 255.255.255.128
exit
interface GigabitEthernet1
ip address 192.0.2.2 255.255.255.252
no shutdown
exit
router bgp 65002
bgp router-id 10.255.0.2
no bgp default ipv4-unicast
neighbor 192.0.2.1 remote-as 65001
address-family ipv4 unicast
no auto-summary
neighbor 192.0.2.1 activate
network 203.0.113.0 mask 255.255.255.128
exit-address-family
endR3
hostname R3
ip cef
interface Loopback0
ip address 10.255.0.3 255.255.255.255
exit
interface Loopback10
ip address 203.0.113.129 255.255.255.128
exit
interface GigabitEthernet1
ip address 192.0.2.6 255.255.255.252
no shutdown
exit
router bgp 65003
bgp router-id 10.255.0.3
no bgp default ipv4-unicast
neighbor 192.0.2.5 remote-as 65001
address-family ipv4 unicast
no auto-summary
neighbor 192.0.2.5 activate
network 203.0.113.128 mask 255.255.255.128
exit-address-family
endR2# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 203.0.113.128/25 192.0.2.1 0 0 65001 65003 iContain exports explicitly
ip prefix-list OWN-ONLY seq 5 permit 198.51.100.0/24router bgp 65001
address-family ipv4 unicast
neighbor 192.0.2.2 prefix-list OWN-ONLY out
neighbor 192.0.2.6 prefix-list OWN-ONLY out
exit-address-familyR1# clear ip bgp 192.0.2.2 soft out
R1# clear ip bgp 192.0.2.6 soft outR2# show ip bgp 203.0.113.128/25
% Network not in tableR1# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 203.0.113.0/25 192.0.2.2 0 0 65002 i
*> 203.0.113.128/25 192.0.2.6 0 0 65003 iThe customer still uses imported routes, but no longer offers transit between its providers. Prefix allowlists, appropriate communities and customer-cone policy can work together. Maximum-prefix is a useful volume guard, not proof that every permitted announcement has the right scope.
Layer detection and prevention
Monitor unexpected origin/path changes, new more-specifics, exported customer cones and peer route counts. IRR as-set objects can help generate authorized customer policy; they are not the deprecated AS_SET segment inside a BGP UPDATE. BGP Roles and the Only-To-Customer attribute can detect or contain some policy violations when supported and correctly deployed. ASPA addresses provider-relationship authorization, while RPKI ROAs authorize origins. These mechanisms answer different questions.
Deploy explicit import/export policy rather than assuming a session’s existence implies authorization. Standards specify default-reject behavior for external sessions without policy, but actual image defaults must be checked. Keep the corrected allowlist as the final state of this defensive lab.
Key Takeaways
- A leak advertises routes beyond intended scope.
- Customer, peer and provider are per-relationship roles.
- Correct-origin routes can still be leaked.
- IRR as-set and on-wire AS_SET are different concepts.
- Explicit export policy is a primary containment control.
Protocol and command references
Route-leak taxonomy · Roles and OTC · Default external policy · Router-symbol attribution.