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!
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!
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...