I went at a full lab and kept accurate timings as I went.

Morning

• Initial Configurations – Full Lab Reading – My own diagram took 45 minutes.
• Testing of L2 and FR pre-configurations and validation took up 15 minutes.
• ISIS was fine a mixture of L2 and L1, OSPF was okay add in some advanced IGP features and complete in 20 minutes.
• BGP was going well, two AS’s to be built, iBGP, eBGP – 40 minutes
• But I got caught cold with a simple omission that I just could not see – asked to use the [not so new now] format AA:NN and advertise as such – configured up the ip community list, created the route map, matched on the community and used the set command to specify the value required but here’s where I got thrown – I played with both advertising the network using the network statement under the ipv4 address family and specifying the route map and then also with specifying the route map under the neighbor command with the route map filtering on an inbound direction. The latter was kinda cheating but strangely I saw the community value under the “sh ip bgp x.x.x.x” command but then not another time – I had forgotten the “send-community” command for the relevant neighbors and just could not see that! Some BGP advanced features were fine but I had used up over 1 hour.
• MPLS – I really like this section – LDP, Neighbors, Traffic Engineering [really well documented in DocCD], no issues – 35 minutes and that brought me up the halfway mark. It did raise a question in my head – if you are asked for a specific path in a traffic engineering tunnel should we also place a second dynamic entry in addition to the 1st explicit entry? i am leaning towards yes – Why? Because if there is an issue with one of your routers in the tunnel path then you can lose connectivity and thus points – whereas the dynamic option ensure connectivity remains and points lost are minimised – finally from reading forums and feedback over configuration will not go against you once its within the lab guidelines.
• Save configurations and reload.

Now I am a little behind on my plan which is L2, L3 IGP, EGP , MPLS, and some QoS\Security\features before lunch for my actual lab attempt as I know I’ll need time to gain as much as possible from the MPLS VPN Section.

Afternoon

• Quick check of morning work – ’sh isis nei’, ’sh ip ospf nei’, ’sh ip bgp summ’, pings, etc – 10 minutes.
• QoS – a whole myriad of items, CAR, NBAR, FRTS, etc – some items found in the 12.4 docs, some easier to find in the 12.2 doc’s – watch for anomalies here in the IOS e.g. FRTS with 7200’s – Time =36 minutes.
• Services\Management – based on the blueprint – I went for questions on RMON, Netflow, SNMP, etc – Some queries – If we get asked for Netflow do we go for V5 or V9? I have worked with V5 for years and only recently set about configuring V9 in work – one for the proctor maybe? Time = 45 mins.

MPLS VPN 

• VRF – I copied and pasted a string of VRF details in as initial configs as per the lab and this really took time for me to resolve. MP-iBGP – no issues – up and running across several routers – well documented again in the Doccd if you’re not familiar. 2nd site configured with some redistribution between OSPF & BGP – Note for redistributing OSPF into BGP I use the IEE acronym [as in the shorter version of IEEE - the engineering institute] as in matching internal ext 1 ext 2. Just helps for redistributing all OSPF routes. 1st and 2nd sites talking – redistributing and setting some advanced features – verification can be difficult having to know exactly what to look for and more importantly where – I used the INE SP Vol2 Lab Workbook in this regard as the newer solutions guide for the Dynamips version has verification and validation commands in addition to the solutions. The key to this section is two-fold – ascertaining what is being asked for – knowing where to configure what and avoiding troubleshooting if at all possible. My total time for 9 sections was 3 hours – Ouch!!!
• Security – A lot of this was done as part of the IGP\EGP and MPLS sections as it asked for authentications and filtering there – additional filtering and total time was 20 mins.
• Finally – Multicast – PIM SM across the AS’s  – RP\BSR and multicast VPN – total time of 25 minutes – no major issues – what’s nice about multicast is that if there are errors it tells you on screen and the messages are fairly accurate.

Conclusion:- Total Time = 9h 15 mins – Hmmm – have to speed up both to finish and allow additional time for verification otherwise happy enough with 20 days to go.

What is it with typo’s – is it that we get used to using F7 with Microsoft Word\Outlook to auto-correct our natural spelling mistakes? There is of course no such luxury in IOS and I am constantly having to backtrack on small errors not just typos that have huge implications.

Examples include …..

• NET addressing with ISIS
• Advertising networks into BGP
• Enabling mpls traffic-eng tunnels on the wrong physical interfaces
• Specifying the wrong ip addresses for various interfaces
• Adding neighbors into the wrong address-families
• Wrong mask details for OSPF networks or when filtering through access-lists\prefix-lists, etc
• Missing configurations – e.g. not placing all route-target import\export entries across all transit routers in the inter-network
• Redstribution Filtering – trying to trap all posssibilities – I favour the tagging method.

You’ll have noticed that my blogging has been less technical and more observational – this is of course deliberate – more hours labbing! I have some rack rental time over the coming weekends with both INE & IPExpert – I have put together 4 “Master Labs” basically a culmination of both the aforementioned workbooks plus my recalled tasks I received in my 1st lab attempt [No, not available] – broken these into the 9 sections – put a big chart on my whiteboard and ticking the boxes off as I go. I am fairly confident I can sort out the foundations of the lab reasonably quickly i.e. L2\IGP\EGP & MPLS. The key for me will be obtaining as many of the MPLS VPN’s 27 points available. I am confident with Basic\Multi-VRF, MP-iBGP, MP-eBGP but advanced configurations are killing me time wise and even though I can configure up L2VPN it just seems so strange to type in ‘interworking ip’ commands on one end of the network and the neighbors appear by magic on the other – Good Stuff!

One of the keystones to success in the SP Lab Exam is verification. Now this is obviously key to all tracks but is particularly complex in SP.

With the RS exam there are 4 ways to verify connectivity – ping, traceroute, routing table lookup and TCL Scripting [extended version of ping] where we put together a TCL Script using the foreach functionality – specify the various IP ranges used during the exam and execute the perl script on the routers. It has been covered in various other posts so here’s a link to NMC’s[or Cisco's] TCL document -> http://www.netmasterclass.net/site/articles/CISCO%20IOS%20TCL%20and%20RCMD%20testing%20and%20troubleshooting%20scripting.pdf

Note that for the for the 3550’s, they do not support TCL rather use macro’s so in config mode type…

macro name ICMP
do ping 18.1.1.1
do ping 18.2.2.2
do ping 18.3.3.3
do ping 18.4.4.4
@

However we use the address-family concept in SP and as a result this technique is only valid for L2 & L3 addresses not associated with address-families. As a result we need to place various appendages to our verification commands. Concentrating on the MPLS VPN world we use…

“show ip bgp vpn all summary” command to check the MP-BGP establishment status

“show ip vrf detail” command to verify the import and export route targets.

“ping vrf <vrf> <ip address> source <source ip>” to ping ip addresses not in standard routing table

“sh ip bgp vpn all summary”
Lists all of the MP-BGP and CE peers.

“sh ip bgp vpn all”
Lists all of the VPN prefixes advertised and received by the router.

“sh ip bgp vpn vrf <vrf> summary”
Similar to the first command, but for a specific VRF.

“sh ip bgp vpn vrf <vrf>”
Lists all of the VPN prefixes received in a specific VRF.

“sh ip bgp vpn vrf <vrf> labels”
Lists labels for the VPN prefixes in a VRF.

“sh mpls forwarding”
Shows all LFIB entries (VPN, non-VPN, TE, and so on).

“sh mpls forwarding | inc <prefix>”
Shows whether the prefix is present in the LFIB or not.

“sh mpls forwarding vrf <vrf> <prefix>”
Shows LFIB lookup based on a VPN prefix.

“sh mpls forwarding label <label>”
Shows LFIB lookup based on an incoming label.

This also extends to Multicast wher you need to amend the commands such as sh ip pim vrf <vrf> int, etc.

As you can see the verification in the MPLS VPN portion of the lab will require a good deal of time and hence perhaps why Cisco perform so much pre-config on this exam.

The more mock labs I do the more I realise the SP Lab is all about details. Small details or nuances if you wish. Having completed INE Vol2 Lab 7 tonight I have begun collecting them and the trick is to be aware of their existance during the pressure moments of the lab.

• Typos – These happen to me all the way through my practise labs – NET addresses in ISIS, ATM PVC addressing, the wrong configuration on the wrong router or the right configuration on the wrong interface, wrong masks on loopbacks, etc
• Gotchas – ensure clns statements added to both ATM & FR connections if passing ISIS traffic across. Know the PPPoE configuration is dependent on IOS versions with different hardware,
• Diagram\IP Analysis – Match up your pre-configurations with the diagrams handed out. You literally have to walk each router interface by interface and match it up with the workbook you have been given. It has been known for the wrong workbooks to be handed to candidates.
• Pro-Active Management – Enable debug ip routing on relevant core devices – you need to know when routes are being deleted on one router as you make changes on another.
• Always complete IGP, EGP, MPLS & MPLS VPN prior to multicast to prevent issues such as RPF, etc -> Look what happens when you do not!

Rack1R4(config-if)#ip vrf forwarding 65001
% Interface Ethernet0/1 IP address 10.3.48.4 removed due to enabling VRF 65001
Rack1R4(config-if)#
%PIM-5-NBRCHG: neighbor 10.1.48.8 DOWN on interface Ethernet0/1 non DR
Rack1R4(config-if)#ip address 10.3.48.4 255.255.255.0

• Be aware that strange events will occur – do not let them phase you – here is an example – enabling VRF on an interface removes the ip address right?

Rack1R2(config-if)#ip vrf forwarding 65001   
% Interface FastEthernet1/0 IP address 10.3.27.2 removed due to enabling VRF 65001
Rack1R2(config-if)#
RT: del 10.3.27.0/24 via 0.0.0.0, connected metric [0/0]
RT: delete subnet route to 10.3.27.0/24
RT: delete network route to 10.0.0.0
Rack1R2(config-if)#
%DEC21140-5-REMOVE_HWADDR_FAIL: Interface FastEthernet1/0 failed to remove Addr:=0100.5e00.000d from HWAF

• Reloads – 1. Know when to reload - 2. why you should reload – 3. how reload can help you and 4. when not to reload.

My opinion? 1. At the start to ensure no gremlins, if strange events\issues strike you, just before lunch. 2. To remove issues, to ensure stable configurations & for piece of mind. 3. again to assist in resolving unknown issues and 4. at the end of the lab.

• Time Management – we stress this over and over again but we engineers do not know when to let an issue go – however be aware that the SP exam is more hierarchical then the RS exam and there is less scope for skipping sections due to the nature of the SP Core and the reasoning behind end-to-end connectivity.

These are just some notes as I have come across them – there are a few more and I will incorporate them in the Version 3 of the CCIE SP Lab Checklist which I published before my last attempt in February.
Happy labbing, Steve

Hi,

I have been dual studying this past month both CCIE Service Provider and VMware VCP. I completed the VMware 3.5 Course earlier in the year and have been part of the management team for a set of 16 ESX servers hosting 100 servers for the past year. Given the VCP4 vSphere exam takes over the VCP 3 exam in December and that I move on shortly from this role I decided to maximise both my time on this project and my training.

However I failed the VCP exam in July but managed to get through on my 2nd attempt yesterday. Cisco and VMware are tied together ownership wise Ref: http://www.vmware.com/company/news/releases/cisco.html and it made sense especially considering announcements such as these -> http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/net_brochure0900aecd806abf2f.htmlhttp://www.vmware.com/company/news/releases/cisco_vmworld08.html

http://www.vmware.com/company/news/releases/cisco_vmworld08.html

so I completed the pass and onwards to my 2nd SP attempt – 60 days to go!!

This is a list of terms I began to build following research on Netflow Configuration – These are CCIE SP specific. Hope they are of use to you.

BGP—Border Gateway Protocol. An interdomain routing protocol that replaces Exterior Border Gateway Protocol (EGP). BGP exchanges reachability information with other BGP systems. It is defined by RFC 1163.

BGP/MPLS/VPN—A VPN solution that uses MPLS and BGP protocol to allow multiple remote customer sites to be connected over an IP backbone. Refer to RFC 2547 for details.

CE router—A customer edge router. A router that is part of a customer network and interfaces to a PE router.

customer network—A network that is under the control of an end customer. A customer network can use private addresses as defined in RFC 1918. Customer networks are logically isolated from each other and from the provider network. A customer network is also known as a C network.

egress PE—The provider edge router through which traffic moves from the backbone to the destination VPN site.

EGP—Exterior Gateway Protocol. Internet protocol for exchanging routing information between autonomous systems. Documented in RFC 904. Not to be confused with the general term exterior gateway protocol. EGP is an obsolete protocol that was replaced by BGP.

export packet—A packet from a device (for example, a router) with NetFlow Services enabled that is addressed to another device (for example, a NetFlow collector). This other device processes the packet (parses, aggregates, and stores information on IP flows).

FEC—Forward Equivalency Class. A set of packets that can be handled equivalently for the purpose of forwarding and thus is suitable for binding to a single label. The set of packets destined for an address prefix is one example of an FEC. A flow is another example.

flow—Stream of data traveling between two endpoints across a network (for example, from one LAN station to another). Multiple flows can be transmitted on a single circuit. Packets with the same value for source address, source port, destination address, and destination port might be considered a flow or A set of packets with the same source IP address, destination IP address, source/destination ports, and type-of-service, and the same interface on which flow is monitored. Ingress flows are associated with the input interface, and egress flows are associated with the output interface.

flowset—A generic term for a collection of records that follow the packet header in an export packet. The flowset contains information that must be parsed and interpreted by the collector device. There are two types of flowsets: template and data. An export packet contains one or more flowsets, and both template and data flowsets can be mixed within the same export packet.

ICMP - Internet Control Message Protocol. Network layer Internet protocol that reports errors and provides other information relevant to IP packet processing. Documented in RFC 792.

ICMP flood - Denial of service attack that sends a host more ICMP echo request (“ping”) packets than the protocol implementation can handle.

IGMP - Internet Group Management Protocol. Used by IP hosts to report their multicast group memberships to an adjacent multicast router.

IGP - Interior Gateway Protocol. Internet protocol used to exchange routing information within an autonomous system. Examples of common Internet IGPs include IGRP, OSPF, and RIP.

IIH - IS-IS Hello. Message sent by all IS-IS systems to maintain adjacencies.

Integrated IS-IS – Routing protocol based on the OSI routing protocol IS-IS but with support for IP and other protocols. Integrated IS-IS implementations send only one set of routing updates, making it more efficient than two separate implementations. Formerly called Dual IS-IS.

Internet Protocol (IP, IPv4) – Network layer for the TCP/IP protocol suite. Internet Protocol (version 4) is a connectionless, best-effort packet switching protocol. Defined in RFC 791

internetwork - Collection of networks interconnected by routers and other devices that functions (generally) as a single network. Sometimes called an internet, which is not to be confused with the Internet.

internetworking - General term used to refer to the industry devoted to connecting networks together. The term can refer to products, procedures, and technologies.

Inverse ARP – Inverse Address Resolution Protocol. Method of building dynamic routes in a network. Allows an access server to discover the network address of a device associated with a virtual circuit.

IP – Internet Protocol. Network layer protocol in the TCP/IP stack offering a connectionless internetwork service. IP provides features for addressing, type-of-service specification, fragmentation and reassembly, and security. Defined in RFC 791

IP multicast – Routing technique that allows IP traffic to be propagated from one source to a number of destinations or from many sources to many destinations. Rather than sending one packet to each destination, one packet is sent to a multicast group identified by a single IP destination group address.

IP explicit path – A list of IP addresses, each representing a node or a link in the explicit path

IS-IS – Intermediate System-to-Intermediate System. OSI link-state hierarchical routing protocol based on DECnet Phase V routing, whereby ISs (routers) exchange routing information based on a single metric to determine network topology.

ISP - Internet service provider. Company that provides Internet access to other companies and individuals.

IPv6—IP version 6. Replacement for the current version of IP (version 4). IPv6 includes support for flow ID in the packet header, which can be used to identify flows. Formerly called IPng (next generation).

ingress PE—The provider edge router through which traffic enters the backbone (provider network) from a VPN site.

label—A short, fixed-length identifier that tells switching nodes how the data (packets or cells) should be forwarded.

label imposition—The act of putting the first label on a packet.

LDP—label distribution protocol. A standard protocol between MPLS-enabled routers to negotiate the labels (addresses) used to forward packets. The Cisco proprietary version of this protocol is the Tag Distribution Protocol (TDP).

MPLS—Multiprotocol Label Switching. Switching method that forwards IP traffic using a label. This label instructs the routers and the switches in the network where to forward the packets based on preestablished IP routing information.

MPLS flow – A unidirectional sequence of MPLS packets that arrives to a router on the same subinterface, has the same source and destination IP addresses, the same Layer 4 protocol, the same TCP/UDP source and destination ports, and the same type of service (TOS) byte in the IP header. A TCP session is an example of a flow.

MIB - Management Information Base. Database of network management information that is used and maintained by a network management protocol, such as SNMP or CMIP. The value of a MIB object can be changed or retrieved using SNMP or CMIP commands, usually through a GUI network management system. MIB objects are organized in a tree structure that includes public (standard) and private (proprietary) branches.

MTU - maximum transmission unit. Maximum packet size, in bytes, that a particular interface can handle.

multicast - Single packets copied by the network and sent to a specific subset of network addresses. These addresses are specified in the Destination Address Field. Compare with broadcast and unicast.

multicast address – Single address that refers to multiple network devices. Synonymous with group address. Compare with broadcast address and unicast address.

multicast group – Dynamically determined group of IP hosts identified by a single IP multicast address.

options template—A special type of template record used to communicate the format of data related to the NetFlow process.

OSPF—Open Shortest Path First. A link-state, hierarchical Interior Gateway Protocol (IGP) routing algorithm proposed as a successor to RIP in the Internet community. OSPF features include least-cost routing, multipath routing, and load balancing.

packet header—The first part of an export packet that provides basic information about the packet, such as the NetFlow version, number of records contained within the packet, and sequence numbering, so that lost packets can be detected.

PAP - Password Authentication Protocol. Authentication protocol that allows PPP peers to authenticate one another. The remote router attempting to connect to the local router is required to send an authentication request. Unlike CHAP, PAP passes the password and the host name or username in the clear (unencrypted). PAP does not itself prevent unauthorized access but merely identifies the remote end. The router or access server then determines whether that user is allowed access. PAP is supported only on PPP lines.

PIM - Protocol Independent Multicast. Multicast routing architecture that allows the addition of IP multicast routing on existing IP networks. PIM is unicast routing protocol independent and can be operated in two modes: dense and sparse.

PIM sparse mode – One of the two PIM operational modes. PIM sparse mode tries to constrain data distribution so that a minimal number of routers in the network receive it. Packets are sent only if they are explicitly requested at the RP (rendezvous point). In sparse mode, receivers are widely distributed, and the assumption is that downstream networks will not necessarily use the datagrams that are sent to them. The cost of using sparse mode is its reliance on the periodic refreshing of explicit join messages and its need for RPs. Sometimes called sparse mode PIM or PIM SM.

PIM dense mode – One of the two PIM operational modes. PIM dense mode is data-driven and resembles typical multicast routing protocols. Packets are forwarded on all outgoing interfaces until pruning and truncation occurs. In dense mode, receivers are densely populated, and it is assumed that the downstream networks want to receive and will probably use the datagrams that are forwarded to them. The cost of using dense mode is its default flooding behavior. Sometimes called dense mode PIM or PIM DM.

policy routing – Routing scheme that forwards packets to specific interfaces based on user-configured policies. Such policies might specify that traffic sent from a particular network should be forwarded out one interface, and all other traffic should be forwarded out another interface.

POP - 1. point of presence. In OSS, a physical location where an interexchange carrier installed equipment to interconnect with a local exchange carrier (LEC) or 2. Post Office Protocol. Protocol that client e-mail applications use to retrieve mail from a mail server.

PPP - Point-to-Point Protocol. Successor to SLIP that provides router-to-router and host-to-network connections over synchronous and asynchronous circuits. Whereas SLIP was designed to work with IP, PPP was designed to work with several network layer protocols, such as IP, IPX, and ARA. PPP also has built-in security mechanisms, such as CHAP and PAP. PPP relies on two protocols: LCP and NCP.

PQ/CBWFQ – priority queueing/class-based weighted fair queueing (PQ/CBWFQ). Feature that brings strict priority queueing to CBWFQ. Strict priority queueing allows delay-sensitive data, such as voice, to be dequeued and sent first (before packets in other queues are dequeued), giving delay-sensitive data preferential treatment over other traffic.

PE router—A provider edge router. A router at the edge of a provider network that interfaces to CE routers.

provider network—A backbone network that is under the control of a service provider and provides transport among customer sites. A provider network is also known as the P network.

QoS – quality of service. Measure of performance for a transmission system that reflects its transmission quality and service availability.

TDP—Tag Distribution Protocol. The Cisco proprietary version of the protocol (label distribution protocol) between MPLS-enabled routers to negotiate the labels (addresses) used to forward packets.

virtual LAN - Group of devices on one or more LANs that are configured (using management software) so that they can communicate as if they were attached to the same wire, when in fact they are located on a number of different LAN segments. Because VLANs are based on logical instead of physical connections, they are extremely flexible.

virtual circuit - Logical circuit created to ensure reliable communication between two network devices. A virtual circuit is defined by a VPI/VCI pair, and can be either permanent (PVC) or switched (SVC). Virtual circuits are used in Frame Relay and X.25. In ATM, a virtual circuit is called a virtual channel. Sometimes abbreviated VC. See also PVC, SVC, VCD, virtual route, and VPI.

VCI - virtual channel identifier. 16-bit field in the header of an ATM cell. The VCI, together with the VPI, is used to identify the next destination of a cell as it passes through a series of ATM switches on its way to its destination. ATM switches use the VPI/VCI fields to identify the next network VCL that a cell needs to transit on its way to its final destination. The function of the VCI is similar to that of the DLCI in Frame Relay. Compare with DLCI. See also VCL and VPI.

VPN—Virtual private network. A network that enables IP traffic to use tunneling to travel securely over a public TCP/IP network.

VRF—VPN routing and forwarding instance. The VRF is a key element in the MPLS VPN technology. VRFs exist on PEs only. A VRF is populated with VPN routes and allows multiple routing tables in a PE. One VRF is required per VPN on each PE in the VPN. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table. In general, a VRF includes the routing information that defines a customer VPN site that is attached to a PE router.

 References:

http://ciscosystems.com/en/US/docs/ios/12_0st/12_0st10/feature/guide/egress.html#wp1020366

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsmnf24.html#wp1027188

http://www.cisco.com/en/US/docs/internetworking/terms_acronyms/ita.html

As stated previously in order to try and pass the SP Lab the 2nd time around I went into real post-mortem analysis of my lab attempt and the training materials available. I also have gone through multiple Cisco Presentations, NANOG sessions, Networkers aka Live, listened to various podcasts, videos on demand and finally delved deep into Cisco Forums. Key points uncovered and reasons for failing the SP Lab.

• Over-confidence in pre-configurations – you must verify everything before you start – I cannot over emphasise this point.
• Ensure your lab matches your topology – ping directly connected ethernet devices, L2, some basic L3, some MPLS and some VRF are already pre-configured – check this pre-config. Ref: Networkers 2009 CCIE SP Techtorial
• INE SP Mantra – Build and Verify then move on!!!!
• Running out of time due to over-configuration, IOS Bugs, router reloads, misreading of the exam questions, troubleshooting issues, etc
• Staying with IOS Bugs, certain SP stuff works one way on 2600’s and another on 3600’s – be aware of the IOS nuances, reload at least twice during the lab.
• Sequence is everything in the SP exam – e.g. MPLS TE – you must enable MPLS TE capability for the IGP’s prior to configuring the MPLS TE itself or it might not work Ref: INE CCIE SP CoD. It does not mean it won’t work but it might not work. Also it may take up to 20 minutes to decide to work. This is an issue close to my heart as I configured MPLS TE perfectly on my lab or so I thought but no marks.
• Be aware that it appears the proctor has the ability to remote onto your PC – this does not mean they do anything other than observe.
• Ensure your IGP & EGP are completed and stable prior to starting multicast section to ensure you do not encounter SPF issues. Ref: INE RS V4
• Know the nuances regarding reachability in the SP Lab as against the RS Lab – TCL alone here will not suffice, remember ping , ping vrf, etc
• Also remember that full reachability is not necessarily required as per SP networks in general Ref: CCIE SP ‘Ask the Expert’
• Verification is unbelievably important [Stressing the obvious] – know your commands, know what to expect form the outputs – e.g. MPLS see an outgoing lable be an incoming label on the next hop
• Use notepad for large configurations or even for troubleshooting – it’s harder to scroll page after page on SecureCRT on a per router basis than to ’select all’ copy to notepad and compare two router configurations that way
• Answer what is explicitly asked for and nothing else – no points lost for over-configuration
• Do not reload the routers before you leave the exam Ref: CCIE SP Tips – Cisco Learning Network
• Watch out for label forwarding breaks in the MPLS VPN’s where VPN routes will be able to exchange between PE’s but VPN traffic cannot be delivered Ref: CCIE SP Tips – Cisco Learning Network

The title of this blog entry is ‘Is the fog lifting’ – I am beginning to see the various nuances now – e.g. make sure you match internal external on your OSPF redistribution as external routes not passed by default, local preference BGP attribute is reflected throughout AS as against other attributes such as weight which is locally significant, IP addressed removed when enabling VRF forwarding on interface because the prefix is taken from the IPv4 table and inserted into the VRF table, etc.

Apologies for the lack of technical blogging but I have been really busy studying and labbing up various SP labs. I will post up some of my jotted notes and gotcha’s shortly but I just wanted to get this link to you. I’m sure some the of the more experienced SP candidates may be aware of this but NANOG is a great resource specifically here -> http://www.nanog.org/presentations/archive/index.php

Simply navigate to a particular year or NANOG Session to see the various video files or PDF presentations. For example – Select 2006, select NANOG Meeting 24, there you have the following topics directly related to the SP Lab.

• Pseudowires and L2TPv3 Engineering
• ISIS Routing on the Qwest Backbone: a Recipe for Subsecond ISIS Convergence
• An Approach to IP Network Traffic Engineering
• How to Secure Your Job: Implement MPLS VPNs
• Global Crossing’s Operational Experience With MPLS
• IS-IS Deployment & Design Guidelines, with Emphasis on New Features
• Inter-domain Traffic Engineering: Principles, Applications, and Case Studies

Enjoy your discovery of this site – great stuff!

I for one love mp3’s and podcasting – I have worked a shift rota for the last several years and miss out on a lot of talk and sports shoes which I podcast. Applying this to Cisco studies I have found a number of really good links for those that do not get to Cisco Live\Networkers, or product releases, etc.

Cisco Switching Podcast Series:- http://www.cisco.com/en/US/prod/switches/networking_solutions_products_genericcontent0900aecd805f25cc.html

Cisco Data Center Podcast:-http://www.cisco.com/cdc_content_elements/podcast/index.shtml

Cisco Technology Podcast:-http://www.cisco.com/en/US/products/products_technology_podcast_listing.html

Cisco SP360 Service Provider MP3 Links:-http://blogs.cisco.com/search/results/10157add726c281567ef60c7f9a41b0a/

MPLS – multi protocol label switching

• can transport different payloads incl. L2/L3 protocols
• switches traffic between interfaces based on locally significant label values similar to DLCI’s for frame-relay.

Why use MPLS?

• independent of medium being transported across
• allows for BGP free core thus saving routing table space e.g. up to 200,000 routing table entries on the internet.
• less resources used, less lookups
• traffic engineering – use underutilised links, b/w guarantee, quick failure detection via fast re-route.
• L2/L3 VPN Service available, no need for additional VPN technologies.

MPLS Label defined in RFC3032 – label stack encoding.

• 20 bit label – local significance
  3 bit EXP – CoS – 8 variations
  S bit – define bottom label in label stack
  8 bit TTL
• MPLS packet can be encapsulated several times
• Top most label is most significant and determines path taken.
• MPLS labels bound to forward equivalency classes [FEC]
• Label forwarding information base [LFIB] used as against CEF FIB or IP routing table to switch traffic – as a result IP debugging of no use when troubleshooting. The LFIB is built on a hop by hop basis based on the IGP routing table.

Router Types:
P\LSR – provider or label switch router – internal to ISP, only switch MPLS labels.
PE\LE – provider edge\label edge – facing customer, performs both IP & MPLS lookups
CE – customer edge [no mpls knowledge, unlabelled packets only]

MPLS Label Operations:

1. Label push – places mpls label onto unlabelled packets otherwise know as imposition at PE
2. Label pop - on PE, removes the mpls label prior to transporting onto CE otherwise known as disposition
3. Label swap – completed on P routers, replaces the mpls label
4. PHP – penultimate hop popping – used to reduce load on PE routers

Label Distribution:

Label mapping information advertised using Label Distribution Protocol. These include either LDP, TDP, MP-BGP & RSVP.

• MP-BGP – RFC 3107, seen in inter-AS MPLS.
• RSVP – Resource Reservation Protocol – seen in MPLS-TE.
• LDP – Label Distribution Protocol – open standard defined in RFC 3036 using port 646 and using UDP multicast to 224.0.0.2 to discover peers and to establish TCP sessions.
• TDP – Tag Distribution Protocol – Cisco Proprietary using UDP port 711 to discover neighbours and subsequently establish TCP sessions.

Note: IGP adjacency needs to be established ahead of time and labels are automatically advertised for IGP routes which means OSPF or ISIS for the SP Lab. If no IGP available, say only BGP, then neither TDP or LDP can be used.

Configuration:

Three commands are required -> ip cef [to enable cisco express forwarding] globally,
then entering either mpls ip or tag-switching ip under the interface.
Note that sometime mpls ip will display as tag-switching ip depending on the IOS in question. To verify the adjacency use sh mpls ldp nei.
The established TCP session is sourced from the router-id interface by default which is usually the highest active loopback address. You must watch for this in the lab is asked to create a second loopback address at a later stage on an MPLS enabled router – it may cause adjacencies to fail. Modification of this is achieved by mpls ldp disc transport-address command.

To explicitly specify a distribution protocol use the mpls label protocol command at an interface level -> mpls label protocol ldp. it is recommended to manually specify the distribution protocol especially for production networks as IOS upgrades\router changes could have different default values. Once configured across MPLS enabled routers the NBRCHG: TDP Neighbor 172.16.12.10 (1) is UP or similar will appear on each neighbor.
Once neighbors are established you will still see UDP broadcasts taking place even though TCP sessions have been established. Why? To monitor the network segments in case new neighbors appear in order to establish peering sessions.
When troubleshooting, check the mpls forwarding table via sh mpls forwarding-table on a hop by hop basis to ensure that all neighbors are building end to end LSP’s [label switch paths] for appropriate destinations.
Also be aware of Implicit Null possibilities for directly connected neighbors and the corresponding popping that will occur as a result.

Verification:
sh ldp nei
sh mpls ldp nei
sh mpls forwarding-table [IPv4 to Label mappings]
sh ip route [Underlying transit checks]
do sh run int fa0/0
debug ip packet det – look for “UDP src=xxx” entries, 711 indicates TDP, etc. [Be careful with this command]
debug mpls ldp transport events
debug mpls packets
sh log, clear log
undebug all [when complete]