BGP TTL Security check

By default, IOS sends BGP messages to EBGP neighbors with an IP time-to-live (TTL) of 1. Sending BGP messages with a TTL of 1 requires that the peer be directly connected, or the packets will expire in transit. Likewise, a BGP router will only accept incoming BGP messages with a TTL of 1, which can help mitigate spoofing attacks.
However, a remote attacker can adjust the TTL of sent packets so that they appear to be originating from a directly-connected peer.

By spoofing legitimate-looking packets toward a BGP router at high volume, result in denial of service (DoS).

The BGP Support for TTL Security Check feature introduces a lightweight security mechanism to protect eBGP peering sessions from CPU utilization-based attacks. These types of attacks are typically brute force Denial of Service (DoS) attacks that attempt to disable the network by flooding the network with IP packets.

This feature protects the eBGP peering session by comparing the value in the TTL field of received IP packets against a hop count that is configured locally for each eBGP peering session. If the value in the TTL field of the incoming IP packet is greater than or equal to the locally configured value, the IP packet is accepted and processed normally. If the TTL value in the IP packet is less than the locally configured value, the packet is silently discarded.

The BGP peering session is not affected by incoming packets that contain invalid TTL values. The BGP peering session will remain open.

To configure this feature for an existing multihop session, you must first disable the existing peering session with the no neighbor ebgp-multihop command. The multihop peering session will be restored when you enable this feature with the neighbor ttl-security command.

Examples

The following example sets the expected incoming TTL value for a directly connected EBGP peer. The hop-count argument is set to 2 configuring BGP to only accept IP packets with a TTL count in the header that is equal to or greater than 253. If the 10.1.1.1 neighbor is more than 2 hops away, the peering session will not be accepted.

neighbor 10.1.1.1 ttl-security hops 2

Use Sh ip bgp neighbors command to check following output.

External BGP neighbor may be up to 2 hops away.

Minimum incoming TTL 253, Outgoing TTL 255

In the Peer router if you configure as ebgp-multihop 3 then it will not establish BGP neighborship. Sh ip bgp neighbors command will display following output in that Router.

External BGP neighbor may be up to 3 hops away.

Minimum incoming TTL 0, Outgoing TTL 3

Neighbor state will be stopped at OpenConfirm state. (Remote Router will be in OpenSent state.)