Why are EIGRP and RIP using IP TTL 2 (CISCO)?
through my research on CCNP ROUTE, sniffing for EIGRP packets, I noticed the packets have an IP TTL of 2. I also checked this for RIP. OSPF does not have this property as it is link state.
Why EIGRP and RIP have IP TTL 2?
I already asked one CCIE person, but he didn't know.
I have come to the conclusion that this may have something to do with relay frame topologies and topologies. For example, EIGRP routing using multicast from one conversation to another (assuming subinterfaces)?
Any advice / ideas / explanation would be greatly appreciated.
source to share
Take a look at this simple relay hub topology and topology:
R2 / R1-- \ R3
where R1 is the hub (R2 and R3 have no PVC in between). In the meantime, there is no need to know about it. ”
- R1 DLCI 102 to R2
- R1 DLCI 103 to R3
- R2 DLCI 201 to R1
- R3 DLCI 301 to R1
I have used physical / multipoint interfaces (subinterfaces) with one subnet:
- R1 - 10.0.0.1/24
- R2 - 10.0.0.2/24
- R3 - 10.0.0.3/24
Layer 3 connectivity between R1-R2 and R1-R3 is achieved using inverse automatic frame conversion. I used static mapping to make layer 3 work between R2 and R3 by mapping the IP address to each other from the DLCI to R1. (for example, frame-relay map ip 10.0.0.3 201 on R2).
Thus, there is a complete level 3 connection.
Then I created a loopback on R2 and R3 to advertise one subnet and enable EIGRP routing for those subnets. Then I manually configured R2 to create a neighborhood with R3 IP on the 10.0.0.0/24 subnet and vice versa.
And now the output is ... R2 (or R3) sends EIGRP HELLO with IP TTL 2, R1 receives this packet and notices that its destination is on the same interface it arrived on. This is usually resolved by sending an ICMP Forwarding Message that was sent. Also, EIGRP HELLO redirects to the same interface (does not switch!) And so it decreases the TTL.
source to share