MPLS Layer 3 VPN Explained

Lessons Discussion
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