Formulating an Opening Moves Strategy for Troubleshooting and/or Configuring MPLS Layer 3 VPN’s

Hi Everyone,

I made this recent post to the NetMasterClass Blog and other discussion forums today. I want to share it with the CLN community as well. It is a follow up to a  free Live On-Line Group Mentoring session we held yesterday. If anyone in the CLN community is interested in attending a free mentoring session, please contact rauf@netmasterclass.net. We at NMC are committed to enhancing Cisco 360 CCIE learning content with lots of on-line mentoring services. Please feel free to sign up for a technical webinar at no charge!

Here is my positng about formulating an Opening Moves Strategy for MPLS Layer 3 VPNs:

I hope those that attended yesterday?s free MPLS webinar enjoyed it. I plan to have a follow up MPLS webinar on configuring MPLS sham-links next Tuesday, October 5^th at 12 noon GMT-5.

I have also had requests for Webinars for the following topics:

Multicasting ? Sparse Mode

Router QoS

Catalyst QoS

PPP Authentication and Encryption

EEM

All of these topics are very interesting topics and lots of fun to learn!!! Especially when we use our ?proof by IOS? and ?proof by debug? approach.

Please contact the NMC registrar Rauf Rasulov rauf@netmasterclass.net if you want to attend any on-line seminars on these topics.  We at NMC are very excited about our Live On-Line Group Mentoring service as a complement to offering Cisco 360 products and services. Delivering training and mentoring services on-line is so very powerful. We are more than willing to provide lots and lots of free live training samples for the CCIE community.

Yesterday, we discussed implementing a baseline MPLS Layer 3 VPN configuration.  We called this formulating a set of ?opening moves? for implementing a baseline MPLS Layer 3 VPN configuration. This is a very hot discussion right now among the NMC Live On-line Group Mentoring student community.  At the end of this e-mail  are some ?rough edit? notes from yesterday?s webinar. These notes are also a loose culmination of notes collected from the NMC CCIE Mentoring community.

Please feel free to add to them in any way you?d like. Also, please let comment on whether you think it is useful to have a set of ?opening moves? for configuring a specific technology or troubleshooting a specific technology.  There is an old quote from the famous ancient Chinese writer Sun Tzu and the his classic ?The Art of War? ? the general Sun Tzu quote is ?Wars are won or lost before they are fought?. Among many other things, Sun Tzu is making a reference to how well prepared a given army is to fight a specific war. We like to extrapolate from this Sun Tzu quote the following CCIE lab preparation principle, ?CCIE labs are passed or failed before they are attempted?, or perhaps more specifically, ?OSPF points are gained or lost before they are attempted?, or ?MPLS points are gained or lost before they are attempted?, etc.  The point I am trying to make is: One needs to develop a structure to approach a CCIE level problem; developing a set of ?opening moves? can be a useful starting point for formulating such a structure.

Again, here are some notes for forming a set of opening moves for either troubleshooting or configuring a baseline MPLS Layer3 VPN implementation. Actually, the following checklist is more oriented towards troubleshooting a baseline MPLS Layer3 VPN implementation. Please note these notes are ?roughly edited?. I hope they can act as a starting point for any of you that are beginning to learn about MPLS.

Once again, please let me know if you want to attend a free Webinar or any of the topics listed above. Or let me know if there are any other topics you?d like to cover in an on-line webinar.

Thanks!

All the best,

-Bruce

Andrew Bruce Caslow, CCIE #3139

+1 703 606 7353

NetMasterClass, LLC

Cisco Learning Partner

www.NetMasterClass.com

Some suggested opening moves for troubleshooting  and configuring a baseline MPLS Layer 3 VPN:

Some Suggested Opening Moves for Troubleshooting MPLS

Start at the PE routers:

***Check both ends of a PE connection from a VRF perspective:

1). Check to make sure the associated VRF?s are using the same RD

2). Check to make sure the route-target import and export statements complement each other.

3). Check to make sure vrf forwarding is enabled on the correct interfaces

4). Are all applications of the VRF name applied in a consistent case-sensitive manner.

Verify with:

Show ip vrf

***Check both ends of a PE connection from a m-BGP perspective:

1). Check to make sure the BGP update-source is reachable via the global routing table and is not in a VRF

2). Check the usual BGP issues: the neighbor remote-as statements complement each other.

3). Check to make sure the ipv4 unicast address-family is either activated or deactivated. If it is de-activated and the vpnv4 address-family is activated, it will cause many BGP error  messages to be generated until the remote end has the vpnv4 address-family activated.

Verify with:

Sh bgp vpn unicast all summ

***Check the baseline MPLS switching configuration on the edge PE routers as well as on the internal MPLS switching devices

1). Is MPLS activiated on all of the interfaces in the MPLS path

2). Is the LDP router-id pingable?

3). Is the LDP router-id associated with an IP address in a VRF? If it is, select another IP address.

4). Is the next-hop of the vpnv4 path advertised with its original mask If it is being advertised via OSPF and the loopback is generating a host route due to the OSPF loopback network  type, change the OSPF network type or change the loopback mask-length to /32.

Verify with:

Sh mpls ldp neigh

Show mpls forwarding

***Now, Check the PE to CE Connections and Configurations

Verify with:

Show ip route vrf XXX on the PE router

Under the most basic configurations, these routes will be listed as BGP routes. They will be redistributed

Into the VRF IGP’s on the PE router. While the routes will reside in the PE router as BGP routes, they

Should also appear in the IGP database and/or topology tables such as “show ip ospf database” or “show ip

Eigrp topology”.  See the next step for more details:

**Check the Redistribution Statements between the edge routing protocols and the mp-BGP peer on the PE.

Check to make sure the edge routes are being learned over the mp-BGP connection.

Verify with:

Sh bgp vpn unicast all

Sh bgp vpn unicast all x.x.x.x

**Finally, check the edge CE routers to make sure they have received the routes:

This involves standard non-VRF router show commands such as:

Sh ip ospf neigh

Sh ip ospf database

Sh ip ro

Sh ip eigrp neighbor

Sh ip eigrp topology

Sh ip route

**Some Good Multi-Purpose MPLS Verification and Testing Tools

Clear mpls counters

Debug mpls packet – Look for both packets being transmitted and received on each transit interface.

Debug bgp vpn unicast all updates

Trace vrf

Ping vrf

Sh ip ro vrf

Using Debug IP Packet to troubleshoot MPLS:

When you see the following debug ip packet output:

*Sep 21 17:58:47.883: IP: s=2.2.2.2 (local), d=3.3.3.3 (Serial0/0/0), len 76, sending

*Sep 21 17:58:47.883: IP: s=2.2.2.2 (local), d=3.3.3.3 (Serial0/0/0), len 76, MPLS encapsulation failed

Please, note that this is a ?work in progress? by the NMC CCIE mentoring community. We hope you find this useful. Please free to add whatever comments you have. Thanks!