Networks For The Littlest. Micro issue №6. MPLS L3VPN and Internet Access

The article about L3VPN turned out to be big - as many as 130,000 characters.
Given that not everyone has read it yet, we have taken out this part about Internet access to a separate publication.
This is especially important, because in Runet, and indeed on the Internet, there is no available analysis of this topic.
It is likely that you are reading exclusive material now.

So, there is a carrier, which provides its client with L3VPN. All of a sudden, from the bay and the bakery, he also needed the Internet.
The most obvious solution is to run another cable in one VPN, in another Internet.
Suppose it is difficult. Then you can raise the subinterface and transfer the photos to the contact in a separate VLAN.
Suppose there is a complicated leased channel, where you can only proxy 1 VLAN or the client’s equipment does not know how to VLAN (it is a regular computer), what then?
')
About this next 36,000 letters of your life.

Issue content

• NAT to CE
• VRF Aware NAT
• Common Services

So, a provider in the same VPN sells access to the Internet, through the same connection, through the same addresses. This means that in the provider’s network it will be necessary to configure access from a private network to a public network, and therefore to ensure the intersection of route information.
All this indecency has its name - Route Leaking - routes flow from VRF to the global table. The name of the functional saying - to resort to Route Leaking, especially through static routes is necessary only in extreme cases, for an eerie crutch.

There are two approaches to the implementation of this functionality:

1. Configure static routes from VRF to public network and vice versa.
2. Juggling Route Targets

Both have the right to life.

Let's start with the statics.

Matter of course, we need NAT to hide private networks.
Scenarios differ only in the place of use:

• In the client's network - CE NAT.
• In the provider's network at the extreme PE - PE NAT.
• In the provider's network at the point of Internet access - VRF Aware NAT.

NAT to CE

The provider issues to the client a pool of public addresses to which it broadcasts its internal ones. All that remains to be done by the provider is to configure the routing between the VRF and the global table.
Given that the broadcast will be on CE, you need to select only one branch, let it be TARS_2 - there we have a public link network - 100.0.1.0/30.



As you can see, for this test we need something in the quality of the Internet and a computer that needs access to it.
In GNS, there is such a wonderful object as VPCS, which is perfect for this role.
On TARS_2, you need to configure NAT, below is its configuration:
TARS_2(config)#interface Loopback0
TARS_2(config-if)#ip address 172.16.255.2 255.255.255.255

TARS_2(config)#interface FastEthernet0/0
TARS_2(config-if)#description To Linkmeup
TARS_2(config-if)#ip address 100.0.1.2 255.255.255.252
TARS_2(config-if)#ip nat outside

TARS_2(config)#interface FastEthernet0/1
TARS_2(config-if)#description To LAN
TARS_2(config-if)#ip address 172.16.1.1 255.255.255.0
TARS_2(config-if)#ip nat inside

TARS_2(config)#router bgp 64502
TARS_2(config-router)#network 172.16.1.0 mask 255.255.255.0
TARS_2(config-router)#network 172.16.255.2 mask 255.255.255.255
TARS_2(config-router)#neighbor 100.0.1.1 remote-as 64500

TARS_2(config)#ip nat inside source list 100 interface FastEthernet0/0 overload

TARS_2(config)#access-list 100 deny ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
TARS_2(config)#access-list 100 permit ip 172.16.0.0 0.0.255.255 any

The access-list 100 consists of two lines - the first one prohibits the translation of addresses for packets that go from their network to their own network located on the other end of the provider.
The second line allows broadcasting only for the addresses of your network. If suddenly you register permit ip any any, then the BGP session with Linkmeup_R3 will immediately drop.
Details on how to configure NAT were covered in the fifth part of the SDSM .

Internet configuration:
Internet(config)#interface Loopback0
Internet(config-if)#ip address 101.0.0.101 255.255.255.255

Internet(config)#interface FastEthernet0/0
Internet(config-if)#description To linkmeup
Internet(config-if)#ip address 101.0.0.1 255.255.255.252

Internet(config)#router bgp 64501
Internet(config-router)#network 101.0.0.0 mask 255.255.240.0
Internet(config-router)#neighbor 101.0.0.2 remote-as 64500

Internet(config)#ip route 101.0.0.0 255.255.240.0 Null0

The BGP settings on the Internet are exactly the same as they were in Balagan-Telecom in the eighth edition , we only allowed ourselves some liberties with IP addresses.
The Loopback 0 interface on the site with the name Internet represents the entire Internet. Ping before him and we will check.
Linkmeup_R1 is also configured to communicate with the Internet :
Internet(config)#interface FastEthernet1/1
Internet(config-if)#description To Balagan-Telecom
Internet(config-if)#ip address 101.0.0.2 255.255.255.252

Internet(config)#router bgp 64500
Internet(config-router)#network 100.0.0.0 mask 255.255.254.0
Internet(config-router)#network 101.0.0.0 mask 255.255.255.252
Internet(config-router)#neighbor 101.0.0.1 remote-as 64501

Internet(config)#ip route 100.0.0.0 255.255.254.0 Null0

As for Internet access from a VPN, in this case, the configuration needs to be changed only at the closest to CE PE - in our case Linkmeup_R3 .

1. Create a default route for VRF TARS. This is so that packages that come from TARS_2 are not dropped and know where to go.

Linkmeup_R3(config)#ip route vrf TARS 0.0.0.0 0.0.0.0 101.0.0.2 global

Pay attention here to two things:
The global keyword . It suggests that Next Hop (101.0.0.2) should be searched for in the global routing table.
Linkmeup_R1 is selected as the Next-Hop address in the direction of the Internet. Why not Loopback as we love? This avoids the so-called blackholing'a. The fact is that the loopback is always available, and in the event of a channel falling between our gateway ( Linkmeup_R1 ) and the Internet, TARS_2 will not notice this and will continue to send traffic to Linkmeup_R3 , and the latter, also suspecting nothing, to Linkmeup_R1 . If we specify a link address, it will disappear from the routing tables as soon as the line falls.

As a result of the previous operation, the default route appears on Linkmeup_3:


2. Now it needs to be communicated to the client so that he also has a default route (although he could have configured it himself).

address-family ipv4 vrf TARS
neighbor 100.0.1.2 default-originate

Result:


So, the routes to there , that is, to the Internet, we already have, now with regard to back .

3. On Linkmeup_R3, configure a static route for the network 100.0.1.0/30:
ip route 100.0.1.0 255.255.255.252 FastEthernet1/0

Why do we need it? That was the route, it is logical after all. If from the Internet the packet arrives on Linkmeup_R3 , and there is no route to 100.0.1.0/30 in the global routing table ( in the VRF, it will, of course ), the packet will be dropped.
It was:

There is a route, but only not there. The packet will not be dropped, but it will not reach the addressee either.

It became:


4. Next, you need to inform BGP neighbors about this network - everyone should know about it. In particular, we are interested in Linkmeup_R1 .
router bgp 64500
network 100.0.1.0 mask 255.255.255.252

Result:

BGP, in principle, knew about this network before, but only in the address-family ipv4 vrf TARS, where it reached via the redistribute connected command. In the global routing table it was not.

So, everything is ready, we check:


This suggests that Route Leaking has earned, that is, access from the VRF to the global routing table and vice versa works.

Checking the availability of the Internet from a computer is a formality that will show that we have configured NAT correctly. In fact, all the magic happens on Linkmeup_R3 , and the familiar broadcast on TARS_2 , that is, the things are largely unrelated, and if the Internet is available from TARS_2 , it will be available from PC1 .
However, we will check:


Internet is available. Hooray!



Repeat the configuration steps:

• Configure NAT. On CE .
• Set a default route in the direction of the Internet for the VRF with the indication Next Hop and the keyword Global. On PE .
• Make PE announce this default route to the client. On PE .
• Configure the route in the global TM in the direction of the client with the indication of the output interface. On PE .
• Report this route to MBGP neighbors, or rather to that node, which looks to the Internet. On CE .

Complete configuration of nodes interesting to us.

---

The configuration described is Route Leaking .

---

Here we omit the script with NAT at the extreme PE, because it is not interesting.

VRF-Aware NAT

A more correct and slightly more scalable option - setting up the broadcast on Egress PE - on the Internet connection. In this case, we have a central node where all operations are performed, and the client does not need to do anything.


The only inconvenience: despite the fact that perhaps no client is connected to Egress PE directly, this router will have to support all the VRFs from which you need to access the Internet. Actually, therefore, he and VRF-Aware.

In our case, Egress PE is Linkmeup_R1 , which is a gateway to the Internet for the entire network linkmeup — no absolutely additional settings on other nodes.
Let PC2 from the C3PO Electronic network ( C3PO_2 ) want to access the Internet.
We don’t touch PC1 from TARS 'Robotics and leave it unchanged - they have a separate story with their white addresses, although they can also be natit in the same way.

1) So, firstly on Linkmeup_R1 there should be a VRF C3PO. He is already there, but if it were not, it would be necessary for it to be.
VRF configuration is typical and it has not changed:
Linkmeup_R1(config)#ip vrf C3PO
Linkmeup_R1(config-vrf)#rd 64500:100
Linkmeup_R1(config-vrf)#route-target export 64500:100
Linkmeup_R1(config-vrf)#route-target import 64500:100

2) Configure NAT
We turn on ip nat inside in the direction from which we receive packets for broadcasting, that is, in the direction of the P-router Linkmeup_R2 :
Linkmeup_R1(config)#interface FastEthernet 0/1
Linkmeup_R1(config-if)#ip nat inside

In the direction of the Internet, turn on ip nat outside :
Linkmeup_R1(config)#interface FastEthernet 1/1
Linkmeup_R1(config-if)#ip nat outside

Create an ACL where we allow access from the C3PO network to the Internet:
Linkmeup_R1(config)#access-list 100 permit ip 192.168.0.0 0.0.255.255 any

And actually NAT itself:
Linkmeup_R1(config)#$ip nat inside source list 100 interface FastEthernet 1/1 overload


3) In BGP, as well as last time, we prescribe the default route to be sent to this VRF:
Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router)#address-family ipv4 vrf C3PO
Linkmeup_R1(config-router-af)#redistribute static
Linkmeup_R1(config-router-af)#default-information originate


Be careful with redistribution in production. Use only with filtering.

Note that the redistribute static command alone is not enough to pick up and announce the default route. To do this, you will additionally have to execute the default-information originate command explicitly.
In order for this route to be announced by BGP, it is necessary that it be in the routing table:
Linkmeup_R1(config)#ip route vrf C3PO 0.0.0.0 0.0.0.0 101.0.0.1 global

Now it will not work right away, because I was slightly deceiving, saying that no settings anywhere except the Internet gateway will be needed.
The fact is that we generated the default route for VRF C3PO on Linkmeup_R1 and transmitted it via Linkmeup_R3 via BGP, but then it got stuck before reaching C3PO_2 - you need to force OSPF to announce the default route. Like the previous time without the explicit default-information originate command, it will not do this:
Linkmeup_R3(config)#router ospf 2 vrf C3PO
Linkmeup_R3(config-router)# default-information originate

Checking:

It would be strange if it did not work.



Complete node configuration for VRF Aware NAT.

---

It was the same Route Leaking.

---

Common Services

So far, we have been discussing the problem of transferring traffic from VPN to public networks and back.
Another approach to providing Internet access is to bring it into a separate VRF.
Strictly speaking, it is the most scalable, because there is no need to customize something individually for each client VRF.
An important condition is that NAT occurs on the client’s network and only routes to the public client prefixes are imported into VRF Internet.

Common Services, often referred to as Shared Services, is a continuation of the question of the interaction between VRFs, which we discussed earlier . The basic idea is that the export / import is accomplished by the special setting of the route-target. Only this time it is necessary to limit the list of transmitted prefixes in order to avoid intersection of address spaces and allow only public routes.

Consider the task again on the example of TARS, because they already have public networks.

At the gateway, we create VRF Internet.
Linkmeup_R1(config)#ip vrf Internet
Linkmeup_R1(config-vrf)#rd 64500:1
Linkmeup_R1(config-vrf)#route-target import 64500:11
Linkmeup_R1(config-vrf)#route-target export 64500:22

Please note that the route target for import and export is different this time and now it will be clear why.
2) Transfer the interface towards the Internet to the VRF:
Linkmeup_R1(config)#interface FastEthernet 1/1
Linkmeup_R1(config-if)#ip vrf forwarding Internet
Linkmeup_R1(config-if)#ip address 101.0.0.2 255.255.255.252

3) Move the BGP neighborhood with a router on the Internet to the address-family ipv4 vrf Internet :
Linkmeup_R1(config-router)#router bgp 64500
Linkmeup_R1(config-router)#no neighbor 101.0.0.1 remote-as 64501
Linkmeup_R1(config-router)#address-family ipv4 vrf Internet
Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 remote-as 64501
Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 activate

4) Declare the default route:
Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router-af)#network 0.0.0.0 mask 00.0.0.0
Linkmeup_R1(config-router-af)#default-information originate

Linkmeup_R1(config)#ip route vrf Internet 0.0.0.0 0.0.0.0 101.0.0.1

5) In the client VRF TARS, you also need to configure RT:
Linkmeup_R1(config-vrf)#ip vrf TARS
Linkmeup_R(config-vrf)# route-target both 64500:200
Linkmeup_R1(config-vrf)# route-target export 64500:11
Linkmeup_R1(config-vrf)# route-target import 64500:22

So, in addition to its own RT, which provides the exchange of routing information with other branches (64500: 200), those RT are configured here, which are also for VRF Internet, but vice versa:

• what was exported to VRF Internet (64500: 22) then became import to VRF TARS
• what was on import to VRF Internet (64500: 11) then became export to VRF TARS

Why is that? Why not just give route-target both 64500: 1, for example, on all VRFs?
The basic idea of ​​the Common Service concept is to provide access to the right VRF clients, but not allow them to communicate with each other directly to provide isolation, as required by the definition of a VPN.
If you configure the same RT on all VRFs, then the routes will calmly walk between them.
With the above configuration, all client VRFs have RT 64500: 22 for import (everyone will get Internet routes), and also they have RT 64500: 11 for export, but only VRF Internet has this RT 64500: 11 for import - Only VRF Internet will receive customer routes. They cannot exchange with each other. The main thing is that the Internet does not engage in philanthropy and does not begin to route client traffic.


So, as a result of our operations, we can see the following:

On TARS_2 everything is in order.

Linkmeup_R1 has a route to the network 100.0.0.0/30, but there are also extra routes to private networks:


And in this case we will even have an intimate connection:


But what about these extra routes in the VRF Internet? After all, if we connect another VRF in the same way, we will get unnecessary gray subnets from it.

Here, as usual, filtering will help. And if specifically, we will use the prefix-list + route-map:
Linkmeup_R1(config)#ip prefix-list 1 deny 172.16.0.0/12 le 32
Linkmeup_R1(config)#ip prefix-list 1 deny 192.168.0.0/16 le 32
Linkmeup_R1(config)#ip prefix-list 1 deny 10.0.0.0/8 le 32
Linkmeup_R1(config)#ip prefix-list 1 permit 0.0.0.0/0 le 32

The first three lines prohibit announcements of all private networks. The fourth allows all the rest.
In our case, it would be quite possible to do with one line: ip prefix-list 1 permit 100.0.0.0/23 le 32 - the entire Linkmeup subnet, but the example we cited is more universal - it allows for the existence of other public networks and, accordingly, one prefix-list can be applied to all vrf.
The following construct applies the extended community to those prefixes that are in prefix-list 1, in other words, sets RT:
Linkmeup_R1(config-map)#route-map To_Internet permit 10
Linkmeup_R1(config-map)#match ip address prefix-list 1
Linkmeup_R1(config-map)#set extcommunity rt 64500:11

The only thing left is to apply the route-map to the VRF:
Linkmeup_R1(config)#ip vrf TARS
Linkmeup_R1(config-vrf)#export map To_Internet

After updating the BGP routes (you can force the command clear ip bgp all 64500 ), we see that only the public route remained in the VRF Internet:


And, in fact, checking the availability of the Internet with PC1 (NAT is already configured for TARS_2 ):

---

Dear readers, you have just become familiar with another approach to Route Leaking .

---

Complete configuration of all nodes for Common Services.

The most accessible topic Common Services is described by Jeremy Stretch . But it has no indication that prefixes need to be filtered.
In general, they have there in theirs America, everyone knows and respect each other. Therefore, Jeremy readily refers to Ivan Pepelnyak, or rather his note on Common Services , and Ivan, in turn, to Jeremy. Their articles complement each other, but again the topic is not fully disclosed.
And here is the third link , which, coupled with the first two, allows you to add up some idea of ​​how Common Services works.

All types of Internet access from VRF are described in this article . But it is so confusing that this is why I decided to devote a separate micro-issue to the SDSM to the question of setting up this functionality.

---

In general, about MPLS and its applications, including L3VPN, can be deeply read in Ina Minei, Julian Lucek. MPLS-Enabled Applications .
From the list of the best books for the signalman .

---

This year, wait for SDSM12. MPLS L2VPN.