Re: Formulating an MPLS Opening Moves Strategy

Does this mean it's OK for the rest of us to advertise our free
training material here?

--
Marko Milivojevic - CCIE #18427
Senior Technical Instructor - IPexpert
FREE CCIE training: http://bit.ly/vLecture
Mailto: markom_at_ipexpert.com
Telephone: +1.810.326.1444
Web: http://www.ipexpert.com/
On Wed, Sep 29, 2010 at 14:56, Andrew Bruce Caslow
<abcaslow_at_netmasterclass.net> wrote:
> 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. B 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. B 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. B At the end of this e-mail B 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. B 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. B 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 B 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 B 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 B 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". B 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net