One of the applications that MPLS (Multi-Protocol Label Switching) provide is WAN connectivity for enterprises (generally speaking) that seeks secure communication among its entities and remote locations.
The demand for the customers expand beyond just only WAN connectivity to gain Internet access utilizing the same last mile , but is the service provider infrastructure capable of supporting such a setup? Sure it does and this is one of the main design aspect MPLS technology supports: flexibility.
Now as it is assured that MPLS supports Internet access over the provided service (MPLS L3VPN), let us examine the available options from a technical perspective and highlight some design concerns among the available options
Before starting the dive into the available options, we will categorize from high level the options into:
- MP-BGP
- non-MP-BGP
What is meant by that is that L3VPN service rely solely on establishing a VPNv4 session between the serving PEs
Where from we will get the Internet routes? Usually through our GW or what so called ASBR (Autonomous System Boundary Router).
How this device will be connected? This varies from a network to another and in our case we will add a P router to whom the ASBR will be connected (just to raise the complexity a little bit and fulfil the design goal for which this document is written).
Note: The design options are listed in the CCDE study guide, but some ideas and highlights are added
Design Option 1:
In the first option which is relying on non MP-BGP with default route pointing to a next-hop within the global routing table.
In the topology depicted above, we are serving two customers (one with only one location to serve because the main idea is to serve this customer with Internet access and not maintaining access to another branch or location).
As well and mentioned earlier, we have a P router that is acting as a RR for the VPNv4 AF and is connected to the ASBR which in turn is connected to the Internet Service Provider.
The PE-CE routing protocol is RIPv2 and OSPF is the IGP inside the network and for sure BGP IPv4 is the running protocol between the ASes.
What we will do is to give Internet access to customers who are part of different VRFs.
The Internet destination is represented by a loopback interface configured on INET router which are advertised to the ASBR via BGP IPv4 unicast.
Currently (in this design option), the customers are terminated via physical connection (no logical segmentation).
As the customers need Internet access (and currently they are using private IP addressing scheme for the WAN connectivity), some public IP addressing scheme should be implemented.
For the sake of this document, a public IP subnet is used for NATting the traffic and enable the customers to gain Internet connectivity.
But where the NAT process should take place? In the first scenario, the P router will handle the role of this translation.
Now the question arises, the P router do not have any VRF configuration implemented, should we define the VRF? Actually we will have to configure it as the NAT statements are attached to the VRFs of concern.
This example assumes every VRF is assigned a public IP address block (Class C) just to illustrate more clearly the translation process.
But how the routes will be imported to into the specific VRFs? In design option 1 we are relying on the global routing table to gain Internet access, so a static route is pointing to the next-hop router (ASBR) inside the respective VRF.
Now, as mentioned earlier, we have public IP subnet per VRF (in our demonstration example, we have two VRFs) and the NAT process will be configured on the P router, so how the subnets will be learned by the INET router? One of the options is to configure an IPv4 iBGP session between our P router (NAT translator) and the ASBR.
The question that arise, is that really the role of the P router? No, it should handle the role for switching labels but technically is viable solution and we will examine other scenarios for the same option.
The below figure shows the different BGP instances running to achieve the ultimate goal for our customers: Internet access.
As the P router is the main component in our scenario, we will list the relevant configurations:
P:
ip access-list standard ABC_TRAFFIC
permit 10.10.8.0 0.0.0.255
ip access-list standard MSSK_TRAFFIC
permit 10.10.6.0 0.0.0.255
permit 10.10.7.0 0.0.0.255
ip nat pool MSSK_POOL 62.215.1.0 62.215.1.254 prefix-length 24
ip nat pool ABC_POOL 62.215.2.0 62.215.2.254 prefix-length 24
ip nat inside source list ABC_TRAFFIC pool ABC_POOL vrf ABC
ip nat inside source list MSSK_TRAFFIC pool MSSK_POOL vrf MSSK
ip route 62.215.1.0 255.255.255.0 Null0
ip route 62.215.2.0 255.255.255.0 Null0
ip route vrf MSSK 0.0.0.0 0.0.0.0 192.168.12.2 global
ip route vrf ABC 0.0.0.0 0.0.0.0 192.168.12.2 global
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0
neighbor 4.4.4.4 remote-as 1
neighbor 4.4.4.4 update-source Loopback0
neighbor 5.5.5.5 remote-as 1
neighbor 5.5.5.5 update-source Loopback0
address-family ipv4
network 62.215.1.0 mask 255.255.255.0
network 62.215.2.0 mask 255.255.255.0
neighbor 2.2.2.2 activate
exit-address-family
address-family vpnv4
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-community both
neighbor 4.4.4.4 route-reflector-client
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community both
neighbor 5.5.5.5 route-reflector-client
exit-address-family
address-family ipv4 vrf ABC
network 0.0.0.0
exit-address-family
address-family ipv4 vrf MSSK
network 0.0.0.0
exit-address-family
Verification:
Trying to ping from our CEs to check the connectivity and the NAT translations on the P router
R6-CE#ping 3.3.3.3 source loopback 1
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 = 40/47/56 ms
R7-CE#ping 3.3.3.3 source loopback 1
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.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/59/68 ms
R8-CE#ping 3.3.3.3 source loopback 1
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 = 48/52/60 ms
R1-P#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 62.215.1.1:3 10.10.6.6:3 3.3.3.3:3 3.3.3.3:3
--- 62.215.1.1 10.10.6.6 --- ---
icmp 62.215.1.2:2 10.10.7.7:2 3.3.3.3:2 3.3.3.3:2
--- 62.215.1.2 10.10.7.7 --- ---
icmp 62.215.2.2:1 10.10.8.8:1 3.3.3.3:1 3.3.3.3:1
--- 62.215.2.2 10.10.8.8 --- ---
R1-P#sh ip nat translations vrf MSSK
Pro Inside global Inside local Outside local Outside global
icmp 62.215.1.1:4 10.10.6.6:3 3.3.3.3:4 3.3.3.3:4
--- 62.215.1.1 10.10.6.6 --- ---
icmp 62.215.1.2:3 10.10.7.7:2 3.3.3.3:3 3.3.3.3:3
--- 62.215.1.2 10.10.7.7 --- ---
The below figure illustrates the devices roles with respect to different aspects of the setup:
Note: Redistribution is meant for the PE to CE relationship.
A caveat has to be cleared which is the next-hop-self which has to be defined (or redistribution to take place):
ASBR:
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 212.118.23.3 remote-as 3
!
address-family ipv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 next-hop-self
neighbor 212.118.23.3 activate
exit-address-family