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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
