Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Cisco Employee

Strange IP TTL handling in IOS

Dear friends,

I am doing an experiment with TTL Security Check in OSPFv2. I have two OSPF devices connected via a direct link, call them R1 and R2. R1 is running 7200 IOS, R2 is a Linux-based Quagga router on which I can manipulate the TTL of OSPF packets.

After activating the TTL Security Check on R1 using the simple ttl-security all-interfaces OSPF mode command and making the Quagga on R2 send its packets with the TTL of 255, all is fine and the OSPF adjacency comes up nicely. However, I got intrigued by the fact that the ttl-security all-interfaces command has an optional hops hop-count argument whose value is in the range of 1-254 inclusive. This range surprised me. I expected the range to be in 0 to 254 because to make sure the received OSPF packets were received from on-link routers, their TTL should be exactly 255 and not 255-1=254; 254 would suggest that the OSPF packet traversed across one router.

So afterwards, I configured R2 to send its packets with TTL of 254. To my even bigger surprise, R1 dropped the adjacency. So I ran debug ip ospf adj on R1 and was nailed when I saw this:

R1(config-router)# ttl-security all-interfaces 
R1(config-router)# do debug ip ospf adj
OSPF adjacency debugging is on
R1(config-router)#
*Apr 26 12:41:36.091: OSPF-1 ADJ   Et2/0: Drop packet from 10.0.12.2 with TTL: 253

 

I am perfectly sure that the OSPF packets from R2 (10.0.12.2) are sent with TTL of 254 - confirmed with Wireshark. If R1 claims that it is dropping my packets with the TTL of 253 then it must have decremented the TTL itself before passing the packet to OSPF.

That is illogical in my opinion. Once a packet is received by a router who is its intended recipient, regardless of what interface the packet comes in and which router's IP address is in the packet's destination IP field, the TTL is not supposed to be decremented because the packet is not routed anymore - it has already arrived at its destination. After all, this can be demonstrated trivially: have two routers connected back to back, and have one router's loopback interface advertised to the other, and ping the loopback from the other router with the TTL set to 1. It will succeed just nicely. Even the traceroute will stop after a single hop. Once again: TTL should be decremented only when packet is about to be routed to a non-local destination. Why should the OSPF packet's TTL be decremented by an extra value, then?

And by the way, if I leave my R2 send its OSPF packets with TTL of 1, this is what I get on R1:

R1(config-router)#
*Apr 26 12:54:16.091: OSPF-1 ADJ   Et2/0: Drop packet from 10.0.12.2 with TTL: 1

 

This is a mess - when R1 gets OSPF packets with TTL of 254, it decrements the TTL before passing the packet to OSPF (which is illogical in itself), so OSPF sees a TTL of 253. Tested down to an initial TTL of 2: if R2 sends OSPF packes with TTL of 2, R1's OSPF process receives them with the TTL of 1. If R2 sends OSPF packets with TTL of 1, however, R1's OSPF process receives them again with the TTL of 1 - if the behavior was consistent, shouldn't it receive them with a TTL of 0?

So am I missing something, or is the TTL handling in IOS truly a mess? Any suggestion and clarification is welcome!

Best regards,
Peter

 

 

Everyone's tags (1)
3 REPLIES
VIP Super Bronze

Hi Peter,Hope you are well

Hi Peter,

Hope you are well.

Great test and observation.  I am wondering if this behavior is only on Cisco devices.  I have a couple of Juniper devices.  I will see, if I can duplicate your scenario and report back.

Thanks,

Reza

Cisco Employee

Hi Reza,I am so glad to be in

Hi Reza,

I am so glad to be in touch with all of you again. Yes, I am fine, though overloaded ... that is why my participation here at CSC is not as extensive as I would like it to be. Hoping to be gradually getting back, though :)

I will be very thankful for any insight you can provide. Looking forward to reading from you soon!

Best regards,
Peter

 

VIP Super Bronze

Hi Peter, Sorry for the delay

Hi Peter,

 

Sorry for the delay to response.  I did not have the devices ready, then had issue finding the right serial to DB9 converter for the console cable.  I finally got it configured, but don't see the option "ttl-security" under OSPF and/or under the interface. It seems that Juniper does not support this command.

Thanks,

Reza

 

138
Views
5
Helpful
3
Replies
CreatePlease to create content