PacketLab
BGP · Convergence and Security

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.

Lab topologyPhysical links
.1 / .2.5 / .6.9 / .10.13 / .14.17 / .18.21 / .22.25 / .26R1Transit providerR2Provider / peerR3Provider / peerR4CustomerR5CustomerR6CustomerR7Customer
Solid lines are physical links. Endpoint labels are the last octets of 192.0.2.x/30, first router then second router in the address table. Loopback0 is 10.255.0.N/32 on RN. Logical BGP peers are listed in the configurations.
Learned route sourceTypical permitted export
Own or authorized customer routeCustomers, peers and providers under the agreed policy.
Peer routeCustomers; not another peer or provider.
Provider routeCustomers; 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 categoryExample failure
Type 1: hairpinA multi-homed customer announces one provider’s route to another.
Type 2: lateralA peer-learned route is exported onward to another peer.
Type 3: provider to peerTransit-provider routes are exported to a peer.
Type 4: peer to providerPeer-learned routes are exported to a transit provider.
Type 5: re-originationA route is re-originated while a data path still leads to the legitimate origin.
Type 6: internal/more-specific leakInternal 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.

Lab topologyPhysical links
.1 / .2.5 / .6R1AS 65001R2AS 65002R3AS 65003
Solid lines are physical links. Endpoint labels are the last octets of 192.0.2.x/30, first router then second router in the address table. Loopback0 is 10.255.0.N/32 on RN. Logical BGP peers are listed in the configurations.
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
end

R2

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
end

R3

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
end

Open plain-text configurations

Outputs are illustrative, not recorded router results. Each lab starts from its own baseline. Configuration and feature support vary by image and release; platform-specific examples identify their prerequisites.
R2# show ip bgp
     Network          Next Hop        Metric LocPrf Weight Path
*>   203.0.113.128/25 192.0.2.1            0             0 65001 65003 i

Contain exports explicitly

ip prefix-list OWN-ONLY seq 5 permit 198.51.100.0/24
router 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-family
R1# clear ip bgp 192.0.2.2 soft out
R1# clear ip bgp 192.0.2.6 soft out
R2# show ip bgp 203.0.113.128/25
% Network not in table
R1# 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 i

The 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.

Route Leaking Quiz

Six questions · four options each · select one answer per question. Submit all answers to see your score and explanations.

1. Which event is a customer hairpin leak?
2. Can an RPKI Valid route still be leaked?
3. Where may provider-learned routes normally be exported in this role model?
4. Does maximum-prefix verify export scope?
5. Is an IRR as-set the on-wire AS_SET path segment?
6. What does the lab allowlist retain for export?
Protocol and command references

Route-leak taxonomy · Roles and OTC · Default external policy · Router-symbol attribution.