Re: Formulating an MPLS Opening Moves Strategy

hahahahaha thanks ron.

On Thu, Sep 30, 2010 at 1:45 AM, <ron.wilkerson_at_gmail.com> wrote:

> Just noticing this??? 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