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
