Re: Formulating an MPLS Opening Moves Strategy

From: Narbik Kocharians <narbikk_at_gmail.com>
Date: Thu, 30 Sep 2010 02:05:33 +1000

To All,

It may seem to some of us that this is a FREE advertising, and maybe it is,
but the benefits of these FREE stuff is enormous. People will learn a lot
from them. Recently we offered a FREE site-to-site VPNs (Roughly around
300-400 pages of labs and full explanations), as Marko mentioned, they have
FREE webinars, and as Bruce mentioned Netmaster has FREE webinars as well.

Take advantage of them and learn from them. like i always say "Any lab will
teach you something" this could be from the vendor you like, or from the
vendor you don't. But at the end of the day, you will gain so much knowledge
it's incredible.

Enjoy the FREE stuff. It takes lots of prep work for Bruce or Marko or
anyone else to do one of these. Enjoy them.

On Thu, Sep 30, 2010 at 1:47 AM, Marko Milivojevic <markom_at_ipexpert.com>wrote:

> I don't want to join any party if it's against the rules. However, I'd
> gladly point out that we not only had several free online seminars,
> but they are recorded and freely available for anyone to watch
> afterwards: http://bit.ly/vLecture
>
>
> --
> 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 15:45, <ron.wilkerson_at_gmail.com> wrote:
> > Just noticing this??? B Have you heard of micronics :)
> > Join the party
> > Sent from my Verizon Wireless BlackBerry
> >
> > -----Original Message-----
> > From: Marko Milivojevic <markom_at_ipexpert.com>
> > Sender: nobody_at_groupstudy.com
> > Date: Wed, 29 Sep 2010 15:34:49
> > To: Andrew Bruce Caslow<abcaslow_at_netmasterclass.net>
> > Reply-To: Marko Milivojevic <markom_at_ipexpert.com>
> > Cc: <ccielab_at_groupstudy.com>
> > Subject: 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
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Narbik Kocharians
CCSI#30832, CCIE# 12410 (R&S, SP, Security)
www.MicronicsTraining.com
Sr. Technical Instructor
YES! We take Cisco Learning Credits!
Training And Remote Racks available
Blogs and organic groups at http://www.ccie.net
Received on Thu Sep 30 2010 - 02:05:33 ART

This archive was generated by hypermail 2.2.0 : Fri Oct 01 2010 - 05:58:06 ART