The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

Understanding BGP TTL Security

By stretch | Monday, November 23, 2009 at 8:08 a.m. UTC

By default, IOS sends BGP messages to EBGP neighbors with an IP time-to-live (TTL) of 1. (This can be adjusted with ebgp-multihop attached to the desired neighbor or peer group under BGP configuration.) Sending BGP messages with a TTL of one 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 (or whatever value is specified by ebgp-multihop), which can help mitigate spoofing attacks.

However, there is an inherent vulnerability to this approach: it is trivial for a remote attacker to adjust the TTL of sent packets so that they appear to originating from a directly-connected peer.


By spoofing legitimate-looking packets toward a BGP router at high volume, a denial of service (DoS) attack may be accomplished.

A very simple solution to this, as discussed in RFC 5082, is to invert the direction in which the TTL is counted. The maximum value of the 8-bit TTL field in an IP packet is 255; instead of accepting only packets with a TTL set to 1, we can accept only packets with a TTL of 255 to ensure the originator really is exactly one hop away. This is accomplished on IOS with the TTL security feature, by appending ttl-security hops <count> to the BGP peer statement.


Only BGP messages with an IP TTL greater than or equal to 255 minus the specified hop count will be accepted. TTL security and EBGP multihop are mutually exclusive; ebgp-multihop is no longer needed when TTL security is in use.

Posted in Routing, Security


November 23, 2009 at 8:49 a.m. UTC

Nice tips !! Did not know that it was possible :)

thanks Jeremy

November 23, 2009 at 12:57 p.m. UTC

I've got to give this a try

November 23, 2009 at 3:12 p.m. UTC

Its a shame this is a Cisco proprietary command since its such a wonderful security feature. And FYI For everyone, it does require IOS Version >= 12.3(7)T

November 23, 2009 at 4:39 p.m. UTC

In fact you should use ttl = 2 when your source of bgp update is a loopback interface.

November 23, 2009 at 5:59 p.m. UTC

It is a very nice explanation. I never understood the difference between ebgp-multihop and ttl-security featues...Thanks

November 23, 2009 at 8:17 p.m. UTC

I'd like to implement this today as well!

November 24, 2009 at 8:24 p.m. UTC

Should this "whatever value is specified by ebgp-multihop" read "whatever value is specified by ebgp-multihop or lower"?

November 25, 2009 at 12:18 a.m. UTC

Just to make sure I understand this... and I've never used or read about ttl security hop but understand and use ebgp-multihop.

Formula would be: TTL ≤ 255-h

h = actual hops

November 25, 2009 at 5:41 a.m. UTC

cool post, I didn't know what this feature is for. Simple and very nice explanation.

November 25, 2009 at 2:22 p.m. UTC

spot on, thanks for all this useful info that you give away with each of your posts.

you blog has really made me a better administrator.

thanks a ton!

Didzis Ozolins
September 12, 2010 at 4:30 p.m. UTC

As of 2007, there is new RFC 5082 describing the TTL-Security feature. The RFC You mentioned is obsolete although the idea stays the same. Just thought it would be a good idea to correct this because at the time you wrote the article, new RFC was already out ;)

September 13, 2010 at 4:41 p.m. UTC

Presumably this has to be configured on both peers to work, correct? Otherwise one side would still try to set the TTL to 1?

February 14, 2011 at 2:53 p.m. UTC

Why it would be more difficult for an attacker to craft a BGP packet to have 255 of ttl than to have a TTL of 1?

February 14, 2011 at 2:57 p.m. UTC

255 is the highest possible value for the TTL field, which is eight bits in length. It is illegal for a router to forward an IP packet to a new hop without decrementing the TTL value by one. Therefore, it can be deduced that any packet with a TTL of 255 was originated on the local segment.

November 4, 2011 at 5:02 a.m. UTC

Is there a debug cmd to verify the received TTL on a packet?

April 5, 2012 at 8:52 p.m. UTC

There are so many people that are confused on this subject. This helped me diagnose but was a little hard to put together (or just the way it read to me). In using his example...I would put the command "neighbor x.x.x.x ttl-security hops 254" presuming that I wanted the router to drop anything less than 254. This is NOT the case and can be proven with "show ip bgp nei | inc TTL" after the adjacency comes up. It actually states the expected hop count.

If the neighbor is directly connected...the right command is "neighbor x.x.x.x ttl-security hops 1" <--indicating that starting from expect that the TTL at your router will be 254 or greater. So I have grown to think of the command as the hops number is the distance away from the neighbor...not the TTL you expect to enter the router.

Awesome diagramming and explanation. After made more sense to me. Appreciate what you do.

May 8, 2012 at 12:48 a.m. UTC

I read the official documentation on Cisco:

After reading it I was still a little confused. I read Jeremy's description and it made perfect sense. Thank you

November 25, 2013 at 11:35 p.m. UTC

@Aves, yes, you need to configure it on both peers.

March 12, 2014 at 2:20 a.m. UTC

Thank you for sharing, that is really cool. Both can be used to calculate the number of hops, but also can limit connections.

A guest
November 12, 2014 at 11:09 p.m. UTC

Very nice explanation..

July 28, 2016 at 12:40 p.m. UTC

We need to configure it on both peers, right? I have one case like this:configure ebgp-multihop on one peer and configure ttl_security hops on another peer, can these two peers be established? If not ,why?

September 17, 2016 at 4:01 a.m. UTC

""Only BGP messages with an IP TTL greater than or equal to 255 minus the specified hop count will be accepted""

My lab does not corroborate that. This is what I see:

R1( R2 R1: router bgp 1 neighbor remote-as 2 neighbor ttl-security 1

R2: router bgp 1 neighbor remote-as 1 neighbor ebgp-multihop 254

BGP session comes up only if TTL in PACKET from R2 is

TTL equal or> 255-HOPCOUNT+1

If TTL=255-HOPCOUNT, BGP does not come up,

You guys can lab it up. But in real life we will never want to use ebgp on one peer and ttl-secuity on other peer, i used it to illustrate the check router performs when configured with TTL-security feature, which is TTL in Packet received should be equal or greater than 255-HOPCOUNT+1.

But it is a great post!!

Comments have closed for this article due to its age.