6WIND has been a leader in the network software industry for over 2 decades and today’s network evolution is towards defining function virtualization at the service infrastructure. At 6WIND, we are constantly reinventing how tomorrow’s networks would look like.
As a start to a multiple-blog series, we will introduce in this first part, how the Virtual Service Router designed by 6WIND can leverage the requirements of a light virtual Provider Edge functionality. The aim of these writings is to introduce our readers to the virtualized routing functions that are available with the 6WIND Virtual Service Router and how it can be used to build your MPLS networks.
1. What is a MPLS network?
Multiprotocol Label Switching (MPLS) is a routing technique in telecommunications networks that directs data from one node to the next based on short path labels rather than long network addresses, thus avoiding complex lookups in a routing table and speeding traffic flows. The labels identify virtual links or paths (LSP – Label Switched Path) between distant nodes rather than endpoints. MPLS can encapsulate packets of various network protocols, hence the “multiprotocol” reference on its name. MPLS, in its original designs, supports a range of access technologies, including T1/E1, ATM, Frame Relay, DSL and Ethernet.
Virtual routing and forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same virtual router at the same time. One or more logical or physical interfaces may belong to a VRF and these VRFs do not share routes (unless explicit leaking is configured) therefore the packets are only forwarded between interfaces within the same VRF.
VRFs can be defined as the TCP/IP layer 3 equivalent of a VLAN. Because the routing instances are independent, the same or overlapping IP addresses can be used in a given VRF without conflicting with other instances. Network functionality is improved because network paths can be segmented without requiring multiple routers.
A Route Distinguisher (RD) separates routes (one VRF for each customer routing table) of one customer from another. RD is prepended to each route (64-bit identifier is prepended) within a VRF to identify which VPN the route belongs to. An RD is carried along with a route via MP-BGP when exchanging VPN routes with other PE routers.
Route Target is a 64-bit identifier used as part of MP-BGP attribute (extended community) to identify which route should be exported or imported to specific VPN. Whereas route distinguishers are used to maintain uniqueness among identical routes in different VRFs, route targets can be used to share routes among them. We can apply route targets to a VRF to control the import and export of routes.
2. How can 6WIND help you build your MPLS Network?
Network Virtual Functions is becoming an attraction today when designing cloudified and virtualized architectures. We will demonstrate in this blog how the 6WIND Virtual Service Router can be deployed as a light MPLS virtual Provider Edge network function.
For the simplicity of this write-up we will showcase the MPLS Layer3 VRF functionality using Ethernet links on 6WIND’s Virtual Service Router and segregating our virtual MPLS router into two distinct L3VRFs (Cust1 and Cust2) each connecting a subset of sites as seen in the following diagram:
In this implementation, a virtual core backbone network is responsible for the transmission of data across the wide area between VRF instances at each edge location belonging to Cust1 and Cust2. This model of MPLS L3VPN has 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 virtual deployment, the virtual customer edge (vCE) routers handle local routing in a traditional fashion using static routes, IGP or eBGP and disseminate the routing information into the virtual provider edge (vPE) where the routing tables are virtualized. The vPE router then encapsulates the traffic, marks it with the RD/RT to identify the VRF instance, and transmits it across the provider backbone network to the destination vPE router. The destination vPE router then decapsulates the traffic based on the RD/RT identity and forwards it to the vCE 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.
The IP addressing for each customer is globally distinct except one entity that has an overlapping subnet with the other customer:
Cust1 uses subnets 10.0.0.0/24, 10.1.0.0/24 and 10.1.1.0/24 for its 3 site entities.
Cust2 uses subnets 10.0.0.0/24, 10.2.0.0/24 and 10.2.2.0/24 for its 3 site entities.
As a prerequisite and best practice for the 6WIND Virtual Router configuration, some elements should be configured on all nodes, such as, management vrf, system license and system fast path. As a reminder, The fast path is the Virtual Router component in charge of packet processing. To accelerate ethernet NICs, the latter must be dedicated to the fast path, and the fast path must be started. To note that in the GNS3 setup we simulated, the “–cpu host” option must be configured in the advanced additional settings when defining the virtual node properties.
vrf management
interface
physical management
port pci-b0s3 ← Physical port mapping (show state network-ports)
ipv4
dhcp
..
..
..
..
dns
server 8.8.8.8
..
..
system
hostname vP-RR
fast-path
port pci-b0s3
port pci-b0s4
port pci-b0s5
port pci-b0s6
port pci-b0s7
..
license
online
serial <License Key>
vrf management ← VRF that allows internet access for the licensing daemon
..
..
..
The following configuration is typical of a 6WIND Virtual Service Router performing label switching functionalities using the Open Shortest Path First (OSPF) as the underlying IGP with MPLS LDP enabled. For the purpose of this demo, we have enabled route-reflector (RR) capability on this virtual P Router to reduce the number of MP-BGP neighbors to be configured on each of the vPE routers. Typically, for a more complex setup, a VPNv4 RR is better to be designed in an out-of path deployment architecture:
vrf main
routing
mpls
ldp
router-id 10.10.10.10
address-family
ipv4
discovery
transport-address 10.10.10.10
..
interface Loop0
..
interface TO-vSER1
..
interface TO-vSER2
..
interface TO-vSER3
..
interface TO-vSER4
..
..
..
..
..
ospf
router-id 10.10.10.10
network 10.0.0.0/8 area 0
passive-interface Loop0
..
bgp
as 1000
router-id 10.10.10.10
address-family
ipv4-vpn
..
..
neighbor-group RR-CLIENT
remote-as 1000
update-source Loop0
address-family
ipv4-vpn
..
route-reflector-client true
..
..
..
neighbor 10.1.1.1
neighbor-group RR-CLIENT
..
neighbor 10.2.2.2
neighbor-group RR-CLIENT
..
neighbor 10.3.3.3
neighbor-group RR-CLIENT
..
neighbor 10.4.4.4
neighbor-group RR-CLIENT
..
..
..
interface
physical TO-vSER1
port pci-b0s4
ipv4
address 10.0.1.10/24
..
..
physical TO-vSER2
port pci-b0s5
ipv4
address 10.0.2.10/24
..
..
physical TO-vSER3
port pci-b0s6
ipv4
address 10.0.3.10/24
..
..
physical TO-vSER4
port pci-b0s7
ipv4
address 10.0.4.10/24
..
..
loopback Loop0
ipv4
address 10.10.10.10/32
..
..
..
..
The following configuration is typical of a 6WIND Virtual Service Edge Router acting as a PE router using OSPF as the underlying IGP with MPLS LDP enabled for label distribution and Multi-Protocol Border Gateway Protocol (MP-BGP) for L3VRF distribution and connectivity using the vpn-ipv4 address-family:
vrf main
routing
mpls
ldp
router-id 10.1.1.1
address-family
ipv4
discovery
transport-address 10.1.1.1
..
interface Loop0
..
interface TO-vP-RR
..
interface TO-vSER2
..
interface TO-vSER3
..
..
..
..
..
ospf
router-id 10.1.1.1
network 10.0.0.0/8 area 0
passive-interface Loop0
..
bgp
as 1000
router-id 10.1.1.1
address-family
ipv4-vpn
..
..
neighbor 10.10.10.10
remote-as 1000
update-source Loop0
address-family
ipv4-vpn
..
..
..
..
..
interface
physical TO-vSER2
port pci-b0s5
ipv4
address 10.1.2.1/24
..
..
physical TO-vSER3
port pci-b0s4
ipv4
address 10.1.3.1/24
..
..
physical TO-vP-RR
port pci-b0s7
ipv4
address 10.0.1.1/24
..
..
loopback Loop0
ipv4
address 10.1.1.1/32
..
..
xvrf Client1
link-interface main
link-vrf Client1
..
..
xvrf Client2
link-interface main
link-vrf Client2
..
..
..
vrf Client1
routing
bgp
as 1000
router-id 10.1.1.10
address-family
ipv4-unicast
network 10.0.0.0/24
..
network 10.1.1.10/32
..
redistribute connected
l3vpn
export
vpn true
label auto
route-target 1000:1
route-distinguisher 1000:1
..
import
vpn true
route-target 1000:1
..
..
..
..
..
..
interface
physical Client1
port pci-b0s6
ipv4
address 10.0.0.1/24
..
..
loopback Loop1
ipv4
address 10.1.1.10/32
..
..
xvrf main
link-interface Client1
link-vrf main
..
..
..
vrf Client2
routing
bgp
as 1000
router-id 10.1.1.20
address-family
ipv4-unicast
network 10.0.0.0/24
..
network 10.1.1.20/32
..
redistribute connected
l3vpn
export
vpn true
label auto
route-target 1000:2
route-distinguisher 1000:2
..
import
vpn true
route-target 1000:2
..
..
..
..
..
..
interface
physical Client2
port pci-b0s6
ipv4
address 10.0.0.1/24
..
..
loopback Loop1
ipv4
address 10.1.1.20/32
..
..
xvrf main
link-interface Client2
link-vrf main
..
..
..
Using Cross-VRF (xvrf) interfaces to perform vrf route leaking with BGP requires a specific semantic between VRs and interface names. VR naming must meet the requirements of interface naming. Actually, the Cross-VRF interface name chosen must be equal to the target VR the interface is connected to. To illustrate, in order to reach VR “main” from VR “Client1”, a Cross-VRF interface named “main” has to be created in VR “Client1”. Reversely, an Cross-VRF interface named “Client1” has to be created in VR “main”. In this way, the interface “main” and the interface “Client1” will be connected together. The naming convention is not only done to reflect the intent of the interface. It is mandatory to configure it in this way, if one wants to benefit from route leaking across VRs, using Cross-VRF interfaces, and BGP.
With the above configuration applied, VR route leaking is possible. Subsequently, if BGP peering is done between a CE and the BGP instance of each VR instance, then route importation and exportation occurs. Below output demonstrates that the routes from Client1 have been imported to the main vrf. The VR route leaks are visible with the @1< indicating that the route entry originated from VR Client1.
vSER1> show bgp vrf Client1 ipv4
BGP table version is 5, local router ID is 10.1.1.10, vrf id 2
Default local pref 100, local AS 1000
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop’s vrf id, < announce-nh-self
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
* 10.0.0.0/24 0.0.0.0 0 32768 ?
*> 0.0.0.0 0 32768 i
*> 10.0.1.0/24 10.2.2.2@1< 0 100 0 ?
* 10.1.1.10/32 0.0.0.0 0 32768 ?
*> 0.0.0.0 0 32768 i
*> 10.1.1.100/32 10.3.3.3@1< 0 100 0 ?
*> 10.2.2.20/32 10.2.2.2@1< 0 100 0 ?
Displayed 5 routes and 7 total paths
vSER2> show bgp ipv4 vpn
BGP table version is 5, local router ID is 10.2.2.2, vrf id 0
Default local pref 100, local AS 1000
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop’s vrf id, < announce-nh-self
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1000:1
*>i10.0.0.0/24 10.1.1.1 0 100 0 ?
*> 10.0.1.0/24 0.0.0.0@2< 0 32768 ?
0.0.0.0@2< 0 32768 i
*>i10.1.1.10/32 10.1.1.1 0 100 0 ?
*>i10.1.1.100/32 10.3.3.3 0 100 0 ?
*> 10.2.2.20/32 0.0.0.0@2< 0 32768 ?
Displayed 5 routes and 6 total paths
vSER2>
We verify that the routing tables to Client1 contain the correct routes to reach the adjacent site:
vSER1> show ipv4-routes vrf Client1
Codes: K – kernel route, C – connected, S – static, R – RIP,
O – OSPF, I – IS-IS, B – BGP, E – EIGRP, N – NHRP,
T – Table, v – VNC, V – VNC-Direct, A – Babel, D – SHARP,
F – PBR, f – OpenFabric,
> – selected route, * – FIB route, q – queued route, r – rejected route
VRF Client1:
C>* 10.0.0.0/24 is directly connected, Client1, 00:15:55
B>* 10.0.1.0/24 [200/0] is directly connected, main, label 82/80, 00:15:06
via 10.2.2.2(vrf main) (recursive), label 80, 00:15:06
* via 10.1.2.2, TO-vSER2(vrf main), label implicit-null/80, 00:15:06
C>* 10.1.1.10/32 is directly connected, Loop1, 00:16:06
B>* 10.1.1.100/32 [200/0] is directly connected, main, label 81/80, 00:15:07
via 10.3.3.3(vrf main) (recursive), label 80, 00:15:07
* via 10.1.3.3, TO-vSER3(vrf main), label implicit-null/80, 00:15:07
B>* 10.2.2.20/32 [200/0] is directly connected, main, label 82/80, 00:15:06
via 10.2.2.2(vrf main) (recursive), label 80, 00:15:06
* via 10.1.2.2, TO-vSER2(vrf main), label implicit-null/80, 00:15:06
vSER2> show ipv4-routes vrf Client1
Codes: K – kernel route, C – connected, S – static, R – RIP,
O – OSPF, I – IS-IS, B – BGP, E – EIGRP, N – NHRP,
T – Table, v – VNC, V – VNC-Direct, A – Babel, D – SHARP,
F – PBR, f – OpenFabric,
> – selected route, * – FIB route, q – queued route, r – rejected route
VRF Client1:
B>* 10.0.0.0/24 [200/0] is directly connected, main, label 81/80, 02:02:44
via 10.1.1.1(vrf main) (recursive), label 80, 02:02:44
* via 10.1.2.1, TO-vSER1(vrf main), label implicit-null/80, 02:02:44
C>* 10.0.1.0/24 is directly connected, Client1, 02:03:31
B>* 10.1.1.10/32 [200/0] is directly connected, main, label 81/80, 02:02:44
via 10.1.1.1(vrf main) (recursive), label 80, 02:02:44
* via 10.1.2.1, TO-vSER1(vrf main), label implicit-null/80, 02:02:44
B>* 10.1.1.100/32 [200/0] is directly connected, main, label 83/80, 02:02:37
via 10.3.3.3(vrf main) (recursive), label 80, 02:02:37
* via 10.0.2.10, TO-vP-RR(vrf main), label 21/80, 02:02:37
* via 10.1.2.1, TO-vSER1(vrf main), label 21/80, 02:02:37
* via 10.2.4.4, TO-vSER4(vrf main), label 23/80, 02:02:37
C>* 10.2.2.20/32 is directly connected, Loop2, 02:03:43
A quick look at the mpls forwarding tables and LDP bindings would show us the labels that were allocated for interfaces and prefixes:
vSER1> show mpls table
Inbound Label Type Nexthop Outbound Label
————————————————
16 LDP 10.0.1.10 implicit-null
16 LDP 10.1.2.2 implicit-null
17 LDP 10.0.1.10 implicit-null
17 LDP 10.1.3.3 implicit-null
18 LDP 10.0.1.10 implicit-null
19 LDP 10.1.2.2 implicit-null
20 LDP 10.1.2.2 implicit-null
21 LDP 10.1.3.3 implicit-null
22 LDP 10.1.3.3 implicit-null
23 LDP 10.0.1.10 23
23 LDP 10.1.3.3 21
23 LDP 10.1.2.2 23
24 LDP 10.0.1.10 implicit-null
80 BGP Client1 –
81 BGP 10.1.3.3 implicit-null
82 BGP 10.1.2.2 implicit-null
vSER1> show mpls ldp binding
AF Destination Nexthop Local Label Remote Label In Use
ipv4 10.0.1.0/24 10.2.2.2 imp-null 19 no
ipv4 10.0.1.0/24 10.3.3.3 imp-null 16 no
ipv4 10.0.1.0/24 10.10.10.10 imp-null imp-null no
ipv4 10.0.2.0/24 10.2.2.2 16 imp-null yes
ipv4 10.0.2.0/24 10.3.3.3 16 19 no
ipv4 10.0.2.0/24 10.10.10.10 16 imp-null yes
ipv4 10.0.3.0/24 10.2.2.2 17 20 no
ipv4 10.0.3.0/24 10.3.3.3 17 imp-null yes
ipv4 10.0.3.0/24 10.10.10.10 17 imp-null yes
ipv4 10.0.4.0/24 10.2.2.2 18 16 no
ipv4 10.0.4.0/24 10.3.3.3 18 20 no
ipv4 10.0.4.0/24 10.10.10.10 18 imp-null yes
ipv4 10.1.1.1/32 10.2.2.2 imp-null 21 no
ipv4 10.1.1.1/32 10.3.3.3 imp-null 17 no
ipv4 10.1.1.1/32 10.10.10.10 imp-null 16 no
ipv4 10.1.2.0/24 10.2.2.2 imp-null imp-null no
ipv4 10.1.2.0/24 10.3.3.3 imp-null 18 no
ipv4 10.1.2.0/24 10.10.10.10 imp-null 17 no
ipv4 10.1.3.0/24 10.2.2.2 imp-null 22 no
ipv4 10.1.3.0/24 10.3.3.3 imp-null imp-null no
ipv4 10.1.3.0/24 10.10.10.10 imp-null 18 no
ipv4 10.2.2.2/32 10.2.2.2 19 imp-null yes
ipv4 10.2.2.2/32 10.3.3.3 19 21 no
ipv4 10.2.2.2/32 10.10.10.10 19 21 no
ipv4 10.2.4.0/24 10.2.2.2 20 imp-null yes
ipv4 10.2.4.0/24 10.3.3.3 20 22 no
ipv4 10.2.4.0/24 10.10.10.10 20 22 no
ipv4 10.3.3.3/32 10.2.2.2 21 23 no
ipv4 10.3.3.3/32 10.3.3.3 21 imp-null yes
ipv4 10.3.3.3/32 10.10.10.10 21 19 no
ipv4 10.3.4.0/24 10.2.2.2 22 17 no
ipv4 10.3.4.0/24 10.3.3.3 22 imp-null yes
ipv4 10.3.4.0/24 10.10.10.10 22 20 no
ipv4 10.4.4.4/32 10.2.2.2 23 18 yes
ipv4 10.4.4.4/32 10.3.3.3 23 23 yes
ipv4 10.4.4.4/32 10.10.10.10 23 23 yes
ipv4 10.10.10.10/32 10.2.2.2 24 24 no
ipv4 10.10.10.10/32 10.3.3.3 24 24 no
ipv4 10.10.10.10/32 10.10.10.10 24 imp-null yes
vSER2> show mpls table
Inbound Label Type Nexthop Outbound Label
————————————————
16 LDP 10.0.2.10 implicit-null
16 LDP 10.2.4.4 implicit-null
17 LDP 10.2.4.4 implicit-null
18 LDP 10.2.4.4 implicit-null
19 LDP 10.1.2.1 implicit-null
19 LDP 10.0.2.10 implicit-null
20 LDP 10.0.2.10 implicit-null
21 LDP 10.1.2.1 implicit-null
22 LDP 10.1.2.1 implicit-null
23 LDP 10.1.2.1 21
23 LDP 10.0.2.10 19
23 LDP 10.2.4.4 23
24 LDP 10.0.2.10 implicit-null
80 BGP Client1 –
81 BGP 10.0.2.10 16
82 BGP 10.0.2.10 19
83 BGP 10.1.2.1 implicit-null
vSER2> show mpls ldp binding
AF Destination Nexthop Local Label Remote Label In Use
ipv4 10.0.1.0/24 10.1.1.1 19 imp-null yes
ipv4 10.0.1.0/24 10.4.4.4 19 19 no
ipv4 10.0.1.0/24 10.10.10.10 19 imp-null yes
ipv4 10.0.2.0/24 10.1.1.1 imp-null 16 no
ipv4 10.0.2.0/24 10.4.4.4 imp-null 16 no
ipv4 10.0.2.0/24 10.10.10.10 imp-null imp-null no
ipv4 10.0.3.0/24 10.1.1.1 20 17 no
ipv4 10.0.3.0/24 10.4.4.4 20 20 no
ipv4 10.0.3.0/24 10.10.10.10 20 imp-null yes
ipv4 10.0.4.0/24 10.1.1.1 16 18 no
ipv4 10.0.4.0/24 10.4.4.4 16 imp-null yes
ipv4 10.0.4.0/24 10.10.10.10 16 imp-null yes
ipv4 10.1.1.1/32 10.1.1.1 21 imp-null yes
ipv4 10.1.1.1/32 10.4.4.4 21 21 no
ipv4 10.1.1.1/32 10.10.10.10 21 16 no
ipv4 10.1.2.0/24 10.1.1.1 imp-null imp-null no
ipv4 10.1.2.0/24 10.4.4.4 imp-null 17 no
ipv4 10.1.2.0/24 10.10.10.10 imp-null 17 no
ipv4 10.1.3.0/24 10.1.1.1 22 imp-null yes
ipv4 10.1.3.0/24 10.4.4.4 22 22 no
ipv4 10.1.3.0/24 10.10.10.10 22 18 no
ipv4 10.2.2.2/32 10.1.1.1 imp-null 19 no
ipv4 10.2.2.2/32 10.4.4.4 imp-null 18 no
ipv4 10.2.2.2/32 10.10.10.10 imp-null 21 no
ipv4 10.2.4.0/24
ipv4 10.2.4.0/24 10.4.4.4 imp-null imp-null no
ipv4 10.2.4.0/24 10.10.10.10 imp-null 22 no
ipv4 10.3.3.3/32 10.1.1.1 23 21 yes
ipv4 10.3.3.3/32 10.4.4.4 23 23 yes
ipv4 10.3.3.3/32 10.10.10.10 23 19 yes
ipv4 10.3.4.0/24 10.1.1.1 17 22 no
ipv4 10.3.4.0/24 10.4.4.4 17 imp-null yes
ipv4 10.3.4.0/24 10.10.10.10 17 20 no
ipv4 10.4.4.4/32 10.1.1.1 18 23 no
ipv4 10.4.4.4/32 10.4.4.4 18 imp-null yes
ipv4 10.4.4.4/32 10.10.10.10 18 23 no
ipv4 10.10.10.10/32 10.1.1.1 24 24 no
ipv4 10.10.10.10/32 10.4.4.4 24 24 no
ipv4 10.10.10.10/32 10.10.10.10 24 imp-null yes
vP-RR> show mpls ldp binding
AF Destination Nexthop Local Label Remote Label In Use
ipv4 10.0.1.0/24 10.1.1.1 imp-null imp-null no
ipv4 10.0.1.0/24 10.2.2.2 imp-null 19 no
ipv4 10.0.1.0/24 10.3.3.3 imp-null 16 no
ipv4 10.0.1.0/24 10.4.4.4 imp-null 19 no
ipv4 10.0.2.0/24 10.1.1.1 imp-null 16 no
ipv4 10.0.2.0/24 10.2.2.2 imp-null imp-null no
ipv4 10.0.2.0/24 10.3.3.3 imp-null 19 no
ipv4 10.0.2.0/24 10.4.4.4 imp-null 16 no
ipv4 10.0.3.0/24 10.1.1.1 imp-null 17 no
ipv4 10.0.3.0/24 10.2.2.2 imp-null 20 no
ipv4 10.0.3.0/24 10.3.3.3 imp-null imp-null no
ipv4 10.0.3.0/24 10.4.4.4 imp-null 20 no
ipv4 10.0.4.0/24 10.1.1.1 imp-null 18 no
ipv4 10.0.4.0/24 10.2.2.2 imp-null 16 no
ipv4 10.0.4.0/24 10.3.3.3 imp-null 20 no
ipv4 10.0.4.0/24 10.4.4.4 imp-null imp-null no
ipv4 10.1.1.1/32 10.1.1.1 16 imp-null yes
ipv4 10.1.1.1/32 10.2.2.2 16 21 yes
ipv4 10.1.1.1/32 10.3.3.3 16 17 no
ipv4 10.1.1.1/32 10.4.4.4 16 21 no
ipv4 10.1.2.0/24 10.1.1.1 17 imp-null yes
ipv4 10.1.2.0/24 10.2.2.2 17 imp-null yes
ipv4 10.1.2.0/24 10.3.3.3 17 18 no
ipv4 10.1.2.0/24 10.4.4.4 17 17 no
ipv4 10.1.3.0/24 10.1.1.1 18 imp-null yes
ipv4 10.1.3.0/24 10.2.2.2 18 22 yes
ipv4 10.1.3.0/24 10.3.3.3 18 imp-null yes
ipv4 10.1.3.0/24 10.4.4.4 18 22 no
ipv4 10.2.2.2/32 10.1.1.1 21 19 no
ipv4 10.2.2.2/32 10.2.2.2 21 imp-null yes
ipv4 10.2.2.2/32 10.3.3.3 21 21 no
ipv4 10.2.2.2/32 10.4.4.4 21 18 no
ipv4 10.2.4.0/24 10.1.1.1 22 20 no
ipv4 10.2.4.0/24 10.2.2.2 22 imp-null yes
ipv4 10.2.4.0/24 10.3.3.3 22 22 no
ipv4 10.2.4.0/24 10.4.4.4 22 imp-null yes
ipv4 10.3.3.3/32 10.1.1.1 19 21 no
ipv4 10.3.3.3/32 10.2.2.2 19 23 no
ipv4 10.3.3.3/32 10.3.3.3 19 imp-null yes
ipv4 10.3.3.3/32 10.4.4.4 19 23 no
ipv4 10.3.4.0/24 10.1.1.1 20 22 no
ipv4 10.3.4.0/24 10.2.2.2 20 17 no
ipv4 10.3.4.0/24 10.3.3.3 20 imp-null yes
ipv4 10.3.4.0/24 10.4.4.4 20 imp-null yes
ipv4 10.4.4.4/32 10.1.1.1 23 23 no
ipv4 10.4.4.4/32 10.2.2.2 23 18 no
ipv4 10.4.4.4/32 10.3.3.3 23 23 no
ipv4 10.4.4.4/32 10.4.4.4 23 imp-null yes
ipv4 10.10.10.10/32 10.1.1.1 imp-null 24 no
ipv4 10.10.10.10/32 10.2.2.2 imp-null 24 no
ipv4 10.10.10.10/32 10.3.3.3 imp-null 24 no
ipv4 10.10.10.10/32 10.4.4.4 imp-null 24 no
The following configuration is typical of the virtual CE router used in our setup. The vCE-vPE routing can be a static route, OSPF or eBGP.
CE1> show config nodefault
vrf management
interface
physical management
port pci-b0s3
ipv4
dhcp
..
..
..
..
dns
server 8.8.8.8
..
..
vrf main
routing
static
ipv4-route 0.0.0.0/0
next-hop 10.0.0.1
..
..
..
interface
physical MPLS1
port pci-b0s4
ipv4
address 10.0.0.10/24
..
..
..
..
system
hostname CE1
license
online
serial <License Key>
vrf management
..
..
..
To test the end-to-end functionality of our setup we will issue the traditional ping between the end client and capture the traffic on outgoing interfaces to check the label advertisements:
vSER2 running config# cmd traffic-capture TO-vP-RR
14:42:08.316163 0c:6c:ef:04:00:04 > 0c:6f:02:17:00:02, ethertype MPLS unicast (0x8847), length 106: MPLS (label 16, exp 0, ttl 63) (label 80, exp 0, [S], ttl 64) 10.0.1.1 > 10.0.0.10: ICMP echo reply, id 6044, seq 45, length 64
vSER1> cmd traffic-capture TO-vP-RR
14:43:55.661653 0c:bb:4a:bd:00:04 > 0c:6f:02:17:00:01, ethertype MPLS unicast (0x8847), length 106: MPLS (label 21, exp 0, ttl 62) (label 80, exp 0, [S], ttl 63) 10.0.0.10 > 10.0.1.1: ICMP echo request, id 6141, seq 1, length 64
14:43:55.662706 0c:6f:02:17:00:01 > 0c:bb:4a:bd:00:04, ethertype MPLS unicast (0x8847), length 106: MPLS (label 21, exp 0, ttl 62) (label 80, exp 0, [S], ttl 64) 10.0.1.1 > 10.0.0.10: ICMP echo reply, id 6141, seq 1, length 64
In the above example, we can see the label 80 assigned by BGP for the VRF Client1 and transport labels from vSER1 and vSER2 are set by LDP to 21 and 16 respectively as already listed in the show mpls table output above.
This concludes our first blog about the 6WIND Virtual Service Router capabilities to operate with MPLS L3VPN functionalities.
In the forthcoming series, we would discuss additional deployment scenarios for MPLS L3VPN and how our technology would help you to transition from traditional hardware vendor lock-in to a virtualized and open deployment model.
We would be glad to get in touch with you should you have any questions related to this post and would be more than happy to discuss further your current and future requirement: marketing@6wind.com
Thank you for your sharing. I am worried that I lack creative ideas. It is your article that makes me full of hope. Thank you. But, I have a question, can you help me?