Maximum-prefix limits, TTL security (GTSM) and session authentication.
Advanced · 20 min read
You'll learn to set a maximum-prefix limit, enable TTL security for a directly connected neighbour, and combine session protections into a baseline.
Layers for different threats
How a more-specific announcement attracts traffic
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Longest-prefix match happens in forwarding, before best-path selection. Only filtering what neighbours may announce, and validating the origin AS with RPKI, stops the wrong route from being accepted in the first place.
A BGP session can go wrong in two ways: someone outside the session interferes with it, or the neighbour sends something it should not. The first needs packet-level protection. The second needs limits on what you accept.
Three threats, three defences
On small screens, swipe sideways or focus the diagram and use the arrow keys.
No single feature covers everything.
Two cheap protections for a BGP session
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Maximum-prefix limits damage from a leak. GTSM stops forged packets from far away, because only a directly connected neighbour can arrive with a TTL of 254 or more.
Limit what a neighbour can send
maximum-prefix in action
On small screens, swipe sideways or focus the diagram and use the arrow keys.
A warning at the threshold gives time to react before the session is closed.
R1. Warn at 80 percent of 100 prefixes and shut the session at 100. Pick the limit from what the provider has agreed to send, with some headroom.
Illustrative Cisco IOS XE output written for this lesson, not a router capture
R1#show logging | include MAXPFX
%BGP-4-MAXPFX: No. of prefix received from 192.0.2.1 (afi 0) reaches 81, max 100
%BGP-3-MAXPFXEXCEED: No. of prefix received from 192.0.2.1: 101 exceed limit 100
The first line is the warning at 80 percent. The second means the limit was crossed and the session was closed. Clear it only after you understand why the neighbour sent more than expected.
Protect the session from far away
TTL security (GTSM) exploits the fact that only a directly connected neighbour can send a packet that arrives with a TTL near 255. Each side sends with TTL 255 and drops packets with a lower value than expected.
Why TTL security works
On small screens, swipe sideways or focus the diagram and use the arrow keys.
ttl-security hops 1 accepts only packets that could come from the neighbour.
R1. Both ends must enable it. With hops 1 only packets arriving with TTL 254 or more are accepted. Do not combine it with ebgp-multihop on the same neighbour.
A baseline for every external neighbour
Authenticate the TCP session (MD5 or TCP-AO where supported).
On small screens, swipe sideways or focus the diagram and use the arrow keys.
A short checklist beats remembering each option.
Check your understanding
Predict · scenario 1
Which control limits the harm from a neighbour that leaks a full table?
Predict · scenario 2
Why does GTSM work against distant attackers?
Predict · scenario 3
Can you use ttl-security hops 1 together with ebgp-multihop on one neighbour?
FAQ
What happens when maximum-prefix is exceeded?
By default the session is shut down and stays down until you clear it. Options let it restart after a time, or only log a warning.
Can I use GTSM with ebgp-multihop?
No. GTSM expects the neighbour to be a known number of hops away. Use ttl-security hops N instead of ebgp-multihop for a neighbour more than one hop away.
Is a session password enough?
It stops forged segments but does not stop a neighbour from sending bad routes. Combine it with prefix limits and filters.