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.netReceived on Wed Sep 29 2010 - 15:47:52 ART
This archive was generated by hypermail 2.2.0 : Fri Oct 01 2010 - 05:58:06 ART