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.) -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.
-----Original Message----- From: Forrest W. Christian [mailto:forrestc@imach.com] Sent: 14. mája 2002 0:02 To: Roger Marquis Cc: nanog@trapdoor.merit.edu Subject: Re: BGP and aggregation
On Mon, 13 May 2002, Roger Marquis wrote:
Last time I tried this (IOS11.X to IOS11.X GRE) it was unreliable due to MTU limits. Certain websites (mainly financial) send large packets and set DF. This probably works around some security issue but the result was that these SSL servers couldn't reach clients over the GRE.
We have seen the same issue in recent history.
Generally, we try to have most of the traffic not pass through a GRE tunnel. With some creative routing, we can pass the data back out to our upstream which knows the more specific for that route.
That said, we do support /32 static dialups across our net - I.E. if you have a /32 static on your dialup, you get the same /32 no matter where you dialup. These generally pass through the GRE tunnel as we only know of them through OSPF through the GRE tunnel.
We have found that setting a mtu of roughly 1514 on the tunnel fixes this. I think this forces the GRE encapsulation to frag the packets regardless of the setting of the DF bit. Whether the far end router reassembles them or not I'm not sure about and haven't had the opportunity to stick a packet sniffer on the far end to tell. Regardless, it seems to fix the broken sites. YMMV
- Forrest W. Christian (forrestc@imach.com) AC7DE ---------------------------------------------------------------------- The Innovation Machine Ltd. P.O. Box 5749 http://www.imach.com/ Helena, MT 59604 Home of PacketFlux Technogies and BackupDNS.com (406)-442-6648 ---------------------------------------------------------------------- Protect your personal freedoms - visit http://www.lp.org/