Search code examples
ipcisco

Why is EIGRP and RIP uses IP TTL of 2 (CISCO)?


through my studies on CCNP ROUTE, while sniffing EIGRP packets, I noticed that packets have IP TTL of 2. I also verified this for RIP. OSPF doesn't have this property since it's link state.

Why does the EIGRP and RIP have IP TTL of 2?

I already asked one CCIE person, but he didn't know.

I came to believe that this may have something to do with frame relay hub&spoke topologies. For example hub routing EIGRP multicasts from one spoke to another (assuming subinterfaces)?

Any advice/idea/explanation would be greatly appreciated.

Thanks.


Solution

  • Let's look at this simple hub&spoke frame relay topology:

          R2
         /
    R1--
         \
          R3
    

    with R1 being a hub (R2 and R3 don't have PVC between them).

    • R1's DLCI 102 to R2
    • R1's DLCI 103 to R3
    • R2's DLCI 201 to R1
    • R3's DLCI 301 to R1

    I 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

    Working layer 3 connectivity between R1-R2 and R1-R3 is provided by frame relay inverse arp automatically. I used static mapping to make layer 3 work between R2 and R3 by mapping each other's IP address to DLCI to R1. (ex. frame-relay map ip 10.0.0.3 201 on R2).

    This way there is full layer 3 connectivity.

    Then I created loopback on R2 and R3 to announce one subnet and enabled EIGRP routing for those subnets. Next, I manually configured R2 to create neighbuorship with R3 IP on 10.0.0.0/24 subnet and vice versa.

    And now the conclusion... R2 (or R3) sends EIGRP HELLO with IP TTL of 2, R1 gets this packet and notices that it's destination is on the same interface as it arrived in. This is generally solved by sending an ICMP redirect message, which got sent. Also the EIGRP HELLO is rerouted to the same interface (not switched!) and therefore gets it's TTL decreased.