![]() | |||||||||||||
Messages in this thread |
List, This is not the same as the pmtud issues discussed ad-nauseum from 1999 through 2001. It really is different. Trust me, please read on. Well, it is similar, but with a twist. We are in the middle of deploying DiffServ compliant QoS throughout our networks and stumbled across an issue that occurs when we configure our routers to mark the DiffServ Code Points (DSCP) for UDP traffic (AFS, NFS, other full frame size UDP traffic). The problem is that when the marked traffic reaches an IPsec/Ethernet segment, and the DF bit set to true, an ICMP message is returned to the transmitting host to say basically "fix your MTU". Since we have changed the ToS field with DSCP information, the ICMP message no longer matches anything in the route cache hash. If the ToS field is not "0", it must match src, dst, and ToS in the cache. Well, we changed one of them and there can be no such match. The net result is that the transmitting host sends another 1500 byte packet and the process repeats itself. Ultimately the data transfer fails. When we stop DSCP marking, MTU negotiation works just fine, but we have no QoS. This kind of match might be great if we use a Linux platform as a router. It may indeed be useful for higher performance DiffServ routing. This kind of match requirement for an end-host is problematic. In our estimation it looks like a bug. Can anyone out there help sort this out? Chester Johnson Network Transport Engineering Intel Corporation - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 12:58 [from the cache] ©2003-2008 | |||||||||||||