MPLS L3VPN Internet Access (Option 3)
Feb 13, 2020
Knowledge
Cisco Admin
Moving forward for our third option for providing Internet access
through MPLS L3VPN service
We will be relying now on establishing MP-BGP session between our
ASBR and our serving PE to transport the Internet prefixes of concern
inside the desired VRF
What actually happen is similar to what so called shared services VRF
for which the spokes can communicate with something common inside
the HQ network
Manipulating the route-target values will accomplish the desired lane
of communication between the customer network and the Internet
cloud
As we are talking about route-target values that means VRF (Virtual
Routing and Forwarding) is involved
What we will do is configuring a new VRF on our ASBR and place the
uplink in that specific VRF and establishing eBGP session with the INET
router or using static routing
As can be seen in the below figure, a new VRF is now attached to the
connection from ASBR to the INET
Just a quick reminder about what the route-target value:
The route-target value is used to control the import/export mechanism
inside a VRF, in humble words which prefixes are allowed to go out and
which prefixes are allowed to move in
Basically what will happen in our scenario here is that the RD (Route
Distinguisher) value for the new VRF will be allowed to enter the
customer VRF and the customer VRF RD will be allowed to enter the
new VRF to allow bi-directional communication
Let us have a look at a sample from the needed configurations:
ASBR:
ip vrf INET
rd 10:10
route-target export 10:10
route-target import 10:10
route-target import 1:1
route-target import 2:2
interface FastEthernet2/0
ip vrf forwarding INET
We will be using BGP between ASBR and INET routers:
router bgp 1
address-family ipv4 vrf INET
neighbor 212.118.23.3 remote-as 3
neighbor 212.118.23.3 activate
exit-address-family
R2-ASBR#show bgp vpnv4 unicast all neighbors 212.118.23.3 routes
BGP table version is 17, local router ID is 212.118.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10:10 (default for vrf INET)
*> 3.3.3.3/32 212.118.23.3 0 0 3 i
Total number of prefixes 1
R2-ASBR#show bgp vpnv4 unicast all neighbors 4.4.4.4 advertised-
routes
BGP table version is 17, local router ID is 212.118.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10:10 (default for vrf INET)
*> 3.3.3.3/32 212.118.23.3 0 0 3 i
Total number of prefixes 1
R4-PE#show bgp vpnv4 unicast all neighbors 2.2.2.2 routes
BGP table version is 33, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf MSSK)
*>i 3.3.3.3/32 2.2.2.2 0 100 0 3 i
Route Distinguisher: 2:2 (default for vrf ABC)
*>i 3.3.3.3/32 2.2.2.2 0 100 0 3 i
Route Distinguisher: 10:10
*>i 3.3.3.3/32 2.2.2.2 0 100 0 3 i
We are already performing redistribution between the MP-BGP and
RIPv2 routing instances, so the new route should pass through to the
customers RIB:
R6-CE#sh ip route rip
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
3.0.0.0/32 is subnetted, 1 subnets
R 3.3.3.3 [120/1] via 192.168.46.4, 00:00:11, FastEthernet1/0.46
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
R 10.10.7.0/24 [120/1] via 192.168.46.4, 00:00:11, FastEthernet1/0.46
13.0.0.0/32 is subnetted, 1 subnets
R 13.13.13.13 [120/1] via 192.168.46.4, 00:00:11, FastEthernet1/0.46
R 192.168.57.0/24 [120/1] via 192.168.46.4, 00:00:11,
FastEthernet1/0.46
And yes it is installed as expected, before checking the ICMP
connectivity, let us check the INET RIB:
R3-INET#show ip bgp
BGP table version is 9, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 3.3.3.3/32 0.0.0.0 0 32768 i
*> 10.10.6.0/24 212.118.23.2 0 1 ?
*> 10.10.8.0/24 212.118.23.2 0 1 ?
*> 192.168.46.0 212.118.23.2 0 1 ?
*> 192.168.48.0 212.118.23.2 0 1 ?
R6-CE#ping 3.3.3.3 source lo1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.10.6.6
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/72/80
ms
Let us have a look at the BGP relations included in this design option:
One caveat to be mentioned regarding this design option (as
mentioned in the CCDE study guide) as we are importing routes (not
default route in this example), what will happen is that a label is
assigned per each prefix (currently we are having one prefix)
In order to clearly demonstrate this, we will configure a new route on
the INET and advertise it to be reachable via the customers:
R2-ASBR#show ip bgp vpnv4 vrf INET labels
Network Next Hop In label/Out label
Route Distinguisher: 10:10 (INET)
3.3.3.3/32 212.118.23.3 22/nolabel
10.10.6.0/24 4.4.4.4 nolabel/19
10.10.8.0/24 4.4.4.4 nolabel/25
13.13.13.13/32 212.118.23.3 23/nolabel
192.168.46.0 4.4.4.4 nolabel/21
192.168.48.0 4.4.4.4 nolabel/18
Now assuming a customer needs full routing table to be available,
what will happen per the current label allocation mode (which is per
prefix), is that every prefix will be assigned a label and from a
scalability perspective this could overwhelm the table
R4-PE#show ip bgp vpnv4 vrf MSSK labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (MSSK)
3.3.3.3/32 2.2.2.2 nolabel/22
10.10.6.0/24 192.168.46.6 19/nolabel
10.10.7.0/24 5.5.5.5 nolabel/20
13.13.13.13/32 2.2.2.2 nolabel/23
192.168.46.0 0.0.0.0 21/nolabel(MSSK)
192.168.57.0 5.5.5.5 nolabel/16
R4-PE#show ip bgp vpnv4 vrf ABC labels
Network Next Hop In label/Out label
Route Distinguisher: 2:2 (ABC)
3.3.3.3/32 2.2.2.2 nolabel/22
10.10.8.0/24 192.168.48.8 25/nolabel
13.13.13.13/32 2.2.2.2 nolabel/23
192.168.48.0 0.0.0.0 18/nolabel(ABC)
What can be done to properly utilize our available resources is to
change the label allocation mode to per VRF instead of per prefix:
ASBR:
mpls label mode vrf INET protocol bgp-vpnv4 per-vrf
R2-ASBR#show ip bgp vpnv4 vrf INET labels
Network Next Hop In label/Out label
Route Distinguisher: 10:10 (INET)
3.3.3.3/32 212.118.23.3 IPv4 VRF Aggr:24/nolabel
10.10.6.0/24 4.4.4.4 nolabel/19
10.10.8.0/24 4.4.4.4 nolabel/25
13.13.13.13/32 212.118.23.3 IPv4 VRF Aggr:24/nolabel
192.168.46.0 4.4.4.4 nolabel/21
192.168.48.0 4.4.4.4 nolabel/18
R4-PE#show ip bgp vpnv4 vrf MSSK labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (MSSK)
3.3.3.3/32 2.2.2.2 nolabel/24
10.10.6.0/24 192.168.46.6 19/nolabel
10.10.7.0/24 5.5.5.5 nolabel/20
13.13.13.13/32 2.2.2.2 nolabel/24
192.168.46.0 0.0.0.0 21/nolabel(MSSK)
192.168.57.0 5.5.5.5 nolabel/16
R4-PE#show ip bgp vpnv4 vrf ABC labels
Network Next Hop In label/Out label
Route Distinguisher: 2:2 (ABC)
3.3.3.3/32 2.2.2.2 nolabel/24
10.10.8.0/24 192.168.48.8 25/nolabel
13.13.13.13/32 2.2.2.2 nolabel/24
192.168.48.0 0.0.0.0 18/nolabel(ABC)
And before closing and moving to the fourth option, let us check the
roles for our running devices with respect to the different protocols
involved:
Note: As can be seen from the above, we did not configure NAT and
that is why NAT boxes are not marked
Let us quickly configure NAT on CE side (which will give the customer
to control the Internet access)
CE:
access-list 10 permit 10.10.8.0 0.0.0.255
ip nat pool POOL 62.215.10.1 62.215.10.254 prefix-length 24
int FastEthernet1/0.48
ip nat outside
int lo1
ip nat inside
PE:
ip route vrf ABC 62.215.10.0 255.255.255.0 192.168.48.8
router bgp 1
address-family ipv4 vrf ABC
redistribute static
R2-ASBR#show bgp vpnv4 unicast all 62.215.10.0
BGP routing table entry for 2:2:62.215.10.0/24, version 22
Paths: (1 available, best #1, no table)
Not advertised to any peer
Refresh Epoch 1
Local
4.4.4.4 (metric 3) from 4.4.4.4 (4.4.4.4)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:2:2
mpls labels in/out nolabel/28
rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 10:10:62.215.10.0/24, version 23
Paths: (1 available, best #1, table INET)
Advertised to update-groups:
8
Refresh Epoch 1
Local, imported path from 2:2:62.215.10.0/24 (global)
4.4.4.4 (metric 3) from 4.4.4.4 (4.4.4.4)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:2:2
mpls labels in/out nolabel/28
rx pathid: 0, tx pathid: 0x0
R3-INET#sh ip bgp 62.215.10.0
BGP routing table entry for 62.215.10.0/24, version 10
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
1
212.118.23.2 from 212.118.23.2 (212.118.23.2)
Origin incomplete, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
R8-CE#ping 3.3.3.3 source lo1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.10.8.8
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/63/72
ms
R8-CE#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 62.215.10.1:1024 10.10.8.8:52 3.3.3.3:52 3.3.3.3:1024
Another point to be pointed to is that the ASBR eBGP relation to the
INET is configured as an IPv4 BGP session under the new created VRF,
but checking this relation will be under the VPNv4 umbrella
