TTL 2 of EIGRP and RIP Packets Explained

(Rene Molenaar) #1

This topic is to discuss the following lesson:

(system) #2

I’m sorry but i don’t really agree with what you say. Your example starts with a multicast link-local ip address as destination. It has to be with TTL1.

When you establish static neighborship instead, your packet becomes a unicast.

The answer to this i guess, is programmers laziness. Is easier to keep the packet as is and just change the destination ip address rather than changing ip address and ttl. From a “c” developer point of view, you will not need to define a “ttl variable” and “set up a “setsockopt” call” … less code, less errors can be made.

(Rene Molenaar) #3

Hi Andrea,

Thanks for your message. I think it’s common practice to set the TTL of link local multicast packets to 1 but it’s not written down in any standard. Only thing I could find about this is a draft:

The TTL of eigrp packets (unicast or multicast) is 2 so the only thing I could think of was the spoke to spoke communication as the hub decrements the TTL by 2.


(Nicholas Russo) #4

Rene is correct. Just because the neighbor statement is used with an IGP does not modify it’s TTL. Whether RIP or EIGRP are sending their hellos/updates via multicast or unicast, the TTL is 2 in both cases. For OSPF, PIM, and LDP, it’s always 1.

If you used the neighbor statement with OSPF, the TTL remains 1. So, simply by modifying the behavior of the IGP does not modify the packet’s TTL.

The reason behind this is to still maintain neighborships across NBMA networks, including DMVPN, for distance vector routing protocols WITHOUT having to disable split horizon at the hub.

Another fun trivia fact: TTL=2 is the reason why RIP and EIGRP packets will hit under “control-plane host” and TTL=1 explains why OSPF, PIM, and LDP will hit under “control-plane cef-exception”. So beware of your protocols in use when configuring CPPr.

(system) #5

Rene and Nick

This is really great information. Thanks for sharing.

(Paul B) #6

This is good info - never read about it before.

(Hussein Samir) #7

Hi Rene,

What about OSPF packets TTL ? I mean if spokes routers become OSPF neighbors in broadcast or non-broadcast network type, so how can they advertising the networks with TTL = 1 ?

(Rene Molenaar) #8

Hi Hussein,

When you use OSPF on a hub and spoke frame-relay network then the hub will be the DR. LSAs are not exchanged from spoke1 to spoke2.


(Hussein Samir) #9

Thanks Rene,

What if the OSPF network type was Point-to-Multipoint Broadcast Network or Point-to-Multipoint Non-Broadcast Network ? So in this case no DR/BDR election since OSPF sees the network as a collection of point-to-point links just like you said in OSPF Network Types Section in OSPF Lessons ?

(Rene Molenaar) #10

With any of the OSPF “point-to-xxxx” network types, the spoke routers will become neighbors with the Hub router.

When one spoke router advertises something to the hub then the hub will create a new IP packet with a LSA and sends it to the other spoke. This IP packet will have a TTL of 1.

(Hussein Samir) #11

You mean we don’t need to frame-relay map between the spoke routers ??

(Rene Molenaar) #12

That’s right. Take a look at this lesson, I think you will like it:

(Hussein Samir) #13

Thank you very much Rene for the clarification and explanation, which an unprecedented
You are a great person

(Hussein Samir) #14

Hi Rene,

The spoke routers are neighbor with hub router and the hub router know all prefixes so what is the benefit of configure static neighbors between spokes routers ?

(Rene Molenaar) #15

Hi Hussein,

I can’t think of any benefit. It might be a nice task for a CCIE lab where they ask you to advertise something from spoke1 to spoke2 without disabling split horizon on the hub…this would do the trick :slight_smile: Only reason I did it here is to demonstrate the TTL=2 .


(Hussein Samir) #16

Thanks Rene that was a very useful for me

(Vikram S) #17

Hello Rene,

I captured packets in wireshark for eigrp over framerelay for both dynamic and static neighbor. But the TTL is always 1. So in case of static neighbor spoke to spoke neighbor ship did not ever happen. Also HUB sending the message to spoke “Time to Live Exceeded”. My spoke to spoke inverse arp is working. I am using 7200 IOS 15.2 router. Please have a look at this.