Virtual routing and forwarding: Difference between revisions
No edit summary |
|||
| (123 intermediate revisions by 90 users not shown) | |||
| Line 1: | Line 1: | ||
{{Short description|Computer networking technology}} |
|||
'''Virtual Routing and Forwarding''' ('''VRF''') is a technology used in computer networks that allows multiple instances of a [[routing table]] to co-exist within the same router at the same time. Because the routing instances are independent, the same or overlapping [[IP address|IP addresses]] can be used without conflicting with each other. |
|||
{{ref improve|date=January 2014}} |
|||
In [[Internet Protocol|IP-based]] [[computer network|computer networks]], '''virtual routing and forwarding''' ('''VRF''') is a technology that allows multiple instances of a [[routing table]] to co-exist within the same router at the same time. One or more logical or physical interfaces may have a VRF and these VRFs do not share routes. Therefore, the packets are only forwarded between interfaces on the same VRF. VRFs are the [[Internet Protocol | TCP/IP]] layer 3 equivalent of a [[VLAN]]. Because the routing instances are independent, the same or overlapping [[IP address|IP addresses]] can be used without conflicting with each other. Network functionality is improved because network paths can be segmented without requiring multiple routers.<ref>[https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/vrf/design/guide/vrfDesignGuide.html Cisco - Virtual Route Forwarding Design Guide]</ref> |
|||
'''VRF''' may be implemented in a network device by having distinct routing tables, also known as [[Forwarding Information Base]]s (FIBs), one per VRF. Alternatively, a network device may have the ability to configure different virtual routers, where each one has its own FIB that is not accessible to any other virtual router instance on the same device. |
|||
== Simple implementation == |
|||
| ⚫ | The simplest form of VRF implementation is |
||
| ⚫ | The simplest form of VRF implementation is VRF-Lite.<ref>{{citation |url=https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/31sg/configuration/guide/conf/vrf.pdf |title=Configuring VRF-lite |publisher=[[Cisco Systems]] |access-date=2020-12-30}}</ref> In this implementation, each router within the network participates in the virtual routing environment in a peer-based fashion. While simple to deploy and appropriate for small to medium enterprises and shared data centers, VRF Lite does not scale to the size required by global enterprises or large carriers, as there is the need to implement each VRF instance on every router, including intermediate routers. VRFs were initially introduced in combination with [[Multiprotocol Label Switching]] (MPLS), but VRF proved to be so useful that it eventually evolved to live independent of MPLS. This is the historical explanation of the term VRF Lite: usage of VRFs without MPLS. |
||
| ⚫ | The scaling limitations of |
||
[[File:Vrf.png|thumb|Example of a global and VRF Routing table summary with different routes/[[routing protocol]]]] |
|||
== Full implementation == |
|||
In a typical deployment, [[Customer Edge]] (CE) routers handle local routing in a traditional fashion and disseminate routing information into [[Provider Edge]] (PE) where the routing tables are virtualised. The PE router then encapsulates the traffic, marks it to identify the VRF instance, and transmits it across the provider backbone network to the destination PE router. The destination PE router then un-encapsulates the traffic and forwards it to the CE router at the destination. |
|||
| ⚫ | The scaling limitations of VRF Lite are resolved by the implementation of [[Internet Protocol|IP]] [[Virtual Private Network|VPN]]s. In this implementation, a core backbone network is responsible for the transmission of data across the wide area between VRF instances at each edge location. IP VPNs have been traditionally deployed by carriers to provide a shared wide-area backbone network for multiple customers. They are also appropriate in the large enterprise, multi-tenant and shared data center environments. |
||
The backbone network is completely transparent to the customer equipment, allowing multiple customers or user communities to |
In a typical deployment, [[customer edge router|customer edge]] (CE) routers handle local routing in a traditional fashion and disseminate routing information into the [[provider edge router|provider edge]] (PE) where the routing tables are virtualized. The PE router then encapsulates the traffic, marks it to identify the VRF instance, and transmits it across the provider backbone network to the destination PE router. The destination PE router then decapsulates the traffic and forwards it to the CE router at the destination. The backbone network is completely transparent to the customer equipment, allowing multiple customers or user communities to use the common backbone network while maintaining end-to-end traffic separation. |
||
Routes across the provider backbone network are maintained using an [[ |
Routes across the provider backbone network are maintained using an [[interior gateway protocol]] – typically [[BGP|iBGP]]. IBGP uses ''extended community'' attributes in a common routing table to differentiate the customers' routes with overlapping IP addresses. |
||
IP VPN is most commonly deployed across an MPLS backbone as the inherent labeling of packets in MPLS lends itself to the identification of the customer VRF. Some IP VPN implementations (notably Nortel's [[IP-VPN Lite]]) use a simpler [[IP in IP|IP-in-IP]] encapsulation over a pure IP backbone, eliminating the need to maintain and support an MPLS environment. |
|||
== |
==See also== |
||
* [[Layer 2 Forwarding Protocol]] |
|||
*[http://www.cisco.com/en/US/docs/net_mgmt/vpn_solutions_center/1.1/user/guide/VPN_UG1.html Cisco document on MPLS & VRF] |
|||
== References == |
|||
| ⚫ | |||
{{reflist}} |
|||
==External links== |
|||
| ⚫ | |||
*[https://web.archive.org/web/20110628060758/http://www.multicorepacketprocessing.com/implementing-virtual-routing-on-multicore-cpus-part-12/ VRFs with multicore packet processors] |
|||
*[https://web.archive.org/web/20160425054026/http://blog.ipexpert.com/vrf-route-leaking/ VRF Route Leaking] |
|||
*[http://support.nortel.com/go/main.jsp?cscat=DOCDETAIL&id=731634&poid=9015 Nortel IPVPN and IPVPN Lite Configuration documentation] |
|||
| ⚫ | |||
| ⚫ | |||
*[https://web.archive.org/web/20210824232159/https://avinetworks.com/glossary/virtual-routing-and-forwarding-vrf/ Virtual Routing And Forwarding (VRF)], [[Avi Networks]] |
|||
[[Category:MPLS networking]] |
[[Category:MPLS networking]] |
||
[[de:VRF-Instanz]] |
|||
Latest revision as of 15:37, 25 March 2024
 | This article needs additional citations for verification. (January 2014) |
In IP-based computer networks, virtual routing and forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same router at the same time. One or more logical or physical interfaces may have a VRF and these VRFs do not share routes. Therefore, the packets are only forwarded between interfaces on the same VRF. VRFs are the TCP/IP layer 3 equivalent of a VLAN. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other. Network functionality is improved because network paths can be segmented without requiring multiple routers.[1]
Simple implementation
[edit]The simplest form of VRF implementation is VRF-Lite.[2] In this implementation, each router within the network participates in the virtual routing environment in a peer-based fashion. While simple to deploy and appropriate for small to medium enterprises and shared data centers, VRF Lite does not scale to the size required by global enterprises or large carriers, as there is the need to implement each VRF instance on every router, including intermediate routers. VRFs were initially introduced in combination with Multiprotocol Label Switching (MPLS), but VRF proved to be so useful that it eventually evolved to live independent of MPLS. This is the historical explanation of the term VRF Lite: usage of VRFs without MPLS.
Full implementation
[edit]The scaling limitations of VRF Lite are resolved by the implementation of IP VPNs. In this implementation, a core backbone network is responsible for the transmission of data across the wide area between VRF instances at each edge location. IP VPNs have been traditionally deployed by carriers to provide a shared wide-area backbone network for multiple customers. They are also appropriate in the large enterprise, multi-tenant and shared data center environments.
In a typical deployment, customer edge (CE) routers handle local routing in a traditional fashion and disseminate routing information into the provider edge (PE) where the routing tables are virtualized. The PE router then encapsulates the traffic, marks it to identify the VRF instance, and transmits it across the provider backbone network to the destination PE router. The destination PE router then decapsulates the traffic and forwards it to the CE router at the destination. The backbone network is completely transparent to the customer equipment, allowing multiple customers or user communities to use the common backbone network while maintaining end-to-end traffic separation.
Routes across the provider backbone network are maintained using an interior gateway protocol – typically iBGP. IBGP uses extended community attributes in a common routing table to differentiate the customers' routes with overlapping IP addresses.
IP VPN is most commonly deployed across an MPLS backbone as the inherent labeling of packets in MPLS lends itself to the identification of the customer VRF. Some IP VPN implementations (notably Nortel's IP-VPN Lite) use a simpler IP-in-IP encapsulation over a pure IP backbone, eliminating the need to maintain and support an MPLS environment.
See also
[edit]References
[edit]- ^ Cisco - Virtual Route Forwarding Design Guide
- ^ Configuring VRF-lite (PDF), Cisco Systems, retrieved 2020-12-30