The new CCIE lab version is in effect. Called version 4.

The first guy on OSL (Online Study List) has been through it, and there’s certainly some changes.

First up, is the annoying OEQ (Open Ended Questions), these were on the retired version 3 as well. Lots of people have issues with them, so I wont bother commenting on them other than saying they scare me too

Second is the trouble-shooting section. According to feedback, this is a doable task, but not easy by any means. You are assigned trouble-shooting tickets which you have to resolve. Apparently its some kind of new user-interface which will be interesting to hear more about. Apparently between 6-12 tickets will be assigned to you.

Third is the lab section. This is as we know it, but scaled to be only 5,5 hours in length to give time for trouble-shooting section. Apparently the passing mark is now 80 instead of 70 which is of some concern. This is the 2nd most interesting thing for me to hear more about… The number one being:

You dont have lab workbooks in physical format

This is really bad if you ask me. To switch back and forth on the screen between your topology diagrams is a nightmare. It will certainly take out a good portion of your time, to recreate stuff on paper. I know that apparently the labs have large monitors, but still, a hassle none the less.

Another member of OSL is up for tomorrow. I really hope he pass it. I also hope he will provide some more insight into the new version of the CCIE lab.

Once you get the initial configurations loaded you’re ready to begin the lab.  This is when the “fun” begins.  Those of us who are used to starting labs with barebone configurations and searching for a few misconfigurations will be in for a bit of a shock.  This is not how this troubleshooting will go.  You’ll be looking at a fully configured network…which you did not build. It was at this point that I should have realized that this would not be easy and that the 2 hour time limit – which initially sounded like all of the time in the world – would be an issue.

When I tell you that you’re looking at a fully configured network, that means things like QoS, Multicast, and IP Services.  You can start to see how difficult Cisco can make these labs.  Throw in a number of devices that you cannot access and INE’s recommendation that you only use show and debug commands, and you’re looking at a bad day on the CLI.

The lab document starts with a “Baseline” section.  This will give you a list of the devices under your control as well as details about how the network has been configured.  This is broken down by well-known sections.  For instance, Bridging and Switching might tell you which devices are STP roots, which VLANs are present, which flavor of STP is running, if and how VTP is set up, etc.  The IGP section describes the routing protocols, any route filtering, redistribution (yes, there is plenty of that), etc.

I read through the baseline and then started making network maps.  INE has some nice examples of the maps that you’ll want to build and how long it should take in the solution guide:

We recommend making your own diagrams, including the following
information:
• IP addressing + IGPs.
• Layer 2 topology.
• BGP diagram.
• IPv6 topology.
• Multicast and Redistribution diagram.

Overall, don’t spend too much time building the baseline – the goal is to spend around 20 minutes. By the end of the baseline analysis phase, you should have clear understanding of the protocols and applications deployed in your network.

It took me a LOT longer than 20 minutes to get my head around what was going on in the network.  It’s much harder to get quickly up to speed on a complex CCIE network when you haven’t built it from scratch. 

After getting a basic idea of what was going on, it was time to start looking at the tickets.  There are ten tickets, each with a point value between 2 to 4 points.  The total amount of points is 30 points, so each ticket will average 3 points.  Like the “classic lab”, you’ll need to fix each issue completely – no partial points are awarded.  There may also be tickets that you cannot resolve unless you’ve already fixed previous tickets.  For example, ticket 10 in lab 1 has the following requirements:

Ticket 10: Multicast
Note: Prior to starting with this ticket make sure you resolved Tickets 4 and 5

Since you need 80% to pass the troubleshooting portion of the lab, you’ll need to get at least 24 points.  This means that you can only really miss about 2 tickets (depending on point values).

Logging is turned off on the devices.  I would strongly suggest enabling logging buffered on all devices(remove the configuration before finishing the lab).  There are a number of logging messages that will point to some initial issues that you might miss if you’re not on the device when the log is generated.  This way you can issue “show log” and see what’s going on.

Another suggestion: work on the tickets that seem easy first.  Then work on any tickets that are requirements for other tickets.  Finally, work on the tougher tickets last.

I used some of my basic, initial troubleshooting habits to find a couple of issues.  In the lab – after building each section – I do basic troubleshooting.  For instance, once all Layer 2 configuration is complete, I verify that I can ping across each link.  After each IGP configuration, I verify that the proper routes are being advertised and received, as well as pinging (at least a subset) of the routes.  I would suggest putting together a “toolkit” of common commands to run on each device when approaching the troubleshooting section such as ’show ip int br | e ass’, ’show ip protocol’, ’show ip [protocol] route’, etc.

Let’s look one of the (easy) tickets from Lab 1:

Ticket 4: Connectivity Issue
• Another ticket from VLAN7 users. They cannot reach any resource on VLAN 5 – all IP Phones have unregistered, and nothing else works.
• However, they are still able to reach the local resources.
• Using the baseline description as your reference, resolve this issue in optimal manner.

3 Points

You will notice this issue if you do a Layer 2 check by pinging across directly connected links.  Basically, you cannot ping from r4 to sw1 on VLAN41.  Looking at sw1, I could see that the SVI interface for VLAN41 was not up.  Sounds like an easy fix.  Make sure that VLAN 41 has been added to the VLAN database.

Actually, it VLAN41 was in the VLAN database.  The IP addressing was correct.  All of the other SVIs were up and working.  WTF?

Here is the configuration for the SVI:

interface Vlan41
ip address 164.16.47.7 255.255.255.0
ip access-group REMOTE_DESKTOP in
ip pim sparse-dense-mode
ntp broadcast client
ntp broadcast

Hmmm….I’ll bet that INE has a dastardly access-list configured.  Let’s see the configuration for that sucker:

ip access-list extended REMOTE_DESKTOP
dynamic RDP timeout 10 permit tcp any host 164.16.7.100 eq 3389
deny   tcp any host 164.16.7.100 eq 3389
permit ip any any

Oh fucking joy.  A dynamic access-list.  But I don’t see how this would be breaking connectivity, let alone keeping my SVI down.  Just to be sure I removed the ACL.  The SVI remained down, but I did catch a break when issued ‘no shut’ after readding the ACL:

*Mar  1 02:19:56.300: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/14 on VLAN0041.

Interesting.  According to our baseline guidelines sw1 should be the root bridge for all active VLANs.  The initial configuration reflects this:

spanning-tree vlan 1-4094 priority 8192

Fa0/14 is a trunk link to sw2:

interface FastEthernet0/14
switchport trunk encapsulation dot1q
switchport mode trunk
spanning-tree guard root

So it looks like someone is generating a better BPDU for VLAN41.  Wanna bet that it’s either sw3 or sw4 – the two switches that are restricted? 

Rack16SW2#sh spanning-tree root

Root    Hello Max Fwd
Vlan                   Root ID          Cost    Time  Age Dly  Root Port
—————- ——————– ——— —– — —  ————
VLAN0001          8193 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0003          8195 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0005          8197 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0007          8199 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0009          8201 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0013          8205 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0018          8210 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0026          8218 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0041          4137 0012.4337.1880        19    2   20  15  Fa0/17         <-NOTE!
VLAN0043          8235 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0055          8247 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0062          8254 0017.0e3f.3900        19    2   20  15  Fa0/14

Rack16SW2#sh spanning-tree vlan 41
VLAN0041
Spanning tree enabled protocol ieee
Root ID    Priority    4137                <-less than 8233 on sw1
Address     0012.4337.1880
Cost        19
Port        19 (FastEthernet0/17)
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    32809  (priority 32768 sys-id-ext 41)
Address     001f.9e4a.fa00
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type
—————- —- — ——— ——– ——————————–
Fa0/4            Desg FWD 19        128.6    P2p
Fa0/14           Desg FWD 19        128.16   P2p
Fa0/17           Root FWD 19        128.19   P2p             <-goes to sw3 not sw1!

I think that I’ve found my problem.  sw3 is advertising a lower priority for VLAN 41.  I went ahead and set the STP priority to 0 for ALL VLANs.  INE chose to only change VLAN 41.

Me:
Rack16SW1(config)#spanning-tree vlan 1-4094 priority 0

INE:
spanning-tree vlan 41 priority 0

Either way, this unblocked f0/14 for VLAN41 and restored the STP instance on that VLAN, which brought up the SVI…which brought up IP connectivity. 

*Mar  1 02:33:29.608: %SPANTREE-2-ROOTGUARD_UNBLOCK: Root guard unblocking port FastEthernet0/14 on VLAN0041.

That should give you an idea of one of the easier tickets.  Even though this was a fairly easy issue, it threw me off my game because 99.99% of the time when I see an SVI down, it’s because the VLAN is not in the VLAN database.

In the final part of the review I’ll discuss the solution guide as well as my overall impressions.

Access to the Volume IV workbook is the same as for all INE workbooks.  Once you’re logged in you’ll find (at present) three troubleshooting labs available.  The workbook will eventually contain 10 troubleshooting scenarios.  Each lab contains 10 trouble tickets which vary in value from 2 – 4 points.  You’ll also get the lab topology, along with initial configurations and the solution guide.

INE Workbook IV

I rented some rack time at INE’s rack rental company, Graded Labs.  I booked a single, 5.5 hour session and planned to attempt the first two labs.  You’re allotted 2 hours for each lab, so I figured I should be able to complete both labs.  I was very wrong.

Graded Labs has a number of configurations for the INE product line which you can choose to have automatically loaded to your rack.  Unfortunately Graded Labs does not have the configs for the new Volume IV workbook yet.  This means that you will initially need to connect to each device and load in the appropriate config.  I had rented rack 16 and was worried that I would need to parse the initial configurations replacing IP addresses to fit the rack number, but INE has the initial configs for 31 different racks (1-30 and the mysterious rack 42) so you don’t need to go through the configs and change the IP addresses to match the rack.  It was just a matter of cutting and pasting in the appropriate configurations.

Initial Configurations For 31 Racks Included

After loading the configurations, it was time to take a look at the lab.  I would very strongly recommend that you take the time to read the Workbook Introduction.  This six page PDF explains INE’s methodological approach to troubleshooting.  You will want to be familiar with it before attempting the labs as it will help you with troubleshooting as well as prepare you for the explanations in the solution guide.

After digesting the Workbook Introduction, it was time to look at the lab.  This is where the first surprises appear.

Lab Do’s and Don’ts:
•  Do not access the routers that are marked as restricted for your access.
•  Do not use the show running-config or show startup-config commands or their equivalents when performing troubleshooting.
•  Do not change or add any IP addresses from the initial configuration unless required for troubleshooting.
•  Do not change any interface encapsulations unless required for troubleshooting.
•  Do not change the console, AUX, and VTY passwords or access methods unless otherwise specified.
•  Do not use any static routes, default routes, default networks, or policy routing unless otherwise specified.
• Save your configurations often.

Those first two restrictions are killers.  While you will use the tried and true INE lab topology for these labs, each lab will include a number of restricted devices – outside of the normally restricted backbone devices.

The topology used for every scenario is the same that we use for all our RS products, including VOL1 (technology- focused labs), VOL2 (configuration mock lab scenarios) and VOL3 (core technologies scenarios).

However, unlike our previous workbooks, we restrict access to some of the devices in the lab topology. For every scenario this “restricted” set may be different and it is clearly outlined in the scenario’s baseline. Using this technique we increase the scenario complexity by allowing candidates to see only “one” side of the problem. When looking at the lab diagram, you will clearly see routers not under your control as being displayed in orange color. Also, when you log onto the “restricted” device, it will warn you using a banner message.

Lab 1 Topology - Note Restricted Devices in Orange

In lab 1 for instance, you are not allowed to access BB1, BB2, BB3, R2, R3, SW3, and SW4.  You’re pretty much on the honor system for the internal network devices as the you’ll be warned by a banner message, but only the first time you connnect (or if you telnet to the device(s)).

For instance, r3 is a restricted device:

Rack16R1#telnet 164.16.35.3
Trying 164.16.35.3 … Open

User Access Verification

Username: cisco
Password:

*****************************WARNING******************************
*                                                                *
*           Per the requirements of this scenario                *
*         You are not allowed to access this router              *
*                                                                *
*****************************WARNING******************************

Rack16R3>

You will not see the exec banner as long as the session to the console line is open from from the access server.  Regardless, it is important that you do not access the verboten devices during the lab.

While the restricted devices threw me an unexpected curve, it was the second requirement that really floored me.

In addition to the above restriction, we highly encourage you not using the show running-configuration, show startup-configuration commands or any other command that shows you the textual representation of the router’s configuration. This requirement makes you focus on using the show and debugging commands, which is invaluable when troubleshooting the real-world scenarios.

Our ultimate goal is not only prepare you for passing the Troubleshooting section of the CCIE R&S lab exam, but also to teach you a structured troubleshooting approach. As opposed to simple guessing and peeking at the routers running configurations you should learn using the debugging commands and interpreting various show commands output.

INE is serious about this too.  The solution guides will only use show and debugging commands to determine the root cause of each issue.  I don’t know if this will be a requirement in the actual lab; I certainly hope not!  In “real life” though, the use of debug commands is pretty much forbidden in the environments that I’ve worked in.  There’s a saying at my job “If you turn on a debugging command you had better have created a network change ticket, otherwise you’ve just created a job change ticket.”  Still, using the debug commands is a very good way to understand the underlying technology and there are some instances where you will get important troubleshooting information for a debug command that you cannot get in a show command.

For every ticket, we are going to follow the same structured procedure to resolve the issue.

Here is an outline of this procedure:

1. Build and Analyze the Baseline
2. Analyze the Symptoms (propose hypothesis)
3. Isolate the issue (gather more symptoms)
4. Fix the Issue (by comparing to the Baseline)

We recommend making your own diagrams, including the following
information:
• IP addressing + IGPs.
• Layer 2 topology.
• BGP diagram.
• IPv6 topology.
• Multicast and Redistribution diagram.

Overall, don’t spend too much time building the baseline – the goal is to spend around 20 minutes. By the end of the baseline analysis phase, you should have clear understanding of the protocols and applications deployed in your network.

This is a brief review of the systematic troubleshooting procedure that you’ll be using for the labs.  You’ll be familiar with the topology drawing bit from your practices labs.  Although, I did pick up some good tips from the solution guide about making topology maps.

Okay, enough jibba jabba about the labs.  Let’s actually dive into one.  That will be the focus of the next part of the review.

As we’re all painfully aware, the next version (4.0) of the CCIE lab exam goes live this October.  For those of us who did not nab a date before the cutover date, we’re looking at a different beast come October.  In addition to a number of new technologies (such as MPLS and Zone Based Firewall) and the dread Core Knowledge questions, there will be a brand new addition: troubleshooting.  Between the Core Knowledge section and the actual lab exam, there will be a troubleshooting section.  While details are still a little vague, here’s what Cisco has said about this section(may require CCO login):

Troubleshooting is allotted two of the eight hours required for the CCIE lab exam. Candidates will be presented with a series of trouble tickets for preconfigured networks and will need to diagnose and resolve the fault or faults. As with previous CCIE labs, the network will need to be up and running for the candidate to receive credit.  Candidates who finish the troubleshooting section early can move on to the configuration section, but they will not be allowed to go back to the troubleshooting section.

Here are some additional details culled from a recent Ask The Expert Section:

• The Troubleshooting section will be independent from the Configuration section, i.e., it will be presented on a different scenario.
• Once you finish the Troubleshooting you will move to the Configuration section that will be presented on a new scenario or topology.
• The Troubleshooting section will have a maximum of 2 hours. The candidate will be presented a series of questions or ‘trouble tickets’ for a given scenario or topology. The referred topology will pre-configured.
• Based on the information provided such as IP addressing diagrams, IGP routing diagrams, and so on you will work to identify and fix the issues. You will be given points for working scenarios.
• The Troubleshooting section will have a certain number of trouble tickets and points allocated to the section. You will receive credits for the points you get. Your score on this section will show as, 30%, or 50%, or 80%, and so on.
• You will need to get a minimum of 80% on each section of the exam to pass on the CCIE lab exam.
• Yes, we are planning to post a sample Troubleshooting questions/trouble ticket for study reference.

Internetwork Expert has a poll up asking CCIE candidates which part of the new lab format scares them the most.  Troubleshooting is the number one choice.

I’ll admit that when I first heard about the addition of troubleshooting to the lab, I was unconcerned.  While I don’t spend any time(outside of practice labs) building complex OSPF networks, I do troubleshoot networks for probably a good 30% – 50% of each workday(not to mention after hours when on call).  Plus, I’ve always been pretty good at the initial troubleshooting sections in the vendor labs.

Petr Lapukhov from INE emailed me recently and gave me access to the first couple of labs in the new Internetwork Expert Volume IV workbook.  This is INE’s new product covering the troubleshooting section of the lab.  I agreed to try the first couple of labs and write my thoughts.  My first thought? I vastly underestimated how potentially difficult the new troubleshooting section could be!

While I have spent a considerable amount of time troubleshooting networks over the last ten (sigh) years, they’ve always been MY networks.  Well, at least they’ve always been networks with which I was very familiar.  So if a server goon bitches about not being able to ping his heart beat IP address, I can quickly re-educate (an exercise in futility) him about the fact that this network exists on a layer-2 only network that is not trunked nor associated with an SVI so he’ll only be able to ping other heart beat IPs sourced from the heart beat IP address on his box.  If I was not aware of the design of this network, then I would have to start with the usual battery of pings and traceroutes to (hopefully) get to the same conclusion.  In other words, familiarity with the network design will make troubleshooting much easier and quicker.  I also overlooked the fact that a good 90% of my daily troubleshooting is really mundane shit like checking speed/duplex, verifying MAC addresses, checking ARP tables, etc.  It’s thankfully very rare that I ever troubleshoot any complicated layer 3 issues.

So while I might feel (justified or not) that I have a lot of troubleshooting experience, a lot of that experience will be worthless in a lab scenerio…as I was soon to discover. 

If a TCP connection does not complete the three-way handshake within a particular time period, TCP intercept sends a TCP reset to the server, cleaning up the connection.

Which TCP intercept mode does this statement best describe?

Highlight for answer: Watch mode.

By default, when does a Cisco router switch over from the root-path-tree to the source-specific SPT?

Highlight for answer: When the first packet is received from the shared tree.  You can change this with the ‘ip pim spt-threshold’ command.

Prefix list explained well

http://ccienotes.blogspot.com/2007/08/ip-prefix-list.html

http://roy.ccieblog.com/2009/03/23/simple-rip-metrics-offset-list-scenario/

Good nice explanation

source -  http://www.iplogic.nl/ip-split-horizon/

IP split-horizon

When the ip split-horizon rule is enabled it will not send updates out the interface it received it on. When this rule is disabled it will send updates out the interface it was received on.

By default ip split-horizon is enabled on ethernet and frame-relay subinterfaces, this means that it will not send updates out the interfaces it receives it on. (ip split-horizon)

By default ip split-horizon is disabled on frame-relay physical interfaces, this means that it will send updates out the interfaces where it receives it on. (no ip split-horizon)

Source -
http://www.petri.co.il/how-to-use-a-distribute-list-to-filter-out-routing-updates-in-cisco-ios.htm

While using Dynamic routing protocols, at some point, you will want to filter the routes that are sent out from one router to another OR filter routes that are received into your router. One of the easiest ways to do this is to use a distribute-list. Let’s find out how

What is a Distribute-List?
First off, let me point out that we are not talking about a “distribution-list”. While the word “distribution” may seem to fit better, that is not what it is called. I too, over the years, have periodically called it a distribution list so I first wanted to set the record straight.

A distribute-list is used to control routing updates either coming TO your router or leaving FROM your router. Distribute-lists work on a variety of different IOS routing protocols. Because of that, learning how to use distribute-lists is very valuable.

As distribute-lists use Cisco IOS Access-Lists, you can very granularly define what routes will or won’t be sent out of the router, or received into the router. Let’s find out how they work…

Step 1 – Define what routes you want to filter
Let’s say that you want to filter inbound routes to a router. Start off by taking a look at your current routing table. What networks, exactly, do you want to filter out? Here is a sample routing table, for our example:

Router# show ip route
Codes: C – connected, S – static, I – IGRP, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2, E – EGP
i – IS-IS, L1 – IS-IS level-1, L2 – IS-IS level-2, ia – IS-IS inter area
* – candidate default, U – per-user static route, o – ODR
P – periodic downloaded static route
Gateway of last resort is not set

100.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 100.200.200.1/32 [110/11] via 172.16.100.29, 00:00:10, Ethernet0
O 100.200.100.1/32 [110/11] via 172.16.100.29, 00:00:10, Ethernet0
C 100.100.250.0/24 is directly connected, Loopback0
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.100.0 is directly connected, Ethernet0
Let’s say that we want to filter out route 10.200.100.1/32.

Step 2 – Create an ACL to filter out that traffic
Next, we need to define an ACL that identifies that route, denies it, and allows all other traffic. Here is the ACL that I used:

Router(config)# access-list 50 deny 100.200.100.1
Router(config)# access-list 50 permit any

Step 3 – Create a Distribute-List that references the ACL and defines the direction
Now, you want to create a distribute-list that references this ACL, then specify the direction that the distribute-list will be applied.
The distribute-list is defined underneath the routing process for the protocol that it is being used on. In our case, we want to filter OSPF routes so we go into the OSPF routing process configuration.

Router(config)# router ospf 10
Router(config-router)#distribute-list ?
<1-199> IP access list number
<1300-2699> IP expanded access list number
WORD Access-list name
gateway Filtering incoming updates based on gateway
prefix Filter prefixes in routing updates

Router(config-router)#distribute-list 50 ?
in Filter incoming routing updates
out Filter outgoing routing updates

Router(config-router)# distribute-list 50 in

Step 4 – Verify that the route has been removed
After you put your new ACL and distribute-list in place, verify that they were successful. Notice how, in the show ip route output below, the 10.200.100.1 no longer shows up.

Router# sh ip ro
(truncated)
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O 100.200.200.1/32 [110/11] via 172.16.100.29, 00:11:39, Ethernet0
C 100.100.250.0/24 is directly connected, Loopback0
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.100.0 is directly connected, Ethernet0
Router#

In Summary
Our route filtering with the distribute-list command was successful. You can use this same concept and procedure to filter out multiple routes from either going in or out of your router. The distribute-list feature works with a number of different routing protocols. You can even specify in the distribute-list command what interfaces you want the command applied to. So, the next time that you need to not send out a route or have a router not receive a route, don’t forget about the distribute-list command (not distribution-list).

Border Gateway Protocol (BGP) is an interdomain routing protocol designed to provide loop-free routing between separate routing domains that contain independent routing policies (autonomous systems). The Cisco IOS software implementation of BGP version 4 includes support for 4-byte autonomous system numbers and multiprotocol extensions to allow BGP to carry routing information for IP multicast routes and multiple Layer 3 protocol address families including IP Version 4 (IPv4), IP Version 6 (IPv6), Virtual Private Networks version 4 (VPNv4), Connectionless Network Services (CLNS), and Layer 2 VPN (L2VPN).
BGP is an interdomain routing protocol designed to provide loop-free routing links between organizations. BGP is designed to run over a reliable transport protocol; it uses TCP (Port 179) as the transport protocol because TCP is a connection-oriented protocol. The destination TCP port is assigned 179, and the local port assigned a random port number. Cisco IOS software supports BGP version 4 and it is this version that has been used by Internet Service Providers to help build the Internet. RFC 1771 introduced and discussed a number of new BGP features to allow the protocol to scale for Internet use. RFC 2858 introduced multiprotocol extensions to allow BGP to carry routing information for IP multicast routes and multiple Layer 3 protocol address families including IPv4, IPV6, and CLNS.

BGP is mainly used to connect a local network to an external network to gain access to the Internet or to connect to other organizations. When connecting to an external organization, external BGP (eBGP) peering sessions are created. Although BGP is referred to as an exterior gateway protocol (EGP) many networks within an organization are becoming so complex that BGP can be used to simplify the internal network used within the organization. BGP peers within the same organization exchange routing information through internal BGP (iBGP) peering sessions
BGP uses a path-vector routing algorithm to exchange network reachability information with other BGP speaking networking devices. Network reachability information is exchanged between BGP peers in routing updates. Network reachability information contains the network number, path specific attributes, and the list of autonomous system numbers that a route must transit through to reach a destination network. This list is contained in the AS-path attribute. BGP prevents routing loops by rejecting any routing update that contains the local autonomous system number because this indicates that the route has already travelled through that autonomous system and a loop would therefore be created. The BGP path-vector routing algorithm is a combination of the distance-vector routing algorithm and the AS-path loop detection
BGP selects a single path, by default, as the best path to a destination host or network. The best path selection algorithm analyzes path attributes to determine which route is installed as the best path in the BGP routing table. Each path carries well-known mandatory, well-know discretionary, and optional transitive attributes that are used in BGP best path analysis. Cisco IOS software provides the ability to influence BGP path selection by altering some of these attributes using the command-line interface (CLI.) BGP path selection can also be influenced through standard BGP policy configuration

BGP can be used to help manage complex internal networks by interfacing with Interior Gateway Protocols (IGPs). Internal BGP can help with issues such as scaling the existing IGPs to match the traffic demands while maintaining network efficiency

As regular visitors will know, I have been preparing for the written exam for over the past month or so. I have been making decent enough progress going through the CCBootcamp Voice Written Study Guide and also trawling through the Voice SRND’s and information on the Cisco documentation site. I was aiming to take the exam in a few weeks time, but am now having second thoughts about it.

While I have been studying for the written I started off putting in 2-3 hours a night of reading, this has now dropped off to 2-3 hours one or twice a week as I feel I have learned as much as I can. I am also finding myself getting bored of the content, maybe this is a sign that I am ready to take the exam. I am also thinking about the practical side of things, and while I do have a stack of Proctor Labs vRack vouchers, I just dont have the time to schedule in full 8 hour sessions after work and at the weekends to go through the workbooks. I also miss the CLI – I know that voice has a great deal of CLI configuration involved, but thats a way off down the line for where I am in my prep.

So, what does all this mean? Well, I may put the voice studies on hold for a while (I still want to do it), and look at SP instead. Since I passed the R&S I feel that I have zoned out a little on the more complex technologies and routing protocols that I dont work with on a day to day basis, such as BGP and VRF’s etc. Of course SP will have its own challenges, but I think that I am more suited to it at present and should be able to make good progress. I will also be able to do a lot of the workbooks on Dynamips, which appeals greatly to me – I will be able to do shorter sessions of 2-4 hours and then longer ones when required – plus I get to go deeper and build on my R&S knowledge.

Jared wrote a good post on the IPexpert blog about doing SP after R&S which makes sense to me. Im hoping that there isnt a major change in the next 6 months or so, but something tells me there may be seeing as Cisco are making changes to all the other tracks, so I will see how I get on.

I have not yet decided on the workbooks to use, but Rick recommends the INE Volume I and II, and also the IPexpert Volume II labs. I will decide on this once I get done with the written exam.

Does an OSFP stub explicitly filter Type-4 LSAs, or is their absence in an OSPF stub area simply due to being unnecessary because the Type-5 LSAs have been filtered?

Highlight for answer: Actually, I don’t know the answer to this question.  I was thinking about it today.  In an OSFP stub area Type-5 LSAs are explicitly filtered.  There are no Type-4 LSAs present either.  I don’t know if they are explicitly filtered, or they are just never generated because the Type 5 LSA is filtered/never created?  It’s my understanding (possibly a misunderstanding) that the ASBR generates the Type-4 LSA, so…it must be explicity filtered at the ABR, right? <–This is WRONG!

—-

Thank you for the comments (big ups to Ivan P, Zeeshan, and Pavel Sefanov).  I think that I have this cleared up in my head now:

The ABR generates the Type-4 LSA. If the area is configured as a stub area, the ABR filters the Type-5 LSAs(generated by the ASBR) and does not generate a Type-4 LSA. So, technically, an OSPF stub configuration only explicitly filters Type-5 LSAs, but it implicitly filters Type-4 LSAs as well as there is no need for the ABR to generate a Type-4 LSA.

So if you were to tell a co-worker that both Type-5 and Type-4 LSAs are filtered, you would be technically wrong. 

Ivan Pepelnjak from Cisco IOS Hints and Tricks wrapped it up nicely:

To make it more explicit: the type-4 LSA is the glue that ties together a type-5 LSA originated by an out-of-area ASBR with the ABR flooding type-5 into the area. If there are no type-5 LSAs, type-4 LSAs are not needed (you will also not see them for ASBRs in the same area).

What are the two tables that CEF utilizes to switch packets?

Highlight for answer: Forwarding Information Base(FIB) and [CEF] adjacency table.

What are the three tables that EIGRP uses?

Highlight for answer: EIGRP neighbor table, EIGRP topology table, and the IP routing table.

Which Spanning Tree convergence improvement utilizes Root Link Query (RLQ) BPDUs to detect indirect link failures?

Highlight for answer: BackboneFast

Which Cisco-supported PIM mode uses shared trees?

Highlight for answer: PIM Spare Mode (also PIM Sparse-Dense mode)

CCIE Journey recently attended Networkers in SF and has a nice recap of the event, particularly from a CCIE candidate’s perspective.  Definitely surf on over and give it a read.

There was a lot of speculation that the recent introduction of the Core Knowledge section to the CCIE lab was to curb cheating via leaked or brain-dumped labs.  A lot of that speculation centered around the Beijing, China lab location.  CCIE Journey’s post contains a nugget that may give validation to some of that speculation:

Monday was my eight hour lab day with a lab written by a proctor just for Cisco Live. We learned a lot in that class. We learned that the pass rate of the Beijing lab was running at 90% before they implemented the open-ended questions.

CCIE Journey shares my concern that we’re all now paying the price for possible rampant cheating at a specific location.  There is a possible bright side to this though:

He [the proctor] also hinted that the open-ended questions were a quick band aid for stopping the brain dumps and might come off in the near future. Maybe the troubleshooting section of the 4.0 lab will be enough?

I think that this makes sense.  Troubleshooting is a better filter than a four question quiz.  I tend to doubt that the Core Knowledge section will go away though.  The Core Knowledge questions are only ever used one time.  This means that they are essentially “un-dumpable”.  Of course, it also means that the questions may have the tendency to become more and more difficult as the obvious questions are used and discarded.

What are unsolicited messages sent from an SNMP agent to an SNMP management station called?

Highlight for answer:  SNMP traps.  SNMP informs fit this description as well.

What is the name of a well-known discretionary BGP attribute that is used to alert downstream routers that a loss of path information has occurred?

Highlight for answer: ATOMIC_AGGREGATE.

What is the practice of advertising a contiguous set of addresses with a single, less-specific address called?

Highlight for answer: Summarization or route aggregation

I received the following email today:

Dear Anonymous Blogger Jerk,

As you know, the CCIE Assessor Lab has been retired. As someone who has used or expressed interest in the Lab, we want to make you aware of a new program to replace the CCIE Assessor Lab. The CCIE Assessor was the first product of its kind to provide candidates with an experience similar to the actual CCIE lab exam. Our recently introduced Cisco 360 Learning Program for CCIE Routing and Switching now offers a complete experience in gaining expert level knowledge and preparing for the rigorous CCIE certification exams including classes, assessment labs and mentoring.

If you have not yet achieved your CCIE certification, you can use the Cisco 360 Learning Program to differentiate your skills and take your career to the next level with the only authorized Cisco expert training. The program is available individually or in value-priced bundles, Essentials, Preferred or Premium packages. Currently, 90% of students completing the Cisco 360 Learning Program successfully pass their R&S lab exam and achieve CCIE certification on their first try!

The Cisco 360 Learning Program is a comprehensive, blended learning program designed to accelerate expert-level competency. In as little as six months to one year, you will elevate your command of technical topics and develop the skills necessary to tackle the types of expert-level configuration and troubleshooting challenges that appear in real-life networks and in the recently updated CCIE lab exam. You can also purchase the program by individual components that can benefit someone with your familiarity of the CCIE materials and examinations.

If you are interested in learning more contact your local Cisco 360 Learning Partner and schedule a free demo of the Cisco 360 Learning Program.

The following resources are available for more information:
Cisco 360 Learning Program website
Solutions Overview
Locate a Cisco Learning Partner
Training Component Details

Best of luck on your networking career,
Learning@Cisco

Actually, I did not know that the CCIE Assessor Lab had been retired.  I used this product before my first attempt.  For $399.00 you received two mock labs.  Since this was Cisco’s official mock lab offering, I decided that it was a good investment of $400.  The labs were obviously getting long in the tooth even then as the first lab only used two switches.  While spendy, it was nice to get a look at the Cisco question verbiage and topology.

The death of the CCIE Assessor is part of the push to make the 360 program the single, official Cisco offering for CCIE training.  There was recently an announcement about the unbundling of the 360 program(something I’ll blog about later).  I think that it’s funny that the email bascially tells you that the 360 program – which can run into 5 figures – is the logical replacement for the CCIE Assessor Lab.  If there is an unbundled 360 mock lab product, then it would have made sense to point out that product. 

Kind of a side rant: The 90% pass on first attempt statistic is compelling, but what are the raw numbers?  90% of x?  If x is a low number (say 10) then that impressive percentage means less.  I would also think that given the high cost for the 360 program, that companies – and I have to believe that few individuals are footing this cost – that are willing to invest that type of cash into training are spending it on highly qualified engineers(there was a recent GroupStudy posting that showed evidence that this was the case).  BUT…as always, I could be wrong and the 360 may be the ultimate CCIE training program.  Maybe I’m just hating cuz I can’t afford it. 

The price I pay for procrastination.  I looked at the CCIE lab scheduler a couple of weeks ago and was surprised to see tons of open dates available before the new 4.0 lab kicks in on 18 October.  There were no dates outside of the 90 day “shit or get off the pot” cutoff, but plenty extending into September.

Today I checked again(I’ve been on a short family vacation for the last week) and there are very few remaining US dates left before the version change:

San Jose - 9 dates (latest is 14 July) and 20 seats left.
RTP – 5 dates (latest is 10 July) and 16 seats left.

Great.  Now I have to decide whether or not I will take another shot at the 3.0 lab or wait until October and try the 4.0 lab.  I have the money available, but getting time off from work will be difficult.  If I take the 4.0 lab I will need to learn the new technologies as well as face the troubleshooting portion of the lab.  If I take the 3.0 lab I won’t have much free time to devote to getting “fight ready”.  At least if I fail it I will still have half of the summer to drown in my sorrows. 

Cisco have announced that the short answer questions will be coming to the Voice lab on July 16th 2009, and I expect they will be added to all tracks which can only be a good thing. I know that some people dont like these, but anything that adds an extra dimension to the certification is OK by me. I think that Cisco is on the right track with all of the recent changes announced to the lab exam blueprints for R&S, Security and Voice.

https://cisco.hosted.jivesoftware.com/community/certifications/ccie_voice/lab_exam?view=overview

CCIE Voice Lab Exam Adding Short Answer Questions:

Also effective July 16, 2009, the Cisco CCIE Voice Lab Exam will feature a new type of question format in a section called Core Knowledge.  In this new section, candidates will be asked a series of four open-ended questions that require a short, typewritten response (typically several words).  The questions will be randomly drawn from a pool of questions on topics currently eligible for testing on the CCIE Voice Lab Exam.  No new topics are being added.  Candidates will have up to 30 minutes to complete the Core Knowledge section of the exam, and may not return to the questions later.  First introduced to the CCIE Routing and Switching lab exam in February 2009, Core Knowledge questions will eventually be added to all CCIE tracks.  The changes allow Cisco to maintain strong exam security, and they help ensure that only qualified candidates are awarded CCIE certification.

Mark at IPexpert has announced on OSL that they will be releasing a version of their flash based question simulation engine, so I am looking forward to checking it out. Im assuming they will follow the same pricing model for the R&S version on this – FREE!

I am currently making steady progress through the ccbootcamp study guide for the written, and will be following up soon with a breakdown of my progress so far. Im still on track to attempt the written exam in August.