[c-nsp] GRE Tunnels and vrfs

[Rodney Dunn]

Sorry..a bit late to the party on this one.

Two things:

If it's GRE then use GRE keepalives so both
ends know when to go down if there is
a failure in the path.

Second, there have been some bugs where the
TTL didn't get decremented correctly with GRE.

CSCdv04959
Externally found minor defect: More (M)
TTL is not decreased while switching packets coming from GRE tunnel

for one.

You can use the static route to blackhole the traffic
also like you said.
 
Rodney



On Mon, Sep 13, 2004 at 06:21:55PM +0200, Gert Doering wrote:
> Hi,
> 
> On Sun, Sep 12, 2004 at 10:34:01PM +0100, Ian Dickinson wrote:
> > Gert Doering wrote:
> > >We managed to build a setup where certain packets would loop (aggregate
> > >routed statically into the tunnel, but not all individual routes were
> > >known on the B end, so the packets came back via the tunnel due to a
> > >default route inside the VRF), and that drove CPU to 90% for hours...
> > 
> > I saw this when routes disappeared on the B end due to circuit
> > failure, whilst the A end still had a static to B.  Adding a high
> > admin distance Null0 static on the B end sorted this, as would
> > have adding an ACL or uRPF to the Tunnel on the A end.  
> 
> Yep.  This is what we did in the end (and usually do).
> 
> > You're
> > right that routers don't like loops over GRE very much.
> 
> The problem is not loops per se.  
> 
> The problem is *neverending loops* - with this bug (which is something 
> quite serious, actually) the packet will loop between those routers *for 
> ever*, because the TTL isn't ever decremented and the packet never 
> discarded (unless one of the routers drops it due to overload).
> 
> gert
> -- 
> USENET is *not* the non-clickable part of WWW!
>                                                            //www.muc.de/~gert/
> Gert Doering - Munich, Germany                             gert at greenie.muc.de
> fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/