[c-nsp] routing between VRF and global

[Jeff Bacon]

So, here's the deal. 

It works. With caveats. 

1) the Cisco 6500 loopback has a fixed mtu of 1514. This isn't enough to
accommodate a GRE-encapsulated packet. So you have to take the path-MTU
hit. 
2) per the release notes, GRE tunnels are hardware-accelerated - except
for packets which require egress features on the tunnel interface -
output ACLs, NAT/PAT, TCP intercept, CBAC, and encryption, which are
process-switched on the RP. 

I set up a sup32 and tested this, and yup it works exactly as described.
Very nicely, only the packets actually requiring egress features are
punted to the RP - you can blast a stream of not-NAT-requiring packets
through the tunnel at full speed without impacting the switch, while
running some packets requiring NAT through the RP. Though at least on an
ME6524/sup32, performance sucks eggs. 


At this point, I will concede defeat and run a crossover cable between a
couple of ports on the switch. 

I am also starting to notice/realize that NAT, as a feature on the 6500,
has, well, limitations. Wouldn't be so bad if I didn't have to NAT to
every friggin' stock exchange. Makes me want to throw a NS5k in front of
them... except for $ and rack space.

Sigh. 

> -----Original Message-----
> From: Daniska Tomas [mailto:Tomas.Daniska at soitron.com]
> Sent: Tuesday, August 03, 2010 3:41 PM
> To: Chris Mason; Jeff Bacon
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] routing between VRF and global
> 
> Chris, Jeff, *
> 
> have you managed this to work being CEF switched? Couldn't get past
> process path when I tried lately
> 
> --
> 
> deejay
> 
> 
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Chris Mason
> > Sent: Wednesday, July 28, 2010 6:26 PM
> > To: Jeff Bacon
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] routing between VRF and global
> >
> > > Which means the only real option is a "GRE internal hairpin".
> Except I
> > > can't see how you would implement a tunnel with both endpoints
> are on
> > > the same device - and even if you could, is that the sort of
> > > configuration you'd want other people to see?
> >
> > I am not sure if this helps you or whether it is supported on the
> > 6500, but I have previously used the follow hack.
> > This is definately a hack and will probably have performance
> issues as
> > well as the GRE overhead on MTU, etc.
> >
> > You create the following in the global table:
> >
> > interface Loopback100
> >  ip address 192.0.2.1 255.255.255.255
> > !
> > interface Tunnel100
> >  ip address 192.0.2.129 255.255.255.252
> >  tunnel source Loopback100
> >  tunnel destination 192.0.2.2
> > !
> >
> > You create the following in the VRF table:
> >
> > interface Loopback101
> >  ip address 192.0.2.2 255.255.255.255
> > !
> > interface Tunnel101
> >  ip vrf forwarding <VRF>
> >  ip address 192.0.2.130 255.255.255.252
> >  tunnel source Loopback101
> >  tunnel destination 192.0.2.1
> > !
> >
> > You then run a dynamic routing protocol across the tunnel like
> OSPF
> > for exampel:
> >
> > router ospf 100
> >  network 192.0.2.129 0.0.0.0 area <AREA>
> > !
> > router ospf 101 vrf <VRF>
> >  network 192.0.2.130 0.0.0.0 area <AREA>
> > !
> >
> > The tunnel source and destination are between different loopbacks
> > within the global table, but one end of the tunnel is within the
> > global and one end within the VRF table. You might be able to NAT
> > across the GRE tunnel.
> >
> > /Chris
> > _______________________________________________
> > 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/