MPLS Layer 3 VPN Explained

Lessons Discussion
189

Hello Guys,

Do we need to have firewalls before or after the edge routers as VPN here does not have any encryption or any other sort of security?

190

Hello Abdalla

The purpose of MPLS Layer 3 VPNs is to connect multiple remote sites of a single customer over the MPLS network in a way that will allow multiple customers to do so, without problems with overlapping IP addressing schemes. If you want to add features such as encryption, and other security mechanisms, you can apply these at each customer site. This is not part of the MPLS implementation, but it is what each customer deploys on each end. So you can install firewalls at each site, and employ encryption before you route your traffic over the MPLS network. MPLS will simply take this encrypted traffic as the payload and deliver it to the appropriate destination, where it can be decrypted and transmitted normally.

In addition, there are other ways in which MPLS can be secured, including the encapsulation of MPLS in GRE tunnels, which can then be secured using IPSec. Details about such an implementation can be found here:

I hope this has been helpful!

Laz

191

Thank you Laz,

You have been always helpful.

1 Like
192

Hello RENE/LAZ,

Please share the sample configuration against above lesson wrt Nokia and Juniper devices.

Thanks,
Ajay M

193

Hello Ajay

Take a look at this post:

Laz

194

I would like to have RD and RT explained to me without using any network terms minus those names. For example use food or animals or something very simple that everyone understands including people who do not understand what networking is.

Thats a trick I use to help others when its confusing I love analogies and stories.

Here is what I think RD and RT is using my trick listed above:

If you had two dogs who were identical twins and you need to differentiate between them in addition if you needed the dogs to make their way across a park with multiple exits what would you need to do?

  1. you could put a collar on each dog with his name (this is your Route Distinguisher)
  2. you needed the specific dog to exit at the specific place in the park you have someone call his name at one of the entrances. (this is your Route Target).

then from that explanation I can even state it simpler:

  1. RD = specific identifier of a route just as name implies.
  2. RT = tells it what path to take “target deals with location where you need to go"

now if that is correct, if not please give me a better animal/food/car/human some sort of analogy that does not use networking explains and all people know, then we can go back and start adding in the more technical stuff.
For Example, someone posted on forums that with MPLS all the attributes that normally are used with BGP for path choice are not there so we in order to find our path and where we are going we have to add a RT etc…

One thing I dont know is if the RT is also part of what goes with the Dog along with his collar (RD). If it does then might say add a electric shocker(RT) to the dogs collar(RD) that shocks him if he starts down the wrong path. This would mean all the information is included with the item that needed to travel to the correct spot; the dog in this case. It would also be different for each identical dog and identify them as well as have them travel where they needed.

Anyway let me know if what I have stated here is correct and if not use the rule to explain without network terms.

Jumping back over to network terminology I wonder if we can see all that in a wireshark capture the RD and RT and if its all the same packet or some sort of encapsulation like a frame is inside of a packet etc… first you have the RD in there maybe then that is inside the RT? but thats only if my above premise was correct I guess.

----------------EDITED--------------
On next lesson I see the RT within the BGP Protocol update message specifically the Path Attribute - extended communities Then carried extended communities!

I also see the RD under Path Attributes MP_reach_NLRI then Label stack 19 which relates I think to I read about something label 19 in the lesson I will have to review.

so that really brings it home from a technical view and I got a big kick out of seeing this in the message update which is so important in BGP states where you have OpenSent awaiting Open Message which will then be checked for errors and if no errors will move on to OpenConfirm where keep alives will be sent then Established. So that wireshark on the next lesson really helped me see the information and also was like a oh wow moment this is cool!

should be a message at end of this lesson that says read through next lesson and most of your questions will be answered lol…

195

Hello Brian

To be honest, I’m not that good with detailed analogies like the one you shared, but for the most part, it sounds reasonable. In its simplest terms, I guess I can say that an RD is used to keep all prefixes in the BGP table unique, while the RT is used to transfer routes between VRFs/VPNs.

Good to hear that most of the rest of your queries were resolved with the next lesson. Thanks for sharing, that’s what helps enrich the content in the forum!

Laz

198

that was my question as well what is the difference. thanks for clarifying. I learn this then forget it then learn it again. I just dont do much with MPLS anymore.

I dont think MPLS VPN L3 VPN is as popular or used as widely as the MPLS L2.

When I worked at some different ISP companies (briefly I dont really enjoy ISP type networks or working for them). It seemed like most times they would sell customers layer 2 circuit so for the customer it was like making offices directly connected via layer 2.

so anytime you call the ISP for an issue they tell you that they only supply layer 2 connectivity and not much they can test.

However, that’s not quite true because they can start following the labels and make sure labels and make sure no issues there as well as many other things.

In real world you have to have basic understanding of this at the very least so ISP does not give you the run around and give you snappy answer that they just provide layer 2 only etc…

With knowledge you have power!

here is an ISP basic troulbe shooting you can also use this to make sure they check everything if you have a problem that does not go away. This would include the light and sending tech out to polish if needed probably a charge but if your business is suffering its sometimes worth it.

If your company getting run around and your having issues with your circuit and your stuck here are some ideas to throw at the ISP:

The point of this document is to provide ISP technicians with steps on how to begin troubleshooting all service affecting issue. This is by no means comprehensive, but things that the management and leads will want to see in a ticket from all technicians. All commands in this document are Juniper formatted. Both IP and Ethernet services will be covered.
No matter what the issue is, the following should be put into all tickets at the beginning of the troubleshooting process.

  1. Show interface
  2. Show interface extensive
  3. Show interface diagnostic optics
  4. Show configuration | display set | match x/x/x
    Now no matter what the issue, if there is an Accedian on the customer’s service, check the firmware version. If it is not update to date, update the firmware and have the customer retest.
    Also, look at the XLR for the customer’s service. If there is a transport path, ask the ONCC to investigate. If there is a type II provider, open a ticket with them. The earlier you do this in your troubleshooting process, the less time you will have to wait for them once you have completed all your troubleshooting.
    Latency & Packet Loss
    Always ask for ping and traceroute (IP services only) testing from the customer if they did not provide it at the opening of the ticket. Many times the customer misreads or misunderstands what they are seeing in their testing, and we need their testing to confirm.
    If you don’t see errors on the interfaces, then the next thing to do will be to examine the network. We will do this with ping and traceroute testing.
    For Ethernet services, start with ping and traceroute test between the loopback addresses of the PE routers.
    For IP services, we want to ping between the source and destination addresses. Most of the time you will not be able to test the entire path due to traffic be handed off on a peering connection. What you will need to do is get to the ingress and egress point of the ISP network and test towards the source and destination. You will also want to run a traceroute to show that the path is the same as the customer is taking.
    If you determine that the latency is high, then run a traceroute monitor and attempt to determine where the increase is. This is also where you will need to check for any network saturation via utilization graphs.
    Degraded
    Ask for any speed tests or Iperf testing the customer has performed. Also ask the customer to perform Iperf UDP testing (Ethernet) or a speed test (IP) and to provide us with those results.
    Once again, if you are not seeing any errors start with some ping tests between the source and destination or PE devices.
    Check the ERO for errors, drops, and saturation. Also look at all NGN devices that are in the path as well. Use the following link for a how to on troubleshooting the ERO

For Ethernet services, if you don’t see any errors and there is no packet loss that we can find, this is where we would offer an RFC 2544 test.
For IP services, if you don’t find and errors, packet loss, or network saturation, then we will dispatch to perform Iperf and speed testing from the demarcation point. This will usually require an Accedian.
Hard Down and Flapping
Look to see if there is two way traffic, if there is then this could be an RFO and we need to speak with the customer to confirm. If you don’t see traffic, bounce the interface and hard code interfaces, i.e. turn off auto negotiation, set speed and duplex.
If you see the interface(s) up, then here a few things to look at
BGP session and received routes. Check for hidden routes as well.
L2 virtual circuit status and VPLS neighbors
Check the customer utilization, especially on IP services as DDoS attacks can affect multiple customers
Extras
Here are just a few things that should be looked during the course of troubleshooting as well.
ERO path – Checking for drops, errors, and flapping across all devices that a customer’s traffic traverses. This will include all NGN devices.
FPC errors – Check logs for ICHIP and MQCHIP errors on the ERO path.
BGP max prefix limit violation – Do to the max prefix limit and customer’s being set at an 85 percent tear down, customer routes can be dropped or hidden.
BGP damping – If a customer’s BGP session flaps, when the session establishes again, the route will be damped for an hour.

1 Like
199

do you have MPLS L2VPN like VPLS as well?

200

Hello Zahid

I’m not sure what you’re asking. Can you clarify? In the meantime, here is some information about MPLS L2VPN Pseudowire.

Please clarify and we’ll answer your question as best we can!

Laz

201

Can you please clarify the behavior of the route-reflector if it receives a prefix(Ex:10.10.10.0/24) from two PE (PE1 and PE2) for two different customers with the same RD (Ex:- 100:1000). Whether only one route will be advertised to the rest of the PE routers?

202

Hello Arun

The Route Distinguisher is what is used to ensure that the prefixes learned from each customer are unique, even if the prefix itself is the same. Each customer will necessarily have a different RD for their prefixes. Therefore, a route reflector will never receive the same prefix with the same RD from two different customers. That is the purpose of the RD.

I hope this has been helpful!

Laz

203

Hello Guys,

Quick question regarding the RD.
When configuring MPLS VPN, we have to assign a unique a RD (ASN:VPN Identifier) per VRF on the PE router.
So if we have two customers, Customer A and B, Sites 1 and 2, we assign a unique RD for each customer’s VRF, for instance:
Cust_A_VRF_Site_1 RD 1:100 and
Cust_B_VRF_Site_1 RD 1:200

My question comes for Site 2…

  • do we have to use the same RD at the other PE router connecting Customer A/B Site 2??? I don’t remember whether the VPN identifier needs to match for both sites or not.
  • if no, how does the PE router know where to send the traffic?
CE_A_site1--+               MP-iBGP               +-- CE_A_site2
            |----PE-1-----[MPLS core]-----PE-2----|
CE_B_site1--+                                     +-- CE_B_site2
                RDs: A = 1:100                RDs: 1:100
                     B = 1:200                    1:200

Regards,

204

Hello Luis

RDs must be unique for different VRFs on the same PE, but for two corresponding VRFs on two different PEs, they may or may not be the same. In smaller deployments, you may find that administrators will configure them to be the same for simplicity, but in larger and more complex deployments, you’ll find that they are different.

The RD is an attribute that is added to the MP-BGP update message for a particular route and is there to distinguish between customers. It is added in the advertisement of outgoing updates, and it only plays a role when outgoing.

So when PE1 sends a prefix of, say, 10.10.10.0/24 to PE2, from customer A, it will send 1:100 10.10.10.0/24. When it sends the same prefix from customer B, it will send 1:200 10.10.10.0/24. When PE2 receives those updates, it knows they’re different. If they were the same, the BGP router would simply replace one with the other.

You can have the RD be different in the other direction. Use 1:300 instead for example. When PE2 advertises routes to PE1, it will use an RD of 1:300, which is fine, since it is only used to ensure that the routes appear unique to BGP.

Remember, it is the RT that is used to allow a PE router to know to which VRF each prefix belongs. A very helpful explanation can also be found at the following Cisco community thread:

I hope this has been helpful!

Laz

1 Like
205

Cannot thank you enough for this amazing explanation

1 Like
206

Hi,

one question regarding import/export of routes. In the article you are saying that “PE2 is configured to export all VPNv4 routes that use RT 123:1 into VRF CustA”. Here you are saying ‘export’ and on the second illustration in the Section 2.2 there’s an ‘import’ tag under the arrow so I am little confused how this actually works.

Does this mean that the import/export sequence actually looks like this:

PE1: Imports routes from Customer A site 1 with the ‘export’ tag into the shared VRF and advertise them to PE2.
PE2: Exports received routes from the shared VRF with the ‘import’ tag into the routing table of Customer A site 2

Is my understanding correct?

207

Hello Ivan

Take a look at this post:

If you have any further questions, feel free to let us know!!

I hope this has been helpful!

Laz

208

Hi , i have a question , RD is to locally distinguish the same routes from two different customers on local PE router , then why we need to send the RD in VPNV4 NLRI to the far END PE router as far END PE router will check the RT value and install the route in the related VRF where this RT is imported. In simple way why the far end PE routers need the RD value.

209

Hello Masaud

Take a look at this post:

I hope this has been helpful!

Laz

210

which one will be checked and popped first RT or VPN Label ?
please explain this.