Routing

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



Expand all | Collapse all

TTL in inner IP header GRE tunnel

  • 1.  TTL in inner IP header GRE tunnel

    Posted 22 days ago
    Hello all,
    I read in JNCIS course:
    "The inner packet (also known as the payload packet) is not
    modified, except the time-to-live (TTL) field, which is decremented. The TTL field must be
    decremented to ensure that the packet does not live forever."
    But I build a VMX lab to test and see that TTL in the inner IP header doesn't change when packet traversing in the tunnel.
    My topology:

    R1# show interfaces gr-0/0/0

    Sep 20 23:54:05

    description TEST_GRE_TUNNEL;

    unit 0 {

        tunnel {

            source 10.249.50.84;

            destination 10.249.50.86;

        }

        family inet {

            address 192.168.12.1/24;

        }

    }



    [edit]

    R1# show routing-options

    Sep 23 01:44:20

    static {

        route 3.3.3.0/24 next-hop gr-0/0/0.0;

    }
    ===
    R3# show interfaces gr-0/0/0

    Sep 20 23:54:05

    description TEST_GRE_TUNNEL;

    unit 0 {

        tunnel {

            source 10.249.50.86;

            destination 10.249.50.84;

        }

        family inet {

            address 192.168.12.3/24;

        }

    }



    R3# show routing-options

    Sep 23 01:44:20

    static {

        route 1.1.1.1.0/24 next-hop gr-0/0/0.0;

    }


    R1#ping 3.3.3.3 source 1.1.1.1
    Sep 20 23:58:04
    PING 3.3.3.3 (3.3.3.3): 56 data bytes
    64 bytes from 3.3.3.3: icmp_seq=0 ttl=64 time=2.911 ms
    64 bytes from 3.3.3.3: icmp_seq=1 ttl=64 time=95.914 ms

    Capture packet from R1 to R2:
    Capture packet from R2 to R3:

    As you see, TTL in the inner IP header remains unchanged (still be 64) when packet traversing in the tunnel.
    Only TTL in the outer is decreased.
    Hope you clear this up for me.
    Thank you.



    ------------------------------
    NAM NGUYEN
    ------------------------------


  • 2.  RE: TTL in inner IP header GRE tunnel

    Posted 22 days ago
    As traffic goes through the transit devices, the TTL of the outer header is decremented as per regular IP forwarding rules, the inner IP header is not, if the book suggests otherwise, please check the errata of the book and see if there is any correction on it.

    Elvin


  • 3.  RE: TTL in inner IP header GRE tunnel

    Posted 22 days ago
    I don't know if I am missing some things.
    This tutorial is from Juniper Official Training.


    ------------------------------
    NAM NGUYEN
    ------------------------------



  • 4.  RE: TTL in inner IP header GRE tunnel

     
    Posted 22 days ago
    I believe the Official Training material is correct but could be written more clearly.

    There are two sentences referring to two different IP headers.

    "The inner packet is not modified, except the TTL field, which is decremented" --> This is the inner IP header before the outer IP header with TTL=64  is added. Once the outer header is added, the inner TTL is not decremented any further until the packet exits the tunnel.

    "The TTL field must be be decremented to ensure that the packet doesn't live forever" ---> This is the outer IP header, whose TTL value is decremented at each hop of the tunnel. 

    Hope this adds some clarity.


  • 5.  RE: TTL in inner IP header GRE tunnel

    Posted 22 days ago
    That is not right, inner header is not touched, you could submit feedback to modify that paragraph, as it needs to be fixed.

    Elvin


  • 6.  RE: TTL in inner IP header GRE tunnel

     
    Posted 21 days ago
    Hi.

    Do you mind running the test with transit traffic i.e. pinging from behind GRE ingress R1 ?

    Thanks.


  • 7.  RE: TTL in inner IP header GRE tunnel

    Posted 21 days ago
    Thank you ElvinArias and djadhav.

    ------------------------------
    NAM NGUYEN
    ------------------------------



  • 8.  RE: TTL in inner IP header GRE tunnel

    Posted 21 days ago
    I have 2 Cisco IOS connect to R1 and R3:
    CE1 --- R1 ---tunnel--- R3 --- CE3

    CE1:
    interface Ethernet0/0
    ip address 1.1.1.100 255.255.255.0
    ip route 3.3.3.0 255.255.255.0 1.1.1.1

    CE3
    interface Ethernet0/0
    ip address 3.3.3.100 255.255.255.0
    ip route 1.1.1.0 255.255.255.0 3.3.3.3


    CE01-GRE#ping 3.3.3.100
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 3.3.3.100, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 2/4/10 ms
    CE01-GRE#

    Traffic between R1-R2:

    Traffic between R2-R3:

    You can see that TTL in the inner IP header remains unchanged when the packet traversing through the GRE tunnel.


    ------------------------------
    --------
    Harry
    --------
    ------------------------------



  • 9.  RE: TTL in inner IP header GRE tunnel

     
    Posted 20 days ago
    Hi Harry.

    My post says that R1 decrements the original packet's TTL value 'before' encapsulating it with the GRE header. 

    So you would need to compare the TTL at CE1-R1 with the inner TTL at R1-R2.

    Or better still, run a traceroute from CE1 to CE2. If you see both GRE tunnel endpoints R1 and R3 in your traceroute output, then they are both decrementing the original TTL (R1 decrementing before encapsulation, and R3 decrementing after deencapsulation).


    --Deepak


  • 10.  RE: TTL in inner IP header GRE tunnel

    Posted 19 days ago
    Hi djadhav,
    Topo:
    CE1 --- R1 ---tunnel--- R3 --- CE3
    "My post says that R1 decrements the original packet's TTL value 'before' encapsulating it with the GRE header."
    Sure. R1 will decrement the original packet's TTL when the packet goes into the tunnel. R3 will decrement the original packet's TTL when the packet goes out the tunnel as well.
    Packet from CE1 --- R1:
    Packet from CE1 --- R2:
    Packet from R2 --- R3:
    Packet from R3 --- CE3:



    ------------------------------
    --------
    Harry
    --------
    ------------------------------