Hello Luis
Yes I understand the confusion. I will ask Rene to clarify this in the diagrams within the lesson.
I hope this has been helpful!
Laz
Hello Luis
Yes I understand the confusion. I will ask Rene to clarify this in the diagrams within the lesson.
I hope this has been helpful!
Laz
In below topic of mpls a small typing mistake :
https://networklessons.com/mpls/mpls-layer-3-vpn-explained
In below diagram u put import instead of export:
Also in below screen shot i think u mean NLRI instead of NRL:
Hello Ziad
Concerning the first issue, the terms are correct. Take a look at this post:
As for the second typo, yes I will let Rene know to make the change.
Thanks for pointing that out!!
Laz
thnx for the great update, now i got the point:v:
Hello @lagapides @ReneMolenaar.
Hello Tejas
The RD for a certain VRF does not need to be the same across all of the MPLS domain. The RT will be used to import and export prefixes between VRFs on different PEs.
I believe that this Cisco community thread quite clearly explains it:
Specifically, it states:
MP-BGP exchanges the VPNv4 (RD:IPv4) prefixes between the PEs (P routers are not VPNv4 aware) not IPv4 routes - When a PE receives a VPNv4 route it discards the RD attached to it and attaches its local RD (according to the VRF that the route is going to be injected into according to the attached RT and the local VRFs import RT) - Since for the local router routing table database the VRF is identified via the RD prepended to the IPv4 route to construct the VPNv4 routes.
I hope this has been helpful!
Laz
This is not a question, but a comment. I wanted to say this before I get tied up on other things and forget. This site is such a great wealth of knowledge. I find myself coming back here more and more for my Technical questions and needs. Your way of Teaching is so concise, clear, straight forward, and easy to understand and to grasp imo.
I have CBT Nuggets experience, IPTV pro, INE, Udemy, Global Knowledge, and few others in the past and present. But this site for me is my favorite. Keep up the great work Rene and others. I am learning at an accelerated rate and understanding what it is I am applying. This site is a big part of that. Thanks for being responsive as well! Thanks for the great content guys.
Hello Desmond
It’s posts like this that make it all worth it. Thanks so much for your kind words, @ReneMolenaar does his best to ensure the content is useful, relevant, and easy to understand, and we do our best to respond as quickly and comprehensively as possible. We do it because we like what we do.
We’ll do our utmost to maintain this QoS if you will () of the service.
We’re happy that the site is a helpful tool in your certification journey, as well as in the development of your skills and knowledge…
Keep learning!!
Laz
Thank you @THEBILLIONARECLUB for your kind words. I appreciate this. This helps to keep going to create more content
IF we have tunnel running between two PE routers, then why do we need iBGP, what is the purpose.
Hello Hemalatha
MPLS VPN is a technology that uses a combination of various features such as LDP, VRFs, and BGP. In the MP-BGP (Multi Protocol BGP) section of the following lesson, Rene goes on to explain that iBGP is used between PE routers in order for them to redistrubute and advertise each customer’s VRF routing table between PE routers. Specifically, MP-BGP is used to do so.
I hope this has been helpful!
Laz
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?
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
Thank you Laz,
You have been always helpful.
Hello RENE/LAZ,
Please share the sample configuration against above lesson wrt Nokia and Juniper devices.
Thanks,
Ajay M
Hello Ajay
Take a look at this post:
Laz
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?
then from that explanation I can even state it simpler:
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…
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
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.
- Show interface
- Show interface extensive
- Show interface diagnostic optics
- 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 EROFor 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.
do you have MPLS L2VPN like VPLS as well?