# BGP TTL Security, Pt. 2 (IOS-XE)

You may see BGP TTL Security referred to by its official name, GTSM (Generalized TTL Security Mechanism) from RFC 5082. GTMS, or TTL Security, uses the TTL value of a received packet to determine whether to drop the packet or accept it.

Let’s use our lab from the last article:

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FeIsVEd0dKx16hAAiBYtX%2Fimage.png?alt=media&#x26;token=c3bd6bb3-9adf-4490-b17d-16b8fbabdc89" alt=""><figcaption></figcaption></figure>

We’ll tear down the BGP session between R1 and R4, and then use TTL security so that the peering session can only be up to a maximum of 3 hops away.

```
R1#
router bgp 65000
no neighbor 4.4.4.4

R4#
router bgp 65001
no neighbor 1.1.1.1
```

**The TTL Security command takes the maximum hop counts as a parameter. BGP subtracts the configured hop count from 256, and only accepts packets if they are at least that value.**

An example will help. In this case, R1 and R4 are three hops away. We’ll configure the maximum hops as 3. 256 minus 3 = 253. So R1 and R4 will only accept the BGP packets if they have a TTL of 253 or higher.

You might wonder, why do we use 256 and not 255? A directly connected router would have a hop count of 1, and therefore the TTL would need to be exactly 255, right? So we would do 256-1=255. The router only decrements the TTL once it processes the packet and then forwards it to its next hop. We need the TTL value “on the wire” before decrementing takes place. Therefore we use 256 and not 255.

Where the TTL decrementation takes place can make this a little confusing. When the router receives a packet with 253 "on the wire", it decrements it by 1 and then technically preforms the TTL security check based on this value. However, I find it easier to understand by using 256 instead of 255. If it makes more sense to you, you can use (255 - hop count) instead of 256, but you will have to remember that the router decrements by 1 upon receiving the packet.

Let’s configure our peering session again, this time with ttl security.

```
R1#
router bgp 65000
neighbor 4.4.4.4 remote-as 65001
neighbor 4.4.4.4 update-source lo0
neighbor 4.4.4.4 ttl-security hops 3

R4#
router bgp 65001
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source lo0
neighbor 1.1.1.1 ttl-security hops 3
```

Notice that we don’t configure ebgp-multihop this time. The ttl-security feature sets the TTL to 255 automatically.

Let’s look at a pcap taken on Gi1 of R1

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FlUCaEGaztwWg2Kag6gPq%2FUntitled%201.png?alt=media&#x26;token=891aa4d8-e3f8-438d-82e1-2bd30e96fd16" alt=""><figcaption></figcaption></figure>

The TTL values are the same as in the last article when we used **ebgp-multihop** with its default 255 hop count.

The difference now is if the TTL is lower than 253, R1 will reject the BGP session.

Let’s change the hop count on R1 to 2. This should instruct R1 to only accept the BGP session if the TTL is 254 or higher.

```
R1#
router bgp 65000
 neighbor 4.4.4.4 ttl-security hops 2
```

If I clear BGP on R1, the session to R4 will **not** come up

```
R1#
debug ip tcp packets
debug bgp ipv4 unicast


*Jul 11 15:01:44.790: BGP: 4.4.4.4 open failed: Connection timed out; remote host not responding
*Jul 11 15:01:44.790: BGP: 4.4.4.4 Active open failed - tcb is not available, open active delayed 14336ms (35000ms max, 60% jitter)
*Jul 11 15:01:44.790: BGP: ses global 4.4.4.4 (0x7F410F403A20:0) act Reset (Active open failed).
*Jul 11 15:01:44.791: BGP: 4.4.4.4 active went from Active to Idle

*Jul 11 15:02:07.653: TCP0: bad seg from 4.4.4.4 -- Discard the invalid TTL packets: port 179 seq 1577333138 ack 0 rcvnxt 0 rcvwnd 16384 len 0
```

R1 tries to open the TCP session, but the TCP packets from R4 are rejected based on the TTL value.

Pop quiz: What will happen if we set both routers to a ttl-security hops of 5? Will they reject the packet because the TTL is not exaclty 251?

```
R1#
router bgp 65000
 neighbor 4.4.4.4 ttl-security hops 5

R4#
router bgp 65001
 neighbor 1.1.1.1 ttl-security hops 5
```

The neighborship comes up. This is because TTL security allows for a TTL value of *at least* (256 - hops). So as long as the TTL is 251 or above in this case, the peering session is established.

Let’s change this up even more. What will happen if we keep ttl-security hops 5 on R1, but we set R4 to use **ebgp-multihop** and remove **ttl-security**? Do you think the neighborship will still form? Pause to consider this before moving on!

```
R4#
router bgp 65001
 no neighbor 1.1.1.1 ttl-security hops 5
 neighbor 1.1.1.1 ebgp-multihop
```

```
R1#clear ip bgp *

R1#
*Jul 11 15:10:30.884: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up
```

The BGP session still comes up! The ttl-security feature is not a “negotiated” feature. It simply does a check on the packet’s TTL. By using the default ebgp-multihop hop count of 255, the packet from R4 is still originated with a TTL 255, so this passes R1’s configured ttl-security check.

So what is the difference right now when we use ebgp-multihop on R4, and ttl-security on R1? R4 is **not** inspecting the TTL value and dropping packets if they don’t have a certain TTL value.

Let’s push this a little bit further so you are solid on this feature. What is the minimum value we could use for **ebgp-multihop** on R4, with R1 still set to **ttl-security hops 5**? Pause to answer this before scrolling down.

The answer is 253.

R4 will send a packet with TTL=253. R3 decrements to 252 and sends to R2. R2 decrements to 251 and sends to R1. R1 accepts a TTL of *at least* 251.

```
R4#
router bgp 65001
 neighbor 1.1.1.1 ebgp-multihop 253

R1#clear ip bgp *

R1#
*Jul 11 15:10:30.884: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up
```

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FCvuunXPdozEDYo9PuRan%2FUntitled%202.png?alt=media&#x26;token=0952cbe7-15a8-4a64-9a82-39b3737f3993" alt=""><figcaption></figcaption></figure>

In the next section we’ll breifly look at ttl-security on IOS-XR.
