OSPF TTL Security Check

The OSPF TTL security check is a mechanism that protects OSPF against remote attacks. When you enable this feature, OSPF will send packets with a TTL of 255 and rejects any packets with a TTL that are smaller than a configured threshold. By default, once you enable this it will only accept packets with a TTL of 255. Since routing decrements the TTL by one, this means that only OSPF packets from directly connected devices will be accepted.

Let’s look at an example. I will use the following topology:

ospf r1 r2 area 0 h1

Above we have two routers running OSPF, behind R2 is an attacker that wants to attack R1. It will do so by sending spoofed unicast OSPF packets destined to

ospf r1 receives spoofed packet

H1 sends a spoofed OSPF, impersonating R2 and destined to R1. When R2 forwards this packet, the TTL will be decreased by 1 and R1 will receive the IP packet. Even if OSPF rejects the packet because the content is garbage, it still has to be processed by the control plane. If H1 sends enough packets, it might succeed in overloading the router’s control plane.

To stop a remote attack like this, we can implement the OSPF TTL security check.

By default, all OSPF packets have a TTL of 1 as you can see in the packet capture below:

ospf packets ttl 1

When TTL security check is enabled, OSPF will only accept packets with a certain TTL value, 255 by default. When it receives packets with a lower TTL, they will be discarded.


Let’s give this a try. We can enable this globally for all interfaces like this:

R1(config)#router ospf 1
R1(config-router)#ttl-security all-interfaces
You can also enable TTL security check on the interface level with the ip ospf ttl-security command.

As soon as you enable this on one router, the neighbor adjacency with R2 will drop once the dead timer expires. Why? We can see the reason when we enable a debug:

R1#debug ip ospf adj
OSPF adjacency debugging is on

On the console of R1, you will see this message:

OSPF-1 ADJ   Gi0/1: Drop packet from with TTL: 1

R1 will now only accept packets with a TTL of 255 and since R2 is sending OSPF packets with a TTL of 1, they are discarded. Let’s enable TTL security on R2 as well:

R2(config)#router ospf 1
R2(config-router)#ttl-security all-interfaces

The OSPF neighbor adjacency will recover and both R1 and R2 are now sending OSPF packets with a TTL of 255 to each other:

ospf ttl 255

Here’s a packet capture where you can see the new TTL value:

ospf packets ttl 255

Wireshark Capture OSPF TTL Security Check

Above you can see that the TTL is now 255. Since this is the highest value possible for the TTL field, it is impossible for H1 to send a spoofed unicast OSPF packet to R1, preventing a remote attack like this.

The TTL security check is not applied to virtual links or sham links by default. If you want to use this, then you can use the area virtual-link ttl-security or area sham-link ttl-security commands.

By default, the lowest TTL that OSPF TTL security check will accept is 255. You can add the hops parameter to use another value. For example, if you use ttl-security all-interfaces hops 100 then OSPF will accept all OSPF packets with a TTL of 155-255.

That’s all there is to it. You can read more about TTL security in the following RFC: The Generalized TTL Security Mechanism (GTSM)


Want to take a look for yourself? Here you will find the final configuration of each device.


hostname R1
ip cef
interface GigabitEthernet0/1
 ip address
router ospf 1
 ttl-security all-interfaces
 network area 0


hostname R2
ip cef
interface GigabitEthernet0/1
 ip address
interface GigabitEthernet0/2
 ip address
router ospf 1
 ttl-security all-interfaces
 network area 0

Forum Replies

  1. I guess if the person spoofing is capable of spoofing a TTL of 2, they are also capable of spooing a TTL of 256 which (with the default config) would effectively override this safety mechanism in this scenario :slight_smile:

    Unless the TTL is an 8 bit field, so 255 is the highest value!

  2. Also you said this:

    might be a change for IOS 15, but now the hops value is the maximum hop value, not the decrement amount.

    [quote]ttl-security all-interfaces hops ?
    <1-254> maximum number of hops allowed[/quote]

    So if you wanted a TTL of 155 you would use the number 155, not the number 100

  3. Hello Chris

    Yes, you are correct that the TTL field is an 8 bit field, so the highest value can be 255.

    I hope this has been helpful!


  4. Hello again Chris.

    You must remember that the value configured in the ttl-security all-interfaces hops command is the number of allowed hops and not the actual value of the TTL field. The value is essentially a threshold.

    The default value is actually 0. This means that it will accept any values of TTL equal to or greater than 255-0. Since routing decrements the TTL by one, this means that only OSPF packets from directly connected devices will be accepted.

    If this threshold is configured at 100 hops, then only packets with a TTL higher than 255-100 = 155 wil

    ... Continue reading in our forum

  5. Hi Rene,
    Hopefully you are doing good…

    I have one question When i am going through you CCIE R&S Written Table of Contents here why 3.6e:Path Preference & 3.6f:Operations not showing anything when i am trying to click there no page is opening so are you want to add any content there or its mistake by you? then 3.6g:Convergence and Scalability having content because when i clicking the + button the content is coming.

    For your reference i attached the screenshot as well.


    ... Continue reading in our forum

10 more replies! Ask a question or join the discussion by visiting our Community Forum