On Tue, May 14, 2002 at 08:19:22AM +0200, Daniska Tomas wrote:
actually gre fragmentation itself has nothing to do w/df bit. you either leave the tunnel with default mtu (and use ip fragmentation - of course depending on df) or you may cause it fragmenting packets and resembling them at the tunnel end. on cisco boxes this is triggered by using larger 'ip mtu' (not interface mtu) value. there are some memory and cpu drawbacks due to defragmentation (a hold queue for fragments until they all arive etc.)
http://www.cisco.com/warp/public/105/56.html#subsecondone A final option is to increase the IP MTU on the tunnel interface to 1500 (available in IOS 12.0 and higher). However, increasing the tunnel IP MTU causes the tunnel packets to be fragmented because the DF bit of the original packet is not copied to the tunnel packet header. In this scenario, the router on the other end of the GRE tunnel must reassemble the GRE tunnel packet before it can remove the GRE header and forward the inner packet. IP packet reassembly is done in process-switch mode and uses memory. Therefore, this option can significantly reduce the packet throughput through the GRE tunnel. Handy for getting around MTUs you can't increase. Unfortunately, I do not believe Juniper has any such functionality (even when gre is done by the RE). -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)