Formulating an MPLS Opening Moves Strategy

Hi Everyone,

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 5th 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 sales person Rauf Rasulov 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. 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!

Blogs and organic groups at http://www.ccie.net
Received on Wed Sep 29 2010 - 10:56:08 ART