Archive for August, 2008


Below is a link to a presentation from this year’s Defcon in regards to the inherent insecurity of BGP prefix advertisements on the Internet.  This is of course old news to most of us but still an interesting presentation.

Additionally there was another good presentation in regards to “Developments in Cisco IOS Forensics” that is an interesting read.

Tags: , , ,



Policy Change to Payment for CCIE Labs

In effort to improve the availability of CCIE lab exams Cisco has updated the CCIE lab payment process.

On September 6, 2008 the payment policy for CCIE labs will be as follows:

Payment in full is due 90 days (calendar) prior to your lab date. Payment must be received to confirm your date. After 90 days refunds will not be available for canceled lab dates.

The change in this policy will allow for lab seats to be open in a timely manner and create more desirable time frames.

If you have questions or want to confirm you are within the 90+ day window please contact customer support.


This is good news as it should open up more lab dates 90 days out as opposed to 30 days out.


I ran across this email on a mailing list today in regards to Cisco interviewing candidates before allowing them to take the exam.  It’s unconfirmed as to it’s authenticity but there have been stories of problems with certain CCIE lab locations (e.g. someone taking the lab for 4 or 5 other people, someone else with a very good memory but no Cisco networking skills taking the exam to just brain dump it, etc).

Dear Candidate:

On August 27, Cisco will introduce a pilot for the CCIE Routing and
Switching lab exam in Beijing, China. The pilot will add a 10-minute
interview that will assess the candidate's ability to apply expert-level
networking skills and knowledge to networking problems that are encountered
on the job. After the lab orientation, a panel of three experts will conduct
a verbal interview with each candidate, asking a series of expert-level
networking questions (questions and answers will be in English). The ability
to correctly answer these questions will affect the exam score. After
completing the interview, the candidate will have the entire 8 hours to
complete the lab portion of the exam.  These scores will then be
calculated and then combined for a total score which will decide a pass
or a fail.

Our goal with this email is to let you know that your day will extend beyond
the normal testing day by approximately one hour.  The additional hour will
be at the end of the day. We hope you find this interview process
enlightening and helpful as we continue to strive for the standard the world
has come to expect from CCIE.

Today my routers finally passed the point of no return. Negotiations between R4 and SW4 broke down, and the course of action we were all trying to avoid was now inevitable… all out war.

%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID type-5 adv-rtr in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID type-5 adv-rtr in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID type-5 adv-rtr in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID type-5 adv-rtr in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID type-5 adv-rtr in area 0
%OSPF-4-FLOOD_WAR: Process 1 re-originates LSA ID type-5 adv-rtr in area 0

Who will be the winner? Only time will tell. What sent them over the edge though? Did the diplomat in charge of DTP negotiation fail?

Be the first person to tell me why R4 and SW4 declared all out WAR on each other and win a $50 amazon gift card! Post your comments now!


Congratulations to Patrik Berglund, winner of a $50 amazon gift card!

R4 and SW4 declared war on each other because they had duplicate OSPF Router-IDs. When R4 redistributed routes into OSPF, it generated LSA Type-5 routes tagged with its own Router-ID, Per RFC 2328, OSPFv2:

    13.4.  Receiving self-originated LSAs

        It is a common occurrence for a router to receive self-
        originated LSAs via the flooding procedure. A self-originated
        LSA is detected when either 1) the LSA's Advertising Router is
        equal to the router's own Router ID or 2) the LSA is a network-
        LSA and its Link State ID is equal to one of the router's own IP
        interface addresses.

        However, if the received self-originated LSA is newer than the
        last instance that the router actually originated, the router
        must take special action.  The reception of such an LSA
        indicates that there are LSAs in the routing domain that were
        originated by the router before the last time it was restarted.
        In most cases, the router must then advance the LSA's LS
        sequence number one past the received LS sequence number, and
        originate a new instance of the LSA.

        It may be the case the router no longer wishes to originate the
        received LSA. Possible examples include: 1) the LSA is a
        summary-LSA or AS-external-LSA and the router no longer has an
        (advertisable) route to the destination, 2) the LSA is a
        network-LSA but the router is no longer Designated Router for
        the network or 3) the LSA is a network-LSA whose Link State ID
        is one of the router's own IP interface addresses but whose
        Advertising Router is not equal to the router's own Router ID
        (this latter case should be rare, and it indicates that the
        router's Router ID has changed since originating the LSA).  In
        all these cases, instead of updating the LSA, the LSA should be
        flushed from the routing domain by incrementing the received
        LSA's LS age to MaxAge and reflooding (see Section 14.1).

In this case, SW4 received an external LSA with its own Router-ID ( as the originator ID. Since SW4 didn’t have a route to the destination that it was originating, it thought that it had previously originated the route, lost the route to the destination, and now received an old LSA which was aging out throughout the topology. In response to this SW4 incremented the age of the LSA to MaxAge, effectively poisoning it. When R4 received this back, it thought that its own LSA was somehow aged out, but since it had a route to the destination itself locally still it re-originated the LSA again. The fight between the legitimate route and the MaxAge route continues over and over, resulting in the FLOOD_WAR message on the command line.

For more detailed information and lab scenarios like this check out the new IEWB-RS Volume 1 Version 5.0!


There is an interesting article regarding CCIEs on   Here is an excerpt from it:

Leading indicators are measurements that change over time and suggest future trends for important second-order results like population growth and economic development. Economists in particular are often looking for indicators that have been known historically to lead the overall economy. If unemployment goes down, for example, it is a good bet that shortly thereafter income will rise and the economy will improve. It’s for this very reason, then, that economists and Wall Street fund managers are always looking for newer and better leading indicators. But such indicators needn’t be limited to the economy: they can apply to technology and technical culture, too, which has its own feedback loop to economic development. My friend George Morton, who figured this all out, says that by knowing the right numbers to look at we can have a good idea what countries will be leading in technology — and presumably in economic development and power — in the years ahead. The measure George likes is the number of Cisco Certified Internetwork Experts or CCIEs.

You can read the rest of the article at:


Note: The following post is an excerpt from the full QoS section of IEWB-RS VOL1 version 5.

Peak shaping may look confusing at first sight; however, its function becomes clear once you think of oversubscription. As we discussed before, oversubscription means selling customers more bandwidth than a network can supply, hoping that not all connections would use their maximum sending rate at the same time. With oversubscription, traffic contract usually specifies three parameters: PIR, CIR and Tc – peak rate, committed rate and averaging time interval for rate measurements. The SP allows customers to send traffic at rates up to PIR, but only guarantees CIR rate in case of network congestion. Inside the network SP uses any of the max-min scheduling procedures to implement bandwidth sharing in such manner that oversubscribed traffic has lower preference than conforming traffic. Additionally, the SP generally assumes that customers respond to notifications of traffic congestion in the network (either explicit, such as FECN/BECN/TCP ECN or implicit such as packet drops in TCP) by slowing down sending rate.

Continue Reading

Tags: , , , , ,


From Cisco:


CCIE labs changing from UniversCD to Cisco Documentation

On Sept 24 2008 CCIE labs will no longer support using the UniversCD documentation for the lab exam.

All labs are migrating to Cisco Documentation only. For those scheduled to take the CCIE lab prior to Sept 24 access will still be available for UniversCD.

The Cisco Documentation pages have the same information that currently resides on UniversCD, please refer to the links on the CCIE web pages to view these pages and become familiar with the new format.

After Sept 24 2008 only the Cisco Documentation web pages will be available for CCIE labs.


So what does this mean for people taking the lab after Sept 24th?  It means you will still have access to everything needed in relation to the documentation but you will need to access it using the link below:


A large portion of the OSPF section from the new IEWB-RS Volume 1 Version 5.0 has been posted on the members site.  This section is still “alpha” because it’s only about 1/3rd of the total content, but I wanted to get something posted due to the large number of requests from eager candidates I’m getting :)   The sections posted so far are complete, the alpha designation just means that there is much more to come later.

Please post all questions and comments on under the CCIE R&S Lab Workbook Volume I Version 5.0 forum.

Happy Labbing!



Cisco is now soliciting beta candidates for Cisco’s upcoming CCIE Wireless Written Exam. We are looking for an exclusive set of professional and expert level Wireless Networking Engineers who can dedicate 3 hours of their time to take the beta exam.

The CCIE Wireless certification, to be launched later this year, will validate that professionals have the expertise to design, manage and support mission and business critical wireless networks and the job skills and technical knowledge required of expert level network IT practitioners. This written exam is the first step in obtaining the CCIE Wireless certification. Successful candidates will have mastered broad theoretical knowledge of wireless networking and demonstrated a readiness for the CCIE Wireless lab examination. Be one of the first wireless professionals to get a peek at the new CCIE Wireless exam.

  • Location: Pearson Vue Testing Centers, Worldwide
  • Registration Date: October 7
  • Last Test Date: November 14, 2008
  • Cost: $US50
  • Exam Number/Name: 351-050 CCIE Wireless Beta Written Exam



Try assessing your understanding of Cisco’s CBWFQ by looking at the following example:

class-map match-all HTTP_R6
 match access-group name HTTP_R6
policy-map CBWFQ
 class HTTP_R6
  bandwidth remaining percent 5
interface Serial 0/1
  bandwidth 128
  clock rate 128000
  service-policy output CBWFQ

and answering a question on the imaginable scenario: Two TCP flows (think of them as HTTP file transfers) are going across Serial 0/1 interface. One of the flows matches the class HTTP_R6, and another flow, marked with IP Precedence of 7 (pretty high), does not match any class. The traffic flow overwhelms the interface, so the system engages CBWFQ. Now the question is: how CBWFQ will share the interface bandwidth among the flows.

Continue Reading

Tags: , , , , ,


CCIE Bloggers