This is for more general topics about networking and vendors.
1 post • Page 1 of 1
When I perform a traceroute from a remote location that traverses through my border router, when the traceroute reaches my border router, I receive that hop twice followed by the final hop. see hops 4 and 5. Traceroute and all data packets are flowing but fear this double hop is an issue waiting to happen. EX:traceroute 10.10.50.51 10.10.10.12 10.10.20.23 10.10.30.34 10.10.40.45 10.10.40.46 10.10.50.5 Border router configinterface Tunnel10 ip address 10.10.40.4 255.255.255.252 ip access-group IN-ACL in ip access-group OUT-ACL out no ip redirects tunnel source Serial0/1/0 tunnel destination 172.16.5.1!interface GigabitEthernet0/0 no ip address! interface GigabitEthernet0/1 no ip address!interface GigabitEthernet0/0.20 encapsulation dot1Q 31 bridge-group 20!interface GigabitEthernet0/1.20 encapsulation dot1Q 31 bridge-group 20!interface Serial0/1/0 ip address 10.10.99.1 255.255.255.252 ip access-group IN-LINK in no ip redirects load-interval 30 no service-module t1 remote-loopback full no cdp enable crypto map ENCRYPT-DATA!interface BVI20 ip address 10.10.50.1 255.255.255.240!bridge 20 priority 65535bridge 20 protocol ieeebridge 20 route ip--end-- Show ip route on the border router shows the border router is layer two adjacent to the last hop 10.10.50.5 via BVI20. The ip routing table shows 10.10.50.0/28 is directly connected via BVI20 BORDER#sh ip roGateway of last resort is 10.10.50.12 to network 0.0.0.0 C 10.10.40.0/30 is directly connected, Tunnel10 C 10.10.99.0/30 is directly connected, Serial0/1/0 10.10.50.0/28 is subnetted, 1 subnets C 10.10.50.0 is directly connected, BVI20 Spanning-tree is blocking G0/0.20, fordwarding on G0/1.20.There is only a single switch between the border router and final hop (10.10.50.5) Thanks for at least looking!!ANY thoughts?Frank
Hi, I guess its caused by the Tunnel10 you are using to connect to your border router.RFC 1702 (http://www.ietf.org/rfc/rfc1702.txt) says:"When IP is encapsulated in IP, the TTL, TOS, and IP security options MAY be copied from the payload packet into the same fields in the delivery packet. The payload packets TTL MUST be decremented when the packet is decapsulated to insure that no packet lives forever."Which means:An encapsulated traceroute packet with TTL = 0 comes to your Tunnel10 interface.The router replies with an ICMP "TTL expired" packet using the Tunnel10 interface IP (10.10.40.4).Following traceroute packet comes with TTL = 1.When decapsulated, TTL is decremented and reaches 0 again.So the router replies with ICMP "TTL expired", using Tunnel10 interface IP (10.10.40.4) again.(I should have used 1 and 2 instead of 0 and 1 in the explanation above to be precise, but the principle is clear, I hope.) Does it make sense? HTH,Milan Message was edited by: milan.kulik
Hi Milan, I can follow the logic of an encrypted packet arriving at Tunnel10 with a TTL of 1 as this is normal traceroute behavior as I understand it. The router decrements the packet TTL by 1 which leave the TTL=0, so the router replies back to the original source address with "TTL expired" using the ingress interface 10.10.40.4. (By the way, mistake on my part and not a trick, just a typeo on my part - 10.10.40.4/30 is not valid should have been 10.10.40.2 or 3 but not an issue with understanding the logic in this example).I understand and agree with this part. This next step is a little murky for me.The original source sends another packet towards the final destination with TTL set to 1 high than it took to reach Tunnel10 in last attempt. In this case the TTL value is now 2. This time the packet is unencrypted at Tunnel10 and in this unencryption process the TTL is decremented by 1 which now leaves the TTL with a value of 1.It seams the router would forward the packet to the next hop with TTL set to 1. BUT I think you are indicating the router decrements the TTL BEFORE forwarding and since the TTL would equal 0, the router would reply back to the original source with the "TTL expired" message. The ingress interface is always used for Traceroute and this is why Tunnel10 10.10.40.4 is seen twice? So with point-to-point in-line encryption, each end point (unencapsulation point, end of tunnel) will always strip the TTL value by two? Sorry took so long to respond, been little ill. Thanks again for your assistanceFrank
Hi Frank, my understanding is:a) a router is replying with ICMP "TTL expired" when received a packet with TTL=1 (no matter of destination address).b) a reouter is decreasing TTL value before forwarding an IP packetc) GRE encapsulation is copying the TTL value from the original packet which is then encapsulted (including the original header with the original TTL).So the GRE packet has an (external) TTL field within the IP header plus another (internal) TTL value within the encapsulated packet. Now the source device is sending traceroute packets.Starts with a packet with TTL = 1, then packet with TTL = 2 followed, then TTL = 3, etc.Which means:In your tracerout output:3 10.10.30.3 - i.e., the router received a packet with TTL = 1 and replied with ICMP "TTL expired"Next packet was received with TTL = 2 by your 10.10.3.3 router.It decreases the TTL value to TTL = 1 before forwarding.As there is a GRE tunnel used to forward it to the next hop, the router encapsulates the original packet to a GRE packet while copying TTL = 1 to the external TTL field.When the next hop receives the GRE packet, its seeing the external TTL = 1 and replies with ICMP "TTL expired".And you see:4 10.10.40.4Next traceroute packet was recived with TTL = 3 by the 10.10.30.3 router.And forwarded to the GRE tunnel with TTL = 2 within the external and internal TTL field.As the external TTL is 2, the 10.10.40.4 router continues by decapsulating the packet.When decapsulated, the extra step specified in the RFC follows: "The payload packets TTL MUST be decremented when the packet is decapsulated to insure that no packet lives forever."So the TTL of the decapsulated packet is decreased from 2 to 1.And the router handles the packet like just received, i.e., it is seeing a packet arrived with TTL = 1.So replies with ICMP "TTL expired" again (using the tunel port as the source IP), and you see: 5 10.10.40.4The next packet comes with TTL=3 and is forwarded to the next hop with TTL=1, which has6 10.10.50.5as a result.I hope to be clear now? And you seem to be correct with "So with point-to-point in-line encryption, each end point (unencapsulation point, end of tunnel) will always strip the TTL value by two." - which is a side effect I did not notice originally. BR,Milan