Welcome to the Network Engineering Domain
Pape O. Fall's Blog
In this topic, we will talk about MPLS L3 VPN Central Services. At this point, if you are unfamiliar with MPLS then please read the first portion of this post here explaining in details how MPLS works.
MPLS Central Services is also referred to as MPLS Common Services and its goal is mainly to allow distinct customer sites to access a common set of servers or services. In other words, let’s say a SP is offering a Web Security solution where a customer traffic is inspected up to Layer 7 and match against local profiles and databases in order to allow or block http/https/ftp requests. Some customers may not want to run such solution in-house and would rather have the SP handle that side of the house. The SP is not going to obviously spin up dedicated hardware for each customer but rather segregate that traffic using VRF, inspect it and either discard it or send it upstream if allowed. All customers would be able to use the central service but communication between customer to customer will not be allowed. In grosso modo, that’s what MPLS Central Services resolve.
We will be using the following topology to demonstrate how to deploy such solution…
In essence here, both JiffyLube and McDonald need to access the internet which is in this case offered by RouteLeak (SP). Here, both JiffyLube and McDonald rely on the Service Provider VPN backbone to access the Internet. Per the diagram, we will be using separate VRF per client site as well as distinct RD on each client site. On the server side, we will use single VRF for each service type… But since we have only one service type in this example, we will just tie it with one RD.
Let’s now hop on the consoles and configure the entire solution end to end. We will start with the configuration of the backbone. Let’s enable CEF, use LDP as MPLS label protocol and force ldp router-id to be loopback0 on R1, R2 and R3…
All right ! The above has been configured on R1, R2 and R3 (R2 and R3 screenshots purposely omitted). Let’s now get OSPF up and running and enable LDP on the appropriate interfaces…
Here, we have OSPF configured on R1 and the command “mpls ldp autoconfig” enables LDP on all interfaces running MPLS. Let’s do the same on R2…
Good ! Let’s make a road trip to R3…
Let’s make sure that labels are generated per loopback and not physical interfaces…
The above has been configured on R1, R2 and R3 (R2 and R3 screenshots purposely omitted).
Great ! Our next step is now to configure our VRF parameters per the diagram on R1, R2 and R3. The following commands will need to be configured on both R1 and R3.
All right ! The above has been configured on both R1 and R3 (R3 screenshot purposely omitted). Let’s configure the VRF parameters for R2…
Good ! Let’s now configure our interfaces which connect to the customers in their respective VRF…
Good ! R1 is done, let’s hop on R2…
All right, R3 is next…
Awesome ! Since R2 is in the transit path to access the Internet, it will need to establish MP-iBGP sessions with both R1 and R3 as well. Let’s configure MP-BGP in the Backbone…
Good, let’s do the same on R2…
R3 is next…
Good ! Let’s now configure RIPv2 to connect to McDonald CE routers and redistribute the routes in BGP (vice versa). While we are at it, we will setup the PE-CE session between the PE routers and JiffyLube CE routers using BGP as well. Let’s do that on R1…
Good ! Let’s hop on R3…
All right ! At this point, we can hop on the CE routers and configure our routing protocols. Let’s start with JiffyLube’s routers…
All right, let’s hop on the remote office router…
Good ! Let’s make a road trip to McDonald’s CE routers now…
Voila ! Let’s head to the remote side…
This is done ! So now, the idea is that both JiffyLube and McDonald should receive a default route pointing to the internet via the VPN backbone. One way of doing that is to import the customer routes on R2 in order to achieve reachability both ways and then import VRF Internet routes at the customer sides so they can receive the default routes. We will then inject a default route via BGP under VRF Internet. Let me show you how…
On R1 and R3, here is what we are doing…
300:1 is VRF Internet RT, so here we are basically importing VRF routes into both VRF JiffyLube and VRF McDonald routing tables. The above configuration is for both R1 and R3 (R3 screenshot is purposely omitted). Let’s make a road trip to R2 now…
In order to achieve 2 way reachability, here we are importing the customers RTs.
Good ! Let’s now inject a default route into VRF Internet…
Here, under the address family VRF Internet, we’ve advertised a zero route to our peers and we also have a static route pointing to the Internet gateway per the diagram. Since, we are using the network command under BGP, we have to have a component route in our routing table in order to successfully advertise it across which is the static route in our case…
Let’s now hop on the Internet gateway router and configure a static route pointing traffic destined to 10.0.0.0/8 back to R2 for return traffic so we can make sure 8.8.8.8 is pingable from the customer side…
Let’s run some troubleshooting commands and make sure our configurations are accurate…
Our MP-BGP sessions are in fact up and running and we are receiving prefixes on R1. Let’s look at the routing table and also make sure we are receiving a zero route…
This is good ! We can clearly see here that JiffyLube routing table is distinct from McDonald’s and we are receiving a zero route with the greater than sign proving that the route has been successfully installed in the routing table. Let’s see if we can get to the Internet…
Good ! We can and we can also see the labels generated. Let’s hop onto the CE routers…
Awesome, here we can clearly see that we can successfully get to the Internet and the remote side as well. We’ve successfully received and installed a default route locally and we are not seeing McDonald’s routes anywhere in the main routing table. Let’s do the same on McDonalds side…
Okay ! one thing I forgot to do is advertise McDonald’s loopback 30 and 40 into RIP. I was looking to ping from loopback tp loopback but didn’t see the routes in the routing table. Let’s do that first…
That’s better, let’s now hop on McDonald CE router at the HeadQuarter…
Let’s hop on R2 and check out the routing table for VRF Internet…
As you see here, both McDonald and JiffyLube routes are successfully imported into VRF Internet. However, McDonald’s routing table is unknown to JiffyLube’s and vice versa.
That completes this topic. Please leave a comment if you have any questions.
Hello I'm Pape. My friends call me Pop. I'm CCIE #48357. I enjoy my field and love to share it with others. I love to write so I'm sharing my blog with you.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | ||||||
Nice POST my friend, so I have one question about how we can better manage the import export route between Internet_Services and Customers, for exemple if we have 10000 customers who need to access on internet ? do you import on the vrf Internet Services 10000 rt or do you have another simple solution to achieve it 😉
Said,
That’s a good question. So, you have another solution where you can use a route-map and tie it with an export map under the VRF instance. But if I understand your question correctly, you are more concern about load on the PE router if you 1000+ customers. That’s one of the issues MP-BGP resolves… You only need to establish a MP-BGP session with the PE routers on each end so your VRFs need to exist on the respective PE routers.
That’s also why you typically deploy first carrier grade edge routers to support that kind of high density. Does that make sense ?
Sorry to speak french, so la solution que je préconisais était plutôt de ne pas avoir à importer les rt des 10000 clients de mon parc dans la vrf internet et le besoin d’en ajouter à chaque ajout d’un nouveau client and for that i think that your solution to use route-map/export-map is the best solution to achieve it.
I thought about the use of set extcommunity rt 400:101 additive in my route-map for every customers vrf and to just import once the rt 400:101 on vrf Internet ? Are you agree with this solution ?
Exactly Said. Once you define your route-map, you have to specify which route target you’d want to tie to the instance.
As you stated, the command is “set extcommunity rt xxx additive”.
But note that, depending on the topology and what you are looking to accomplish, you might need to use either an export-map or an import-map.
cool, thank you. Hope to read you again very soon.
Cool ! QoS is next. Stand by…