Virtual Routing and Forwarding
VRFs Virtual Routing and Forwarding Instances have been about for a long time in the world of service providers, we are now seeing VRFs capabilities as part of the world outside service providers.
VRFs have their own routing instance in a router (own routing table) and the instance is assigned generally assigned to an interface, the interface then only applys to that particular VRF. So for example you could have a Management VRF and this is connected to a separate management network.
Management Processes need to know
If you assign an interface in a VRF for management then the management processes:
need to know "be VRF aware", because typically they will be running against the Global (Default) routing table.
aaa group server tacacs+ Management
server-private 10.100.100.1 timeout 15 key mysecretket
ip vrf forwarding Management-VRF
ip tacacs source-interface Loopback10
flow exporter MYFLOW destination 10.100.100.1 vrf Management-VRF
logging host 10.100.100.1 vrf Management-VRF
snmp-server host 10.100.100.1 vrf Management-VRF
access-class 10 in vrf-also
These example are based on ASR 1000s IOS 15.1
Don't be complacent
So now you are thinking easy, well not all version of code support VRF across all function e.g. ASR 9000 v 4.0.1 ISO XR current version does not support TACACS+ on a vrf. So don't take it for granted. Check you IOS.
I have ran into some issues recently be defining management loopbacks in their own VRF, only to find out that not everything is VRF "aware" by default, and in some cases cannot be VRF aware-ified. So I though I would put up some pointer so you can be VRF aware.