The Never-Ending Story of IP Fragmentation
In the last few months I ran across a number of IP fragmentation issues. Unfortunately I also encountered a lot of misconceptions about IP fragmentation, its impact on GRE and IPSec, as well as the fragmentation-related mechanisms like MTU Path Discovery. I documented most of what I found in the The Never-Ending Story of IP Fragmentation.
or you could enable PMTUD for GRE tunnels with the tunnel path-mtu-discovery interface configuration command. When you enable the PMTUD on a GRE tunnel, the GRE packets are sent with the DF bit set and the router responds to the incoming ICMP destination unreachable messages with the reduction of the tunnel MTU size.
On the other hand, you write:
DF bit is copied from the source IP packet into the GRE envelope. If the source IP packet doesn’t have the DF bit set, it won’t be set in the outgoing GRE packet, potentially resulting in fragmentation of the GRE packet and expensive reassembly on the tail-end router.
How do these two statements connect? Which combination of tunnel path-mtu-discovery and a DF flag in an incoming package causes DF to be set on the GRE package?
* If the tunnel path-mtu-discovery is not configured, all GRE packets are sent without the DF bit and thus fragmented if needed (and the receiving router falls back from CEF into process switching and dies a horrible death when the traffic load increases :( ).
* If the tunnel path-mtu-discovery is configured, the DF bit is copied from the source IP packet into the GRE packet, triggering PMTUD if and only if the original packet looks like it could come from a PMTUD-aware source.
The content of the article is empty under Safari.
I tried several articles, and none of them is readable
The banner is definitely misplaced; it will be "fun" figuring out why, as it appears correctly in IE and FF. The blank article seems to be a timing issue (the JavaScript library is not loaded the first time you open the article) and will be fixed.
As a workaround, I've got it to work by going BACK and FORWARD, the script was already cached on the second visit of the same page.
"The drop of denied packets and generation of ICMP-unreachable messages imposes a load on the MSFC CPU. In order to eliminate the load, you can issue the no ip unreachables interface configuration command. This command disables ICMP-unreachable messages, which allows the drop in hardware of all access group-denied packets."
I'm sure there are many environments, trying to squeeze performance out of their expensive 6500s who look at that and see it as an easy decision. If cisco puts that kind of thing in the slowpath, it is no wonder that the rest of the world says "who cares if PMTUD breaks". Interestingly, that document makes no mention of PMTUD, or breaking it, at all!
However, in most 6500 deployment scenarios it wouldn't hurt you, as the MTU is the same on all interfaces (unless you're terminating IPSec sessions or GRE tunnels on it).
It's obvious why the ICMP unreachables are in slowpath - while it's possible to do everything in ASICs (after all, the CPU is just a large ASIC ;), building whole new IP packets out of existing payload in silicon would be "slightly" expensive ... and then everyone would complain how overpriced these boxes are :)