0
1 votes
MPLS Part 2
06 September 2010
MPLS part 2
MPLS VPNs
1. Overview of MPLS VPNs
It is important to note that the term “VPN” is indicative of a private network, this does not implicitly guarantee encryption. We are so used to IPsec or SSL VPNs that we assume this to be the case. MPLS VPNs do not make use of encryption or authentication, for now. In its simplest sense, an MPLS VPN allows the private connection of two geographically separate network via a transit core. In most cases this traffic traverses the ISP MPLS backbone.
MPLS VPNs make use of 3 core technologies:
1. VRFs on the edge routers separate customer routing tables to provide privacy
2. MP-BGP is used by the ISP edge routers to propagate the layer 3 information of all the VPN endpoints and subnets. Customer routes are redistributed into MP-BGP, and identification is provided through route distinguishers (RDs) and route targets (RTs). RDs are used to cope with overlapping customer subnets. RTs are used to delimit the set of prefixes to import or export. Please note that if you import a RT into multiple VRFs you are effectively leaking those routes into other VPNv4 address spaces.
3. MPLS is used to label the VPN instance for which the packet is destined as it traverses the core.
Router terms are:
C - Customer. Internal customer routers, not active in MPLS VPNs
CE - Customer Edge. Shares internal routes with PE, not MPLS enabled
PE - Provider Edge. Here is where most of the action is. Accepts customer routes into VRFs, uses MP-BGP to advertise VPN targets to other edge routers, participates in MPLS.
P - Provider. These are the core routers that use MPLS for forwarding. Generally they will run an IGP such as OSPF or IS-IS for internal reachability
I will be using this topology for the rest of this example:
A more detailed explanation of the router roles follows:
Customer Edge Router:
These routers will peer with the PE routers with a dynamic routing protocol (usually OSPF or ISIS) and advertise the desired prefixes into their VRF. These prefixes will be reachable from the VPN targets the customer chooses. Generally the ISP will provide full readability between all customer sites, however selective omission is possible.
Configuration of the CE routers is relatively simple, for the purposes of demonstration I will use loopback interfaces on the CE routers to emulate internal networks. I will also skip over the IP addressing, static route, standard OSPF and MPLS configuration:
1. Set IP addressing
2. Configure a default route to the PE router
3. Configure OSPF area 0 between CE and PE.
Provider Edge Routers:
1. Configure VRF instances on CE-PE links. Note: This should be done prior to IP addressing because it will wipe out an interfaces IP when assigned:
2. Set IP addressing. This should include a loopback interface advertised into the core IGP instance (200.0.0.1/32 in this case for PE1)
3. Configure the IGP on the PE to peer with the CE via VRF. OSPF in this case
Verify with:
4. Configure MPLS and IGP to core
5. Configure MP-BGP to PE2
Provider Routers:
1. Set IP addressing
2. Configure IGP (OSPF) instance
3. Enable MPLS
To verify functionality check the routing tables of the CE routers:
The routing tables of the P routers should not show these prefixes:
B
At this point we have satisfied our VPN requirement: customer networks are private, as seen by the lack of routing entries for the 2.2.0.0/16 prefix in the P or Customer B CE routers.
We can also easily manipulate the prefixes advertised into the CE routing table with a simple route map entry. For example, I am going to filter out the 2.2.2.1/32 entry from being advertised into the CUST-A vrf:
Additionally we could use a separate route target to advertise subsets of the customer networks to different VPNv4 peers. Imagine that CUST-B uses a VoIP service from customer A that requires they have access to their CallCenter server at IP 2.2.2.2.
To do this we can use an export map under the VRF for CUST-A:
We will create a new route-target import statement on both PE routers for CUST-B VRF:
On PE2 where the prefix for 2.2.2.2/32 is advertised into VPNv4 we will create an access-list to match the prefix:
Next we create a route-map:
P
Apply the route-map as to the CUST-A VRF:
Clear the MP-BGP session
And now the routing table for B1CE should show a route to 2.2.2.2/32:
Success!
Please note only one export map can be configured per VRF
That’s all for now
~sly
MPLS VPNs
1. Overview of MPLS VPNs
It is important to note that the term “VPN” is indicative of a private network, this does not implicitly guarantee encryption. We are so used to IPsec or SSL VPNs that we assume this to be the case. MPLS VPNs do not make use of encryption or authentication, for now. In its simplest sense, an MPLS VPN allows the private connection of two geographically separate network via a transit core. In most cases this traffic traverses the ISP MPLS backbone.
MPLS VPNs make use of 3 core technologies:
1. VRFs on the edge routers separate customer routing tables to provide privacy
2. MP-BGP is used by the ISP edge routers to propagate the layer 3 information of all the VPN endpoints and subnets. Customer routes are redistributed into MP-BGP, and identification is provided through route distinguishers (RDs) and route targets (RTs). RDs are used to cope with overlapping customer subnets. RTs are used to delimit the set of prefixes to import or export. Please note that if you import a RT into multiple VRFs you are effectively leaking those routes into other VPNv4 address spaces.
3. MPLS is used to label the VPN instance for which the packet is destined as it traverses the core.
Router terms are:
C - Customer. Internal customer routers, not active in MPLS VPNs
CE - Customer Edge. Shares internal routes with PE, not MPLS enabled
PE - Provider Edge. Here is where most of the action is. Accepts customer routes into VRFs, uses MP-BGP to advertise VPN targets to other edge routers, participates in MPLS.
P - Provider. These are the core routers that use MPLS for forwarding. Generally they will run an IGP such as OSPF or IS-IS for internal reachability
I will be using this topology for the rest of this example:
A more detailed explanation of the router roles follows:
Customer Edge Router:
These routers will peer with the PE routers with a dynamic routing protocol (usually OSPF or ISIS) and advertise the desired prefixes into their VRF. These prefixes will be reachable from the VPN targets the customer chooses. Generally the ISP will provide full readability between all customer sites, however selective omission is possible.
Configuration of the CE routers is relatively simple, for the purposes of demonstration I will use loopback interfaces on the CE routers to emulate internal networks. I will also skip over the IP addressing, static route, standard OSPF and MPLS configuration:
1. Set IP addressing
2. Configure a default route to the PE router
3. Configure OSPF area 0 between CE and PE.
Provider Edge Routers:
1. Configure VRF instances on CE-PE links. Note: This should be done prior to IP addressing because it will wipe out an interfaces IP when assigned:
PE1(config)#ip vrf CUST-A PE1(config-vrf)#rd 1:100 PE1(config-vrf)#route-target both 1:100 PE1(config-vrf)#int f0/1 PE1(config-if)#ip vrf forwarding CUST-A PE1(config-if)#ip vrf CUST-B PE1(config-vrf)#rd 2:200 PE1(config-vrf)#route-tar both 2:200 PE1(config-vrf)#int f0/0 PE1(config-if)#ip vrf for CUST-B
2. Set IP addressing. This should include a loopback interface advertised into the core IGP instance (200.0.0.1/32 in this case for PE1)
3. Configure the IGP on the PE to peer with the CE via VRF. OSPF in this case
PE1(config)#no router ospf 1 PE1(config)#router ospf 1 vrf CUST-A PE1(config-router)#net 192.168.1.0 0.0.0.255 area 0 PE1(config)#router ospf 2 vrf CUST-B PE1(config-router)#net 192.168.0.0 0.0.0.255 area 0
Verify with:
PE1#sh ip route vrf CUST-A
4. Configure MPLS and IGP to core
PE1(config)#mpls label protocol ldp PE1(config)#int f1/0 PE1(config-if)#mpls ip PE1(config-if)#int f2/0 PE1(config-if)#mpls ip PE1(config-if)#router ospf 100 PE1(config-router)#net 10.0.0.0 0.0.255.255 area 0
5. Configure MP-BGP to PE2
PE1(config)#router bgp 65400 PPE1(config-router)#address-family ipv4 vrf CUST-A PE1(config-router-af)#redistribute ospf 1 vrf CUST-A PE1(config-router-af)#address-family ipv4 vrf CUST-B PE1(config-router-af)#redistribute ospf 2 vrf CUST-B PE1(config-router-af)#router ospf 1 vrf CUST-A PE1(config-router)#redistribute bgp 65400 subnets PE1(config-router)#router ospf 2 vrf CUST-B PE1(config-router)#redist bgp 65400 sub PE1(config-router)#neighbor 200.0.0.2 remote-as 65400 PE1(config-router)#neigh 200.0.0.2 update-source lo0 PE1(config-router)#address-family vpnv4 PE1(config-router-af)#neigh 200.0.0.2 activate PE1(config-router-af)#neigh 200.0.0.2 send-community
Provider Routers:
1. Set IP addressing
2. Configure IGP (OSPF) instance
3. Enable MPLS
To verify functionality check the routing tables of the CE routers:
A1CE#sh ip route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 2 subnets
C 1.1.1.0 is directly connected, Loopback0
C 1.1.2.0 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 2 subnets
O IA 2.2.2.2 [110/21] via 192.168.1.1, 00:00:50, FastEthernet0/1
O IA 2.2.1.2 [110/21] via 192.168.1.1, 00:00:50, FastEthernet0/1
172.22.0.0/24 is subnetted, 1 subnets
O IA 172.22.1.0 [110/11] via 192.168.1.1, 00:00:50, FastEthernet0/1
The routing tables of the P routers should not show these prefixes:
P1#sh ip route
200.0.0.0/32 is subnetted, 2 subnets
O 200.0.0.1 [110/2] via 10.0.11.1, 00:08:53, FastEthernet1/0
O 200.0.0.2 [110/12] via 10.1.13.30, 00:09:20, FastEthernet0/0
10.0.0.0/24 is subnetted, 7 subnets
C 10.0.11.0 is directly connected, FastEthernet1/0
C 10.1.14.0 is directly connected, FastEthernet2/0
C 10.1.13.0 is directly connected, FastEthernet0/0
C 10.1.12.0 is directly connected, FastEthernet0/1
O 10.1.23.0 [110/11] via 10.1.13.30, 00:34:57, FastEthernet0/0
O 10.1.34.0 [110/20] via 10.1.13.30, 00:34:57, FastEthernet0/0
O 10.0.32.0 [110/11] via 10.1.13.30, 00:34:08, FastEthernet0/0
Nor should the CE routers for the other company (vrf CUST-B
1CE#sh ip route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
172.22.0.0/24 is subnetted, 1 subnets
O IA 172.22.0.0 [110/11] via 192.168.0.1, 00:01:11, FastEthernet0/0
C 192.168.0.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 is directly connected, FastEthernet0/0
At this point we have satisfied our VPN requirement: customer networks are private, as seen by the lack of routing entries for the 2.2.0.0/16 prefix in the P or Customer B CE routers.
We can also easily manipulate the prefixes advertised into the CE routing table with a simple route map entry. For example, I am going to filter out the 2.2.2.1/32 entry from being advertised into the CUST-A vrf:
PE2(config)#no route-map CUST-A-BLOCK permit 10
PE2(config)#route-map CUST-A-BLOCK deny 10
PE2(config-route-map)#match ip address 10
PE2(config-route-map)#route-map CUST-A-BLOCK permit 20
PE2(config-route-map)#access-list 10 permit 2.2.2.0 0.0.0.255
PE2(config)#router bgp 65400
PE2(config-router)#address-family ipv4 vrf CUST-A
PE2(config-router-af)#redistribute ospf 1 vrf CUST-A rou
PE2(config-router-af)#redistribute ospf 1 vrf CUST-A route-map CUST-A-BLOCK
PE2(config-router-af)#do clear ip bgp * soft out
E2#sh ip bgp vpnv4 vrf CUST-A
BGP table version is 20, local router ID is 200.0.0.2
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:100 (default for vrf CUST-A)
*>i1.1.1.1/32 200.0.0.1 11 100 0 ?
*>i1.1.2.1/32 200.0.0.1 11 100 0 ?
*> 2.2.1.2/32 172.22.1.101 11 32768 ?
*> 172.22.1.0/24 0.0.0.0 0 32768 ?
*>i192.168.1.0 200.0.0.1 0 100 0 ?
A1CE#sh ip route 2.2.2.0 255.255.255.0
% Subnet not in table
A1CE#sh ip route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 2 subnets
C 1.1.1.0 is directly connected, Loopback0
C 1.1.2.0 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 1 subnets
O IA 2.2.1.2 [110/21] via 192.168.1.1, 00:14:43, FastEthernet0/1
172.22.0.0/24 is subnetted, 1 subnets
O IA 172.22.1.0 [110/11] via 192.168.1.1, 00:14:43, FastEthernet0/1
C 192.168.1.0/24 is directly connected, FastEthernet0/1
A1CE#
Additionally we could use a separate route target to advertise subsets of the customer networks to different VPNv4 peers. Imagine that CUST-B uses a VoIP service from customer A that requires they have access to their CallCenter server at IP 2.2.2.2.
To do this we can use an export map under the VRF for CUST-A:
We will create a new route-target import statement on both PE routers for CUST-B VRF:
PE1(config)#ip vrf CUST-B PE1(config-vrf)#route-target import 1:200 PE2(config)#ip vrf CUST-B PE2(config-vrf)#route-target import 1:200
On PE2 where the prefix for 2.2.2.2/32 is advertised into VPNv4 we will create an access-list to match the prefix:
PE2(config)#access-list 20 permit 2.2.2.0 0.0.0.255
Next we create a route-map:
P
E2(config)#route-map TO-CUST-B permit 10 PE2(config-route-map)#match ip address 20 PE2(config-route-map)#set extcommunity rt 1:200
Apply the route-map as to the CUST-A VRF:
PE2(config)#ip vrf CUST-A PE2(config-vrf)#export map TO-CUST-B
Clear the MP-BGP session
PE2(config)#do clear ip bgp * soft out
And now the routing table for B1CE should show a route to 2.2.2.2/32:
B1CE#sh ip route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/11] via 192.168.0.1, 00:06:02, FastEthernet0/0
172.22.0.0/24 is subnetted, 1 subnets
O IA 172.22.0.0 [110/11] via 192.168.0.1, 00:06:02, FastEthernet0/0
C 192.168.0.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 is directly connected, FastEthernet0/0
Success!
Please note only one export map can be configured per VRF
That’s all for now
~sly
Thanks for the share.... good one.
jag