Q. When doe this course start?

A. Thursday, June 7, 2012, 8:00 – 10:30 PM EDT

Q. Who should attend this course?

A. This course assumes the student has already been through at least one practice lab on their own and that they are at least familiar with the technologies on the CCIE Voice Lab blueprint.

Q. What is the basis for the course content?

A. This live on-line boot camp walks the student through a new mock lab (that Kevin Wallace created) over a series of eight sessions.

Q. What distinguishes this boot camp from a tradition boot camp?

A. The biggest difference (huge!) is its focus on lab strategy. There are 12 strategies outlined in what Kevin Wallace calls his “CCIE Voice Alchemy” process, which helps the student “turn their lab day into gold.” This boot camp demonstrates these 12 strategies while working through the new mock lab (in a non-linear fashion).

Q. What is the goal of this bootcamp?

A. The goal is for the student to complete this boot camp with a much deeper understanding of the technologies on the lab, and (maybe even more importantly) have a set of strategies that they can use on lab day to make the most effective use of their time.

Q. Who is this Kevin Wallace guy?

A. Kevin Wallace is a CCIE R&S and Voice. With Cisco experience dating back to 1989 (on a Cisco AGS+ router running Cisco IOS 7.x), Kevin has been a network design specialist for the Walt Disney World Resort, a Senior Technical Instructor for SkillSoft, and a network manager for Eastern Kentucky University. Kevin holds a bachelor’s of science degree in electrical engineering (focusing on digital communications) from the University of Kentucky, and has also authored or co-authored multiple books for Cisco Press, including: Voice over IP First-Step,Cvoice Foundation Learning Guide, TSHOOT Cert Kit, TSHOOT Official Certification Guide, and ROUTE Cert Kit. Kevin’s website is1ExamAMonth.com.

Print Friendly

What products are likely to be tested in this revision of the popular written and lab exams? Most believe the following:

• Cisco IPS 4200 Series
• IronPort Web Security Appliances (WSA)
• Cisco Identity Services Engine (ISE)
• Cisco ASA Firewall

Of course we will continue to closely monitor the news here at blog.ipexpert.com and will post details the moment they are announced.

Print Friendly

As you know, policing sets a “speed limit” for traffic that is entering or exiting the Catalyst switch. Traffic that is not exceeding the speed limit is termed the conforming traffic. Traffic that is exceeding the speed limit is termed the exceeding traffic.

Thanks to flexibility in policing configurations on the Catalyst switch, packets can be:

• Transmitted
• Dropped
• Transmitted and Remarked

Remember, on a Catalyst switch, these options are configurable at the switch port level, or the VLAN level.

When configuring traffic policing at the switch port, this QoS treatment can be based on a single class of traffic, or multiple classes of traffic. In the case of multiple traffic classes, this QoS tool is officially termed an aggregate policer.

Here is an example of policing based on a single class of traffic:

CAT2#
CAT2#configure terminal
CAT2(config)#access-list 100 permit udp any any range 16384 32767
CAT2(config)#class-map CM_VOICE
CAT2(config-cmap)#match access-group 100
CAT2(config-cmap)#exit
CAT2(config)#policy-map PM_POLICE
CAT2(config-pmap)#class CM_VOICE
CAT2(config-pmap-c)#police 512000 8000 exceed-action drop
CAT2(config-pmap-c)#exit
CAT2(config-pmap)#exit
CAT2(config)#interface fa0/10
CAT2(config-if)#service-policy input PM_POLICE
CAT2(config-if)#end
CAT2#

Notice that this configuration polices Voice traffic to a rate of 512 Kbps. It uses a burst size of 8000 bytes, and drops traffic that is in excess of this rate. This policer is a applied to the  Fa0/10 port in the inbound direction.

Note: When entering QoS configurations, always consider using context sensitive help (?) in order to confirm the measurement value (for example, bits versus bytes). Notice with the example above, the policer on the Catalyst switch defaults to bits per second.

In the case of aggregate policer, you create an aggregate policing rule – this is accomplished with the following global configuration command:

mls qos aggregate-police

This command specifies the rate and the burst value, as well as the policing action.

Under policy-map class configuration mode, you reference the aggregate policing rule that you created using the following command:

police aggregate

But again, a huge area of confusion and erroneos configuration regards the SVI configuration of policing. Here are the main points to keep in mind:

• The configuration requires a nested policy map
• The policy map applied to the SVI references another policy map that actually does the policing
• Do not forget to enable vlan-based QoS on the appropriate range of ports
• In the parent policy map, you must perform some action (besides calling another policy map)

In order to configure policing on a Switched Virtual Interface (SVI or VLAN interface), here is a sample configuration:

CAT2(config)#int range fa0/1 – 5
CAT2(config-if-range)#mls qos vlan-based
CAT2(config-if-range)#exit
CAT2(config)#access-list 100 permit udp any any range 16384 32767
CAT2(config)#class-map RTP
CAT2(config-cmap)#match access-group 100
CAT2(config-cmap)#exit
CAT2(config)#class-map PORTS
CAT2(config-cmap)#match input-interface fa0/1 - fa0/5
CAT2(config-cmap)#exit
CAT2(config)#policy-map PORT
CAT2(config-pmap)#class PORTS
CAT2(config-pmap-c)#police 256000 8000 exceed-action drop
CAT2(config-pmap-c)#exit
CAT2(config-pmap)#exit
CAT2(config)#policy-map VLAN
CAT2(config-pmap)#class RTP
CAT2(config-pmap-c)#set dscp 46
CAT2(config-pmap-c)#service-policy PORT
CAT2(config-pmap-c)#exit
CAT2(config-pmap)#exit
CAT2(config)#int vlan 100
CAT2(config-if)#service-policy input VLAN
CAT2(config-if)#end
CAT2#

Notice how we set the DSCP value in the parent policy map in order to meet the requirement of “performing some action!” Also remember, both of the sample configurations above require mls qos configured globally on the device.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

Date and Time - Tuesday, May 29, 2012, 8:00 PM EST USA

Format - Live Online WebEx Training Center

Class Recording – Available immediately following the event

Extras – Daily (M-F) email challenges; 24×7 mentor support

Topics – Evening 1 topics

• The Quick-Fire Ticket Management Strategy
• The Quick-Fire Time Management Strategy
• Quick-Fire Layer 2 Strategies

Print Friendly

First, the basics – let us configure basic RIP version 2 on the Cisco ASA:

ASA1# configure terminal
ASA1(config)# router rip
ASA1(config-router)# version 2
ASA1(config-router)# no auto-summary
ASA1(config-router)# network 10.0.0.0
ASA1(config-router)# passive-interface default
ASA1(config-router)# no passive-interface Inside
ASA1(config-router)# end
ASA1#

Notice this “best practices” configuration is just like how I would configure RIP on the router. The passive-interface default bit and then the no passive bit ensures that we are only sending updates out the interface that we want speaking RIP. There is still no method of configuring RIP under an interface on the ASA or a Cisco router.

Now it is time for some verification. First – the routing table.

ASA1# show 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

C    192.1.24.0 255.255.255.0 is directly connected, Outside
R    10.1.1.0 255.255.255.0 [120/1] via 10.2.2.5, 0:00:01, Inside
C    10.2.2.0 255.255.255.0 is directly connected, Inside
C    10.7.7.0 255.255.255.0 is directly connected, DMZ7
C    10.8.8.0 255.255.255.0 is directly connected, DMZ8
ASA1#

Notice that if you need to get a bit more involved troubleshooting either the sending or receiving of updates, you can use debug rip events:

ASA1# debug rip events
RIP event debugging is on
ASA1#
RIP: received v2 update from 10.2.2.5 on Inside
     10.1.1.0255.255.255.0 via 0.0.0.0 in 1 hops
RIP: Update contains 1 routes
RIP: sending v2 update to 224.0.0.9 via Inside (10.2.2.10)
RIP: build update entries
        10.7.7.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0
        10.8.8.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0
RIP: Update contains 2 routes
RIP: Update queued
RIP: Update sent via Inside rip-len:52
ASA1#

In order to configure authentication for RIP on the ASA, simply enact the following:

ASA1# configure terminal
ASA1(config)# interface e0/1
ASA1(config-if)# rip authentication mode md5
ASA1(config-if)# rip authentication key ipexpert key_id 1
ASA1(config-if)# end
ASA1#

Verification can be obtained from debug rip events which show we are now ignoring updates that are not properly configured for authentication:

ASA1#
RIP: ignored v2 packet from 10.2.2.5 (invalid authentication)
ASA1#

Should you want to inject a default route into RIP from the ASA, this is also simple:

ASA1# configure terminal
ASA1(config)# router rip
ASA1(config-router)# default-information originate
ASA1(config-router)# end
ASA1#

Verification is once again debug rip events:

ASA1#
RIP: sending v2 update to 224.0.0.9 via Inside (10.2.2.10)
RIP: build update entries
        0.0.0.0 0.0.0.0 via 0.0.0.0, metric 1, tag 0
        10.7.7.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0
        10.8.8.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0
RIP: Update contains 3 routes
RIP: Update queued
RIP: Update sent via Inside rip-len:112

Other features to be aware of with RIP:

• Filtering RIP updates – this is possible for inbound and outbound RIP routes using a distribute-list tied to an ACL
• Controlling the sending and receiving RIP version – this is done with the  rip send version and rip receive version interface-level commands

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

This update will fix some cosmetic issues, correct some grammar problems that slipped by our editors, and will also add some content in spots to help improve clarity of the text.

Thanks so much for all of the amazing feedback regarding this book series at IPexpert.com. We will keep writing as long as you keep reading! :-)

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

• P.K.S.Dimuthurathna CCIE #35377 (Voice)
• Samir Idris CCIE #35202 (R&S)
• Baktha Muralidharan CCIE #35370 (Voice)
• Lloyd Johnson CCIE #35384 (Voice)
• Idan Nachmani, CCIE #35369 (R&S)
• Piotr Tokarzewski CCIE # 35406 (Sec)

Baktha Muralidharan CCIE #35370
“CCIE Voice, in addition to exacting proficiency in the various voice technologies, is the ultimate test of one’s ability to pay attention to details. I had always been a “concept” person and details were never my forte. IPexpert’s training helped address just that. Squarely! Through their CCIE Voice bootcamps and lab exercises, they consistently drove me to be mindful of details such that it eventually helped tide me over. But IPexpert went beyond detail-training, as it provided a comprehensive tutorial on the associated concepts as well as troubleshooting tips. I recommend their training even to those who are not CCIE-bound, as it will help strengthen on voice skills.”

P.K.S.Dimuthurathna CCIE # 35377 (Voice)
“I am very happy to say I could pass my CCIE Voice few days back in Brussels. Online Study List discussions (OSL) & Proctor Labs remote Racks were helpful for my Journey. I used Gradedlabs & my own equipment before , but later I found Proctor Labs has the most correct Topology for CCIE Voice Track. During last few months, I solely used Proctor Labs sessions for my preparation. Support guys like James Dull did a good Job.

OSL discussions were very helpful when I faced problems. Specially Vik Malhi’s contribution to the list are very significant.

Needless to say CCIE Voice is an extremely difficult path. Somehow finally after 2 years of struggle with lot of sacrifices, it could be done.”

Lloyd Johnson CCIE #35384
“I did not know where to start to obtain my CCIE Voice certification. After doing a some online research and speaking to another CCIE I booked an IPexpert CCIE Voice bootcamp. I was so impressed with Vic’s lecture that  I purchased IPexperts CCIE Voice Blended Learning Solution to re-enforce what I had learned at the bootcamp. Using the Proctor labs 3 site remote equipment  and my own 5 7965 phones with a 871 VPN router I was able to perform all lab tasks provided by IPexpert.  The IPexpert labs are well written and the solution guides are very detailed and easy to understand. I returned to IPexperts one week lab experience to work on mock exam labs and ask those last few questions that Vic was always able to provide a answer that I was able to understand.

I recommend starting with the blended learning solutions followed up with IPexperts bootcamps. You will not be disappointed. Thanks again Vik and the rest of the staff at IPexpert and Proctor Labs.”

IPexpert is proud to boast the industry’s most complete and updated self-study portfolio for the CCIE Routing & Switching, CCIE Voice, CCIE Security, and CCIE Wireless Lab exams. Have you also used IPexpert or Proctor Labs to help you pass the CCIE lab exam? If so, we want to hear your story! Please email us at success@ipexpert.com.

Print Friendly

In the Packet Pushers Podcast episode 89 (OSPF vs IS-IS Smackdown – Where You Can Watch Their Eyes Reload) published few months ago, I made few statements about border routers in both OSPF and IS-IS and their differences. This prompted some disagreement on the panel consisting of Ivan Pepelnjak of NIL, Petr Lapukhov of Microsoft, host Greg Ferro and myself. In this post, I’ll examine OSPF issues and follow-up with IS-IS in the next.

For the purpose of this testing, I will use the network of three routers connected in a “chain”. I will not change this network layout, only the configuration of the routing protocols, as required. Even though both IOS and Juniper configurations are completed in production ProctorLabs racks, I gave routers fictional names to avoid slight router numbering differences between our Cisco and Juniper racks.

Lab time!

One of the statements I made about OSPF was that OSPF router connected to two areas will not act as an ABR, i.e. the “B” bit in its type 1 LSA will not be set unless one of the areas is the backbone area 0.0.0.0. Petr mentioned it might be a Cisco specific behavior and given my recent Junos interest this was a perfect thing to test. The problem basically, boils down to how different vendors implement RFC3509.

OSPF Border in IOS

Here are the relevant initial configurations for our three Cisco routers. To make configurations as similar to the subswquent Juniper configurations, I will use subinterfaces in IOS. There is no other reason to do it.

R1:

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/1
 no shutdown
!
interface FastEthernet0/1.12
 encapsulation dot1q 12
 ip address 192.168.12.1 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 router-id 1.1.1.1
 passive-interface Loopback0
 network 1.1.1.1 0.0.0.0 area 12
 network 192.168.12.0 0.0.0.255 area 12
!

R2:

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/1
 no shutdown
!
interface FastEthernet0/1.12
 encapsulation dot1q 12
 ip address 192.168.12.2 255.255.255.0
 ip ospf network point-to-point
!
interface FastEthernet0/1.23
 encapsulation dot1q 23
 ip address 192.168.23.2 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 router-id 2.2.2.2
 network 192.168.12.0 0.0.0.255 area 12
 network 192.168.23.0 0.0.0.255 area 23
!

R3:

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/1
 no shutdown
!
interface FastEthernet0/1.23
 encapsulation dot1q 23
 ip address 192.168.23.3 255.255.255.0
 ip ospf network point-to-point
!
router ospf 1
 router-id 3.3.3.3
 passive-interface Loopback0
 network 3.3.3.3 0.0.0.0 area 23
 network 192.168.23.0 0.0.0.255 area 23
!

As we can see, routers R1 and R2 are neighbors in area 12, and routers R2 and R3 are neighbors in area 23. Does this make R2 and ABR? The discussion in the podcast revolved around Cisco-specific behavior in this case. Let’s check what R2 thinks about its situation.

Information whether a router is an ABR is carried in Router (Type 1) LSA as a “B” bit. If this bit is set to 1, router is an ABR. IOS will translate this bit into a helpful “Area Border Router” message. So, to get this information, I will have to check the OSPF database and read Router LSAs originated by R2. Since R2 will have both area 12 and area 23 databases even if it’s not an ABR, I will truncate the output for the sake of brevity.

R2:

R2#show ip ospf database router self-originate

            OSPF Router with ID (2.2.2.2) (Process ID 1)

		Router Link States (Area 12)

  LS age: 663
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0x53CD
  Length: 48
  Number of Links: 2

[...]

		Router Link States (Area 23)

  LS age: 646
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0xFF3
  Length: 48
  Number of Links: 2

[...]

In the output above, there is no trace of the “B” bit being set. As further proof of this, let’s see if the route for 192.168.23.0/24 can be seen in the routing table on R1. If R2 was an ABR, we’d see this route.

R1:

R1#show ip route 192.168.23.0
% Network not in table

This is what I expected to see. It’s clear that IOS doesn’t consider R2 to be an ABR. This is a very important concept to remember when preparing for your CCIE, as at first glance it appears that R2 is an ABR. At this moment, we don’t have reachability between networks advertised by R1 and R3. How can we repair this situation? We will need to make R2 and ABR. In Cisco IOS, ABR is the router that has interfaces in area 0.0.0.0 and one or more other areas. Remedy of the situation is therefore rather simple. We’ll advertise R2′s Loopback0 into OSPF area 0 and see if that changes anything.

R2:

router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
!

R1:

R1#show ip route 192.168.23.0
Routing entry for 192.168.23.0/24
  Known via "ospf 1", distance 110, metric 2, type inter area
  Last update from 192.168.12.2 on FastEthernet0/1.12, 00:38:38 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 2.2.2.2, 00:38:38 ago, via FastEthernet0/1.12
      Route metric is 2, traffic share count is 1

R1#show ip route ospf
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/2] via 192.168.12.2, 00:38:44, FastEthernet0/1.12
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/3] via 192.168.12.2, 00:38:44, FastEthernet0/1.12
O IA 192.168.23.0/24 [110/2] via 192.168.12.2, 00:38:44, FastEthernet0/1.12

We now have the OSPF routes on R1. As a final confirmation of my position, let’s take a look at R2′s OSPF database. I will truncate it again, as I’m interested only in LSA headers.

R2:

R2#show ip ospf database router self-originate

            OSPF Router with ID (2.2.2.2) (Process ID 1)

		Router Link States (Area 0)

  LS age: 377
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0xA770
  Length: 36
  Area Border Router
  Number of Links: 1

[...]

		Router Link States (Area 12)

  LS age: 377
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000004
  Checksum: 0x52CB
  Length: 48
  Area Border Router
  Number of Links: 2

[...]

		Router Link States (Area 23)

  LS age: 379
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000004
  Checksum: 0xEF1
  Length: 48
  Area Border Router
  Number of Links: 2

[...]

Clearly, just adding one interface into area 0 caused R2 to behave as an ABR. I wonder, how will Junos act in the same situation?

OSPF Border in Junos

Here are the relevant configurations from our Juniper routers. I have tried to replicate the configuration as much as I could. Since all logical configuration on Junos must be done on logical link units, including loopback (lo0) interface, some differences still exist. They are minor though.

R1:

interfaces {
    fe-0/0/1 {
        vlan-tagging;
        unit 12 {
            vlan-id 12;
            family inet {
                address 192.168.12.1/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 1.1.1.1/32;
            }
        }
    }
}
routing-options {
    router-id 1.1.1.1;
}
protocols {
    ospf {
        area 0.0.0.12 {
            interface fe-0/0/1.12 {
                interface-type p2p;
            }
            interface lo0.0 {
                passive;
            }
        }
    }
}

R2:

interfaces {
    fe-0/0/1 {
        vlan-tagging;
        unit 12 {
            vlan-id 12;
            family inet {
                address 192.168.12.2/24;
            }
        }
        unit 23 {
            vlan-id 23;
            family inet {
                address 192.168.23.2/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 2.2.2.2/32;
            }
        }
    }
}
routing-options {
    router-id 2.2.2.2;
}
protocols {
    ospf {
        area 0.0.0.12 {
            interface fe-0/0/1.12 {
                interface-type p2p;
            }
        }
        area 0.0.0.23 {
            interface fe-0/0/1.23 {
                interface-type p2p;
            }
        }
    }
}

R3:

interfaces {
    fe-0/0/1 {
        vlan-tagging;
        unit 23 {
            vlan-id 23;
            family inet {
                address 192.168.23.3/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 3.3.3.3/32;
            }
        }
    }
}
routing-options {
    router-id 3.3.3.3;
}
protocols {
    ospf {
        area 0.0.0.23 {
            interface fe-0/0/1.23 {
                interface-type p2p;
            }
            interface lo0.0 {
                passive;
            }
        }
    }
}

Let’s start the verification by looking for OSPF routes on R1.

R1:

ipexpert@R1> show route protocol ospf

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

3.3.3.3/32         *[OSPF/10] 01:18:39, metric 2
                    > to 192.168.12.2 via fe-0/0/1.12
192.168.23.0/24    *[OSPF/10] 01:26:19, metric 2
                    > to 192.168.12.2 via fe-0/0/1.12
224.0.0.5/32       *[OSPF/10] 01:26:43, metric 1
                      MultiRecv

That came almost unexpected. All the routes are there. I can see both R3′s link to R2 and the loopback interface. I can even ping…

R1:

ipexpert@R1> ping rapid 3.3.3.3
PING 3.3.3.3 (3.3.3.3): 56 data bytes
!!!!!
--- 3.3.3.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.509/1.999/2.544/0.349 ms

It looks like R2 is performing ABR duties even without having any interfaces in the backbone area. Let’s confirm that by looking into the OSPF database.

Unlike IOS, Junos is a little bit more cryptic about ABR status by virtue of not converting bit values into mnemonics. We’ll have to decipher VEB bit-field manually. The bit we’re after, the B-bit has bit-value of 1. Let’s take a look.

R2:

ipexpert@R2> show ospf database router advertising-router self area 12 detail

    OSPF database, Area 0.0.0.12
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *2.2.2.2          2.2.2.2          0x80000005  1145  0x22 0x50cc  48
  bits 0x1, link count 2
  id 1.1.1.1, data 192.168.12.2, Type PointToPoint (1)
    Topology count: 0, Default metric: 1
  id 192.168.12.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 1
  Topology default (ID 0)
    Type: PointToPoint, Node ID: 1.1.1.1
      Metric: 1, Bidirectional

Indeed, bit-field shows value 0×01, which translates into B-bit being set. R2 is an ABR! Therefore, in Junos there is no need for a router to be connected to the backbone area to perform ABR duties (generate Type 3 summary LSAs between areas).

This is still a broken configuration. It only has an appearance of being fully operational, but adding a single interface in area 0 on either R1 or R3 would render those networks unreachable beyond quasi-ABR R2. I will leave this for another time though…

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List

Print Friendly

Honestly, that question presupposes a number of variables that have to be clarified first. It automatically assumes that the test taker has a solid foundation in the technologies and protocols being tested, it also assumes that ample time has been taken to practice and build speed at the console and at least develop some rudimentary deployment and resolution strategies. That being said my answer is absolutely!

I honestly think the Quick-Fire method made all the difference. In both labs that I took, I was working on trouble tickets up till the last few minutes. The approach helped me stay calm with all the pressure, plus it kept me focused on what was really important; securing points. Honestly, there wasn’t a question asked that any well prepared student could not have answered given enough time; the issue was the clock. The time goes so fast and even a few minutes of wasted time on each ticket can mean the difference between passing and failing. In both attempts, there where tickets that I solved almost immediately and then some I resolved in the last few moments (the ones I considered very hard) before the final verification. The Quick-Fire method is designed to optimize time while maximizing the chances at getting the most correct tickets before it runs out. In both actual lab attempts where we tested Quick-Fire, the tickets ranged from easy to what I considered extremely hard and some contained multiple errors. The Quick-Fire process helped me gather all the “low hanging fruit” quickly and efficiently, and bought me the time necessary to really focus on the harder tickets.

Talking to candidates before the exam, as we waited outside the testing center, I was surprised to hear how many students where coming back after failing the Troubleshooting section. Among the exam “re-takers” the most common complaint was how fast the time runs out, and none of them had passed the Troubleshooting section twice in a row. Therefore, as far as I am concerned, I do not think I would have passed the exam and obtained my digits without Quick-Fire.

The next question is, “What makes Quick-Fire so special?”

I love to answer this one. Quick-Fire is special because it was created from the ground up to help a candidate clear the troubleshooting section. We took input from as many field experienced CCIEs as we could find, regarding their fault isolation approach strategies and their knowledge of common issues affecting tested protocols and we then took all this information and distilled it down to the most streamline process we could envision. The benefit of this process can be best be seen by taking a quick look at a portion of the Quick-Fire approach for a common exam topic like Zone Based Firewall (ZBF):

Zone Based Firewall – Fault Isolation Quick-Fire (excerpt)

1. Check that all interface status are up/up (none should be administratively down)

a)      Verify correct ip address/mask (per drawing)

2. Check if dynamic routing protocol is enabled or if static routing is defined between inside and outside devices.

3. Check the Zone Base Policy:

a)      Verify match protocol, and match-all verses match-any in class-maps.

b)      Verify zone membership of appropriate interfaces

c)      Verify configuration of the policy-map(s)

d)      Verify direction of service policies configured

4. Look for ACL restrictions or other types of filters

This is just a snapshot from the many processes that make up Quick-Fire, but that is not what makes Quick-Fire special. The most valuable and unique aspect of Quick-Fire is the testing and validation that has gone into the process. We have expended literally hundreds of hours testing against every Troubleshooting lab available to us. That means that we have used it against all the grey market vendors’ materials as well as the official Cisco 360 track, not to mention the actual CCIE lab exam (twice!!!) and it performed magnificently!

Personally, it was so nice to take on the Configuration section of the exam knowing I had the Troubleshooting section in the bag. That confidence made me feel unstoppable!

Terry Vinson
CCIE #35347 (R&S)

Print Friendly