|
Home > Archive > CCNA > April 2001 > Packet Intact?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| For simplicity:
RouterA is on NetworkA
RouterB is on NetworkB
RouterC is on NetworkC
A host on NetworkA sends a frame destined for a host on NetworkB...
Is it correct that:
When the frame is received by interface on the router between NetworkA and NetworkB - that the packet remains completely INTACT and is changed in no way and ONLY the frame is recreated - with the nw destination MAC address?
If this is too vague please let me know and I'll try to break it down better.
Thanks! | |
| grahambartlett 2001-04-22, 2:41 pm |
| That's spot on. | |
| dmaftei 2001-04-22, 3:00 pm |
| Hi Carla,
If I understand you correctly, you're describing what's known as "packet switching", that is what happens to a packet as it traverses a router. Say you have:
eth0-Router-eth1
- Router receives the frame on eth0.
- Router strips the Ethernet header.
- Router looks at the destination address and makes a routing decision; in our case the decision is to forward the packet out eth1.
- Router figures out the MAC address for the destination (from the ARP cache; if the destination is not in the cache, Router arps)
- Router decrements the TTL in the packet header. If the TTL is now zero, the packet is dropped.
- Router encapsulates the packet in a new frame; the source MAC address for the frame is eth1's MAC address; the destination MAC address is the address found in step 4.
- Router sends the new frame out eth1
So, I guess the short answer to your question is:
NO, the packet does NOT remain intact, because the TTL field in the packet is decremented.
(It may be that the TTL is decremented in step 3 or 4, instead of step 5, but it does get decremented).
HTH | |
| MadChef 2001-04-22, 3:33 pm |
| Doesn't this also assume that the MTUs on either side are identical and there's no need to fragment the frame?
MadChef | |
| dmaftei 2001-04-22, 5:31 pm |
| quote:
Originally posted by MadChef
Doesn't this also assume that the MTUs on either side are identical and there's no need to fragment the frame?
MadChef
It assumes that the packet is not larger than the MTU on eth1, and therefore it doesn't need to be fragmented. But yes, I didn't think about it.
Cheers! | |
|
| Thanks!
Now I'm off to take a look at MTU's!
This stuff is really interesting. | |
|
| quote:
Another great post by dmaftei
)
[*]Router decrements the TTL in the packet header. If the TTL is now zero, the packet is dropped.
Because of the TTL change the checksum has to be recomputed too.
Terje | |
| dmaftei 2001-04-23, 7:38 am |
| quote:
Originally posted by Terje
Because of the TTL change the checksum has to be recomputed too.
Terje
C'mon, guys, give me a break, will ya... 
Frankly, when I started my answer to Carla's question I completely forgot about MTU/fragmentation and about the checksum. I tried to make the point that the packet is modified while it traverses the router, and that's it. But since you are so picky  , let's try to get down to minute details.
We've got two cases here:
- The router doesn't need to fragment the packet.
The TTL is decremented. If the TTL becomes zero, the packet is dropped. Else, the checksum is recomputed (the checksum field is zeroed for the purpose of this computation -- details, details ), and we're pretty much done with the packet. You end up with two fields that are modified during packet switching: TTL and checksum.
- The packet needs to be fragmented. This happens when the packet is larger than the outgoing medium's MTU (like when you forward from token ring to ethernet).
- if the packet comes with the DF (Don't Fragment) bit set, it is dropped (and I believe an ICMP message explaining why it was dropped is sent back)
- if the DF bit is clear, the router must fragment the packet. Say you get three fragments (you need to forward a 4000 bytes packet to an ethernet; first and second fragments will be 1400 bytes, the third will be 1200 bytes; the split is arbitrary).
- for the first packet the router must change the Total Length field, and must set the MF (More Fragments) bit. The Fragment Offset field happens to remain unchanged (zero).
- for the second packet the router must change the Total Length field, and must set the MF bit. It must also change the Fragment Offset (set to 175; that is 1400/8).
- for the third packet the router must change the Total Length field, and must clear the MF bit (or, if you prefer, the MF bit in the last fragment is not changed -- when compared to the original packet). It must also change the Fragment Offset (set to 350; that is 2800/8).
Strictly speaking, with fragmentation a router doesn't modify a packet; rather, it creates as number (three in our case) of new packets. However, the header of the original packet is reused in creating the fragments, so I guess we can talk about modifying the packet. Also, all this fragmentation stuff happens in addition to the TTL and checksum changes.
How was this? | |
|
| quote:
Originally posted by dmaftei
How was this?
Excellent!
I appreciate what you (and others) do to make this a quality forum worth following. You should be proud when you share your knowledge in a very clear and obviously well thought out way. I think Carla says it all:
quote:
This stuff is really interesting.
Let us all try to keep the forum interesting.
Since we are allready off topic for the thread, I might as well continue the interesting digression.
quote:
(and I believe an ICMP message explaining why it was dropped is sent back)
You are of course right. This message can be used by the sending host to discover the (approximate) MTU of the link by "probing". Fragmentation has such serious drawbacks that hosts may go a long way to avoid it. In fact the drawbacks with fragmentation are so significant that they decided to omit it alltogether from IPv6.
A better method for MTU discovery is described in RFC1063.
You can play a little with fragmentation, and manually "discover" the MTU of a link using the -l and -f options of ping. For a start, try these commands on an Ethernet:
ping -f -l 2000 somelocalhost
ping -f -l 1473 somelocalhost
ping -f -l 1472 somelocalhost
ping -f -l 1000 somelocalhost
Compare your observations with what you know about Ethernet frame format and encapsulation.
Have fun!
Terje | |
| dmaftei 2001-04-23, 10:04 am |
| quote:
Originally posted by Terje
You can play a little with fragmentation, and manually "discover" the MTU of a link using the -l and -f options of ping.
One short note. ping -f -l has the potential of becoming a dangerous toy. Use it with caution!
Cheers! | |
|
| Dear Cisco Scientists
Okay - so now understand based on the above that the packet is modified by the router or routers?
BUT, it is NOT re-created as the frame is?
Thanks and I hope this doesn't start a war | |
| dmaftei 2001-04-23, 9:44 pm |
| quote:
Originally posted by Carla
Okay - so now understand based on the above that the packet is modified by the router or routers?
BUT, it is NOT re-created as the frame is?
Dear Carla
Yes, the packet is modified. As for "re-created", I don't know. I guess it depends on what you mean by re-creating a packet, as a frame is...
If by re-creating you mean stripping off the header, and some time later adding another header, then I guess you can say that the frame is re-created, while the packet is not re-created; it's only modified. (That is for the normal case. When a packet is fragmented, you sort of re-create a few little packets from a big packet.)
I don't think this "modified" versus "re-creating" issue is so important, as long as you understand the underlying logic of the process. Which I believe you do.
quote:
I hope this doesn't start a war
The only war this could start is a war for your favors! Just kidding, I couldn't help it... |
|
|
|
|