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:[email protected]] > Sent: Tuesday, August 03, 2010 3:41 PM > To: Chris Mason; Jeff Bacon > Cc: [email protected] > 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: [email protected] [mailto:cisco-nsp- > > [email protected]] On Behalf Of Chris Mason > > Sent: Wednesday, July 28, 2010 6:26 PM > > To: Jeff Bacon > > Cc: [email protected] > > 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 [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
