Well. Still awake, so here's some random chunk of cisco config for that NAT thing I mentioned earlier.
Most of the examples I found in cisco doc's were for NAT Inside VRF, outside global. My use case was the opposite - IP NAT inside global, outside VRF. In particular, an NMS needed access to an otherwise hidden network. Since it's a Windows based NMS, relying on an IPSEC tunnel being up 24x7 seemed laugable, and also impractical in our case.
Plus, Windows... yeah.
ip vrf ThatVRF
rd 172.16.0.0:1
!
ip nat source list GLOBAL-TO-VRF interface Vlan10 overload
!
ip access-list extended GLOBAL-TO-VRF
permit ip host 10.10.10.1 172.16.0.0 0.7.255.255
!
interface GigabitEthernet0/0
description Gobal to core
ip address 10.11.128.1 255.255.255.248
ip nat enable
!
interface Vlan10
ip vrf forwarding ThatVRF
ip address 172.16.180.2 255.255.255.248
ip nat enable
!
! static to leak 172.16.0.0/13 into global at this hop
ip route 172.16.0.0 255.248.0.0 Vlan10
ip route 0.0.0.0 0.0.0.0 10.11.128.6
ip route vrf 172.16.0.0 255.248.0.0 172.16.180.1
!
end
I still needed to use the NVI trick ala 'ip nat enable' on the 3800 where this is running. using explicit ip nat inside/outside on respective interfaces didn't seem to go for some reason as I expected use of the NVI to only be for between VRF's.
The other caveat is having to leak routes into global for this to work, but not much else you can do (less do it properly in the first place). Statics ala interface routes seems pretty safe.
In production, policy-based routing gets the NMS traffic to this hop to prevent leaking routes any further beyond this point.
So that should be mostly right. I'll consider correcting any errors after some sleep or something.
Wee.
