[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