VRF-aware services in Cisco IOS
"Which Cisco IOS services work in a VRF?" is the question I get in almost any VRF-related discussion, so I made sure it’s covered very early in my Enterprise MPLS/VPN deployment webinar. This is the explanation I usually give in the webinar:
The generic rules are quite simple:
TCP stack in Cisco IOS is VRF-aware. Every TCP server running in Cisco IOS is thus VRF-aware by definition – when the router receives the TCP SYN packet, it associates the TCP session with the incoming VRF and the replies use the correct VRF automatically.
UDP is connectionless; UDP servers are on their own. The same trick does not work with UDP servers (including SNMP, DNS or DHCP servers). The UDP stack has no connection state and cannot associate incoming UDP requests with outgoing UDP responses. The UDP server has to extract VRF information from incoming packet and ensure the response is sent through the same VRF.
Each client has to be made VRF-aware. TCP/UDP clients running in Cisco IOS (SNMP traps, AAA, IP SLA ...) must have explicit VRF support, including VRF-aware configuration commands. The client must specify which VRF to use when establishing outgoing sessions (or sending outgoing UDP packets) and they usually have to get that information from router configuration. The same is true for all transport mechanisms (GRE, IPsec, VPDN ...) and forwarding-path functions (NAT).
Sometimes you can push the outgoing packets through the correct VRF with local policy-based routing. Obviously this “solution” doesn’t scale.
Many IOS services are already VRF-aware, but I’m positive you have your favorite grudge (for example, SSH client is still not VRF-aware). Please share it in the comments!
More information
The concept of Virtual Routing and Forwarding (VRF) tables, VRF-aware services, inter-VRF routing leaking and inter-VRF NAT are described in my Enterprise MPLS/VPN deployment webinar.
The Data Center Interconnect webinar describes how you can use MPLS/VPN between your data centers to ensure end-to-end layer-3 path isolation (or you could join the stretched VLAN craze and implement any of the L2 DCI technologies, which are also documented in the same webinar).
Both webinars are also available as part of the yearly subscription package.
If you have an access-class applied to your VTY lines (you -do- have an access-class on your VTY lines, don't you? ;) ) and need to SSH to a non-VRF interface as well as a VRF interface, you'll need to adjust the access-class configuration on your vty lines as follows:
access-class <number> in vrf-also
This would be less common in an MPLS VPN scenario than in an Internet-based VPN scenario, as it would be uncommon for a service provider to be connecting from both their address space and customer address space. In the Internet VPN scenario, there are some instance where connectivity may be required to either interface.
The vrf-also directive is documented at the very bottom of the following page.
http://www.cisco.com/en/US/docs/routers/asr1000/configuration/guide/chassis/Management_Ethernet.html</number>