[linux-vrf-core] VRF for Linux (MPLS IP VPNs)
Status: Beta
Brought to you by:
jleu
From: Nick E. <ni...@dc...> - 2001-10-10 14:35:51
|
Welcome to VRF for Linux! Please read this document to familiarize yourself with what we are trying to accomplish. [Initial blathering... (revised)] VRF - Virtual (or VPN) Routing/Forwarding instances are at the heart of aggregating multiple customers onto a single machine, while keeping their address spaces separate. VRFs allow two (or more) customers to have identical IP address spaces in use, while keeping them entirely separate withing the router. This is accomplished by maintaining separate L2/L3 tables for each customer (VPN). RFC 2547 describes the requirements for these MPLS VPNs in more detail. VRFs are requred in the Provider's Edge (PE) routers, which is what we are trying to build for Linux. The only issue not directly dealt with is how local traffic (processes running on the router) interace with the VRFs. (TODO: check this) Please read the attached references. Here are some very sketchy ideas on potential implemenations approaches for Linux: 1. minimal changes - keep existing rules and tables, use fwmarks to distinguish traffic internally. This CAN work for non-local traffic, and it is even possible with the OWNER netfilter target to set the fwmark for localally GENERATED traffic. However, how to handle local reception is not understood. I particular, how RIP, OSPF, BGP and the user process subsystem need to be modified is incomplete, and these would need to be modified to push their routes into specific tables. How do we fix up local subsystem to mark sockets (so gated, zebra, routed) work right. What about ping, traceroute, telnet, etc? /etc/hosts, dns? 2. separate, virtual netfilters, rt, rules, with extensions to break out of the virtual spaces for particular routing magic. Process subsystem would be modified to set it into a default VRF context (a'la chroot). Special mechanisms should be included so VRF-aware processes can change VRF membership for particular sockets. 3. virtual linux "machines". I know there is a project to virtualize the whole linux system running atop linux (name?). The issue them would be how to interconnect the routing, how to manage the system as a while, and how to handle PVCs (Frame, ATM) and VLANs. This is just a start. References below: http://www.juniper.net/techcenter/techpapers/200012.html This is a white paper by Juniper: RFC 2547bis: BGP/MPLS VPN Fundamentals It is a good introduction and has nice illustrations which quickly convey the essence of this concept. http://www.juniper.net/techcenter/techpapers/200014.html Another Junpier White Paper: RFC 2547bis: BGP/MPLS VPN Hierarchical and Recursive Applications http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st17/vpnid.htm Cisco: Discusses MPLS VPN ID (RFC 2685), which is used in dialup (RADIUS) and dhcp applications to identify to the servers to which VPN the request belongs. http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/vpnsc/mpls/1_2/prov_gd/vpn_ug1.htm Cisco: Indtroduction to MPLS VPN Technology Includes Cisco definiton of VRFs. http://www.mentortech.com/learn/welcher/papers/mplsvpn.html Another Intro to MPLS VPNs (RFC 2547). This one by MentorTech. Short, and clear. http://community.roxen.com/developers/idocs/rfc/rfc2917.html RFC 2917: another MPLS VPN RFC. They take a different approach to some of the VRF route-distributon issues, using Multicast to implement a virtual LAN between all the VRFs belonging to a VPN. Good reading. |