[c-nsp] NAT configuration between VRFs / 15.1SY

Jeff Bacon bacon at walleyesoftware.com
Wed Dec 11 09:55:55 EST 2013


So, I have this configuration wherein I'm doing NAT between VRFs on cat6500/15.1SY. I don't like it, but I can't think of anything better. 

-----

ip vrf main 
  rd 3:4
ip vrf bridge 
  rd 5:65 
  route-target both 5:65
  route-target import 111:222
ip vrf vendor1
  rd 111:222
  route-target both 111:222
  route-target import 5:65

int g1/1 
 desc -> to g1/2 - loop (main)
 ip vrf forwarding main
 ip addr 1.1.1.1 255.255.255.252
 ip nat outside

int g1/2
  desc -> to g1/1 - loop (bridge)
  ip vrf forwarding bridge
  ip addr 1.1.1.2 255.255.255.252

int g1/3
  desc -> to some vendor
  ip vrf forwarding vendor1
  ip address 2.2.2.1 255.255.255.252

int t2/1
  desc --- WAN link
  no switch
int t2/1.100
  desc --- mpls link
  encap dot1q 100
  ip address 172.15.1.1 255.255.255.252
  ip pim sparse-mode
  mpls ip 
int t2/1.101
  encap dot1q 101
  desc -> to other internal hosts over WAN
  ip vrf forwarding main
  ip address 3.3.3.1 255.255.255.252
  ip nat inside

int vlan 44 
  desc - other hosts in main
  ip vrf forwarding main
  ip addr x y
  ip nat inside

ip nat pool vendor-pool 200.200.200.1 200.200.200.10 netmask 255.255.255.0

ip nat inside source list NAT-ACL pool vendor-pool overload

<bgp config for MPLS>
<bgp config in vrf/vendor1 to talk to vendor1>

<ospf in vrf/main>
<other routing, ignore the routing>
------

Yes, that's an external loopback cable.

1) there are a lot of vendor connections. 
  1a) they aren't all on "this" 6500 - there are several 6500s and several vendor connections
  1b) sometimes the vendor connection is on a PE device elsewhere in vrf/vendorX via MPLS
2) I can't use global space as "common shared services" because global space is being used for MPLS
3) I want all these vendors isolated from each other for various reasons
  (they're not ISPs, they're service providers)
4) yes, that's mpls on a sub-int sharing the WAN link with a separate IGP for internal traffic on another subint when I could be using OSPF/supernet. there's historical reasons and I can't engineer it out easily.
5) yes the NAT has to happen here on the 6500s unless I want to replace a LOT of hardware. 
  (this is actually an improvement of sorts - in previous incantation, that hardware loopback actually was a loopback through another device which was dedicated just to doing NAT.) 


I hate losing Netflow on the internal net. But I don't see an answer that allows me to have Netflow, because as previously discussed here, NAT and Netflow don't co-exist - unless somehow I can convince NAT to work between VRFs, e.g. 

---
int g1/1 
 desc -> to g1/2 - loop (main)
 ip vrf forwarding main
 ip addr 1.1.1.1 255.255.255.252

int g1/2
  desc -> to g1/1 - loop (bridge)
  ip vrf forwarding bridge
  ip addr 1.1.1.2 255.255.255.252
  ip nat inside

int g1/3
  desc -> to some vendor
  ip vrf forwarding vendor1
  ip address 2.2.2.1 255.255.255.252
  ip nat outside

---

but supposedly this doesn't work. at least I haven't gotten it to work. 

I know this is a bodge. Anyone have a better idea that doesn't involve "rip it all out and start over with completely different hardware", which isn't economically- or time-resource-feasible?

thanks
-bacon



More information about the cisco-nsp mailing list