CCNA R&S Course 1 of 4, Lab 8.3.2.7
A student emailed in with a really good question asking about some specifics of TTLs. Here's a basic network diagram of the setup:
To recap - the Time To Live (TTL) field is used to ensure that packets don't float around a network forever. They need to expire eventually. If they didn't eventually expire, it would be possible for our network connections to become saturated with old, derelict packets. If a TTL has a value of zero, the packet can no longer be forwarded.
On with the question!
I am doing the lab 8.3.2.7, when performing ping from PC-A to the rest of the hosts:
1. ping LOCAL router (192.168.1.1) the ttl is 255. My question is should it be 254 instead? since the default original ttl value by ping is 255, as it reaches a router (hop), it decrements the ttl value by 1 and becomes 254.
Let's look at what the RFC has to say:
When a router forwards a packet, it MUST reduce the TTL by at least one.
Source: Requirements for IP Version 4 Routers: 5.3.1 Time to Live (TTL)
Let's look at what's actually inside a router. I'm going to provide an overly simplified version of a router for the sake of explanation.
A router has a few basic components:
- Several network interfaces
- A Processor
- A Forwarding Engine
Any traffic that passes between network interfaces must go through the Forwarding Engine. The Forwarding Engine is a component that directs packets to their destination. During the process of directing packets to their destination, a few things will happen such as:
- Checking / decreasing the TTL
- Re-writing the headers
- Generating a new checksum for the Layer-2 frame.
From PC-A you are pinging the "Local" router on its nearest interface (192.168.1.1). This traffic is handled by the Processor, and is not forwarded to a different network. As a result, the TTL is not decreased.
This is an example of what is called "locally processed traffic." When the traffic is processed locally, there's no need to check/decrease the TTL, there's no need to re-write the headers, and there's no need to generate a new checksum. Why? Because the packet has already reached it's destination. The Processor will handle any replies - there's no need to keep forwarding the original packet.
Similarly, if a packet is sent from PC-A to the 10.1.1.1 interface of the "Local" router, the TTL will not be decreased - again - it is locally processed by the "Local" router - it is not forwarded.
In short the criteria for decrementing the TTL are:
- It has to pass through the forwarding engine
- It has to be destined to a different device.
If both of those criteria are met, the TTL will be decreased.
2. ping S3 192.168.3.11, the ttl is 252. My question is should it be 253 instead? since only routers are considered as hops, moving through switches should not result in ttl value deduction. (same as the ttl result for 192.168.11.1 S1, ttl value does not decrease.)
Indeed, a switch (unless it's a multilayer switch) should never decrease the TTL. Let's think about the steps that are happening in the order they occur:
- PC-A sends an ICMP Echo Request with a TTL of 255. Since the Layer-3 (IP) destination is not on the local network, PC-A will set the Layer-2 (MAC) destination to the "Local" router.
- S1 forwards the frame (we're talking Layer-2 in this step) because it's destined to a MAC address other than S1's MAC address.
- "Local" receives it, realizes that it's not destined to one of its own interfaces, will decrease the TTL (now 254) and forward the Echo Request.
- "ISP" receives it, realizes that it's not destined to one of its own interfaces, will decrease the TTL (now 253) and forward the Echo Request.
- "Remote" receives it, realizes that it's not destined to one of its own interfaces, will decrease the TTL (now 252) and forward the Echo Request.
- S3 receives the frame (we're talking Layer-2 in this step) and decides to process it as it is destined to S3. S3 has received an Echo Request with a TTL of 252.
At this point it's important to note that you never see what the TTL is of a packet that is received by a foreign device. You can make some assumptions based on some common practices, but there's no way to know for certain without doing packet captures at the foreign host.
You may be asking yourself where the displayed TTL value comes from. It's the value that is received by PC-A in the ICMP Echo Reply packet. Let's have a look:
- S3 has received an ICMP Echo Request packet and decides to send a reply (there's no policy or firewall rule preventing it). It sends an ICMP Echo Reply with a TTL=255.
- "Remote" receives it, realizes that it's not destined to one of its own interfaces, will decrease the TTL (now 254) and forward the Echo Reply.
- "ISP" receives it, realizes that it's not destined to one of its own interfaces, will decrease the TTL (now 253) and forward the Echo Reply.
- "Local" receives it, realizes that it's not destined to one of its own interfaces, will decrease the TTL (now 252) and forward the Echo Reply.
- S1 forwards the frame (we're talking Layer-2 in this step) because it's destined to a MAC address other than S1's MAC address.
- PC-A receives the Echo Reply with a TTL of 252 and displays it.
It's imperative to understand the steps above for the next question.
3. ping PC-C 192.168.3.3, the ttl is 125. This looks even funnier to me? how would ttl drops from 252 to 125 without even passing one router?
If PC-C received an Echo Request with a TTL of 252... is there any rule that says it must send an Echo Reply with a starting TTL of 255? Well... no, there isn't.
Any device is free to set the TTL on outbound packets that it originates to any value it chooses. This can be really useful for doing things like a Traceroute. In this case I suspect that PC-C is sending Echo Replies with an initial TTL of 128. A packet capture will show with certainty what is going on.