Posted by: Mar Apuhin | March 8, 2010

Internetwork Expert’s R&S Lab Workbook Volume IV Logs – Lab 3 of 10

11:01 AM 3/7/2010 HKT

LAB 3 VOLUME 4 Notes:

Ticket 1 – RIPv2

• Fix the issue preventing R6 from learning RIPv2 prefixes from BB1.
• Do not change the IP addressing on R6 to resolve this problem.

-Know the scope of the problem.
-Check RIP running config first. Check interfaces running RIP.
-Check interface status up/down
-Check Layer 2 parameters, do ping test.
-PPP can be stuck in LCP exchange, check any authetication issue.
-This ticket is not directly related RIP but rather related to L2 PPP issue on the Serial link running RIP.
-Enable logging console and logging buffered

debug ppp negotiation – Look for “Authentication Failure” for hints.
show ip protocols
show ip route rip
show interface x/x
show frame-relay pvc yyy
show interface virtual-access x | i PPP|packets

Ticket 2 – BGP Peering

• The BGP session between R6 and SW2 is not coming up for some
reason.
• Find what might be causing this and fix the problem applying minimal
changes.

-BGP check – Remember BGP is a layer 4
-Underlying issue maybe related to switch trunking or any layer2 issue.
-Make sure the layer 2 is intact.
-Mark all access and trunk links.
-If using DTP (no switchport noneg) make sure VTP names and password are consistent, else trunks using DTP will not come up.
-Checking of logs is very critical, make sure to familiarized log checking.
-This case is not directly related to any BGP process or layer 4 issue, but rather some layer 2 trunking issue.
-Check BGP decent running config.

show spanntree vlan xxx
show interface fx/x switchport | i Mode
show vtp status
show ip bgp summary.

Ticket 3 – Backup Link

• Users on VLAN42 report terrible performance when connecting the
servers on VLAN5.
• You suspect that the problem is that packets are taking suboptimal path across the backup ISDN link between the two sites.
• Restore optimal performance and ensure the primary path over Frame-Relay cloud is being used.

-This setup is a dual link via Serial p2p and Serial frame-relay ckt.
-FR is down. Check for FR configuration, proper DLCI assignment.
-Check EEK.
-Check OSPF neighbor
-EEK is applied via a map-class, make sure it is consisted on both ends.

debug interface xx
debug ip ospf adj
show ip protocols
show interface xx | i LMI
show frame pvc xxx | s UNUSED
show frame-relay pvc | i DELETED

Ticket 4 – Network Optimization

This ticket requires Tickets 1 and 2 resolved prior to starting.
• After a recent merge process, some networks have been joined together.
• In order to provide end-to-end connectivity, mutual redistribution has been configured between RIP and OSPF on R1, R2, R3, R4 and SW1.
• However, the straight-forward configuration approach resulted in network instabilities and sub-optimal routing.
• Fix the network configuration to ensure optimal routing, which means
using high-speed links (Ethernet and Frame-Relay) for primary data paths.
• The routers behind R5 should receive a single default route to reach the rest of the network.
• R4 may still use the Serial link to reach the networks behind R5.

-Redistribution issue.
A. layout 1

RIP-R2–OSPF—-R1—–OSPF—-R3—
|        |
|__RIP-SW2-RIP__|

Beware of layout 1 when doing mutual redistribution  on all router involved (R1, R2, R3,SW2). The ospf and RIP domain will by default will looped back.

N: At R2 make rip distance lesser than OSPF (e.g. distance 109 – router rip)

B. Redistribution troubleshooting technique.

-Shut down some interfaces to make the topology simple. Check whether you can get expected routes from the neighboring routers.
-Check for filtering in or out direction on the 1. interface, routing process.
-Alternative to bumping up AD of OSPF versus RIP, you can bump down RIP AD targeting only from a specific neighbor.

e.g.

router rip
distance 109 x.x.x.x 0.0.0.0
x.x.x.x is the neighbor.

-this makes routes from neighbor x.x.x.x to have a better distance learned from OSPF.

or it is usually like this:

router ospf 1
distance ospf external 121
! or
distance 110 x.x.x.x 0.0.0.0
! or
router ospf 1
redistribute rip metric 10000 subnets <<<<<<<makes sure the the redistributed routes to OSPF has a worse metric.

General Rule in Redistribution:

1. Native prefixes for one protocol should be reached via this protocol, can have the best metric against others.
2. External prefixes should have AD that is worse than the  AD of the native prefixes from different protocol.
3. When injecting external information into a protocol, assign it a high metric value to make is less preferred.
4. You can safely generate default route for stub domains but watch out and do filter of this default if needed.

Redistribution commandments notes:

1. ospf to eigrp -> 110 to 170 -> ok
2. eigrp to ospf->  90 to 110 -> ok
3. eigrp(external) to ospf -> 170 to 110 <<<– problem here, not ok, watch out!
4. lower AD wins

TECHNIQUES:

1. route tagging
2. route summarization
3. distance

To the following with redistributing:

1. Check first all native routes per router.
2. Check all external routes per protocol type, perrouter.
3. Think of the redistribution commandments.
4. Can make ospf acts like EIGRP on dealing with external prefixes. (distance ospf external 171)
5. Bump up or bump down certain prefixes. (external or internal).
6. The distance of external EIGRP cannot be changed on a per prefix basis.
7. ping the destination using the source IP address interface on different network
8. debug ip packet detail with an ACL (ACL is permit icmp from any to any or host)
9. Adjust default AD of IGP. RIP->109, OSPF= 121, OSPF External = 171, ospf = 89, depends on the situation and requirments.

Watchout on the following with redistributing.

1. route feedback.
2. manually tag the route with higher AD with put into the redistributed towards the lower AD.
3. lockdown pre-redistribution externals to equal to the native AD (e.g. distance 110 0.0.0.0 255.255.255.255  ACL_EXTERNAL_ALREADY
4. The rest of new routes coming is can be bump up (distance ospf external 171)
5. Item 3,4 are OSPF and EIGRP samples.

-debug ip routing
-show ip route xxx
-show ip rip data
-show ip ospf topology

Ticket 5 – Server Farm

• Two new servers have been recently connected to SW1 port 0/18 and SW2 port 0/19 respectively.
• For the lab purpose, the servers are emulated by L3 ports in SW3 and SW4 respectively.
• The following is the configuration policy for the server block:
o The new servers are assigned to the subnet 192.10.X.0/24
o To ensure security, the servers should not be able to communicate directly.
o The servers should be able to reach and communicate via R4.
• However, the configuration appears to be incomplete, as servers cannot reach to each other.
• Ensure the connectivity via R4 and verify it by using IP addresses assigned to the switchports of SW3 and SW4.

-This case is related to private vlan configurations.

show interface f0/x switchport | i private-vlan
show interface trunk
show vlan id
show ip interface f0/xx | i arp

Ticket 6 – BGP

• AS254 and AS54 cannot exchange routes across AS 100, AS 200 and AS 300.
• Applying changes to BGP configurations only, restore the end-to-end connectivity.
• Do not apply any changes to AS 300 routers to accomplish this.
• The ticked will be resolved when AS 54 and AS 254 could see each other’s routes.

-External BGP loop prevention mechanism uses AS-PATH information.
-The use local-as on the source AS will generate the AS path information.
-Use allowas-in on the far receiving end
-Make user no other L2/L3 issue exist. IGP should be stable at this time. No routing loops occured.
-Check for IBGP relationships and watch out for route-refrelector requirments.

show ip bgp regexp _
show ip bgp neig xxx advertise-routes
show ip bgp sum
show ip bgp neig | i state|neighbor|index|update-group|reflec
show ip bgp update-group

Ticket 7 – L2VPN

• You have tasked a junior system administrator to configure an L2VPN tunnel between VLAN64 and VLAN46 interfaces of R6 and R4.
• Some time after this, he reported that the configuration has been done, but there are some issues preventing it from working properly.
• Find and resolve the issues preventing the Layer 2 VPN tunnel from coming up.

-Watch out for inconsistend ckt id name. Ckt id should be the same on both ends.

show vpdn tunnel
show vpdn session
show l2tun session all
show sss circuits

Ticket 8 – L2VPN Issues

• The Frame-Relay connection between R1 and R2 has been recently replaced with L2 VPN. Soon after this, users on VLAN263 started complaining that they cannot download files from the servers on VLAN42.
• They still could use telnet and ssh to access the servers though.
• Suspecting that this may be caused by Path MTU discovery failures, you configured a workaround by clearing DF bit on all TCP packets received by R2 on its VLAN263 interface.
• However, this does not seem to help and the problem persists. Find the solution to this problem that works for all types of network traffic.

-Do ping test with oversized packet to check fragmentation issues.
-Fragments per packet is controlled by VFR – ip virtual-reassembly max-fragments x command.
-Using ip tcp adjust-mss will keep the router to modify and MSS field in TCP packet header.  MSS is 40 bytes less than the MTU. Only for TCP.
-IP virtual-reassembly, use to set max amount of fragmented packets

There are basically few ways to filter fragmented packets:
1) Using an access-group applied to an interface.
2) Using a policy-map that routes fragmented traffic to Null0.
3) Using a service-policy that drops fragments.
4) Configuring IP virtual-reassembly on interface.
5) Using IOS IPS to drop fragmented traffic.
6) Using CoPPr or Control-Plane policing to restrict packets going to the router.

show ip virtual-reassembly | i Fragments
show ip int xx | i list
show ip ips all
show ip policy

Ticket 9 – NTP

• You have recently re-loaded the configuration for R3 and R4 using the backup copies and soon after that discovered the logging timestamps went wrong.
• You know that NTP has been used for time synchronization on R3 and R4.
• R5 was supposed to be the NTP master for R3 and R4.
• You may assume that R5 is configured correctly and fix the issues in R3 and R4.

-NTP key should match on Server and client.
-Use key chain to decrypt md5 hash on same router.
-if the master NTP server is using ACLS on the peers and clients make sure the clients and peers are allowed on the ACL. Make sure NTP source is allowed.
-NTP authentications need to do “ntp authenticate” command
-NTP key should be manually trusted.

show ntp status
show ntp ass detail

Ticket 10 – Internet Access

• After the recent security policy changes users on VLAN5 started complaining they cannot reach YouTube videos anymore.
• Asking a few questions you found that uses cannot access any other WWW sites as well.
• After a short investigation you found that the uplink used to reach the YouTube website is via BB1.
• Talking to the users you found that only HTTP is being affected, FTP downloads work well.
• Applying minimal changes to the network configuration resolve this problem and restore WWW connectivity.

-Related to WWW access only. Described that FTP traffic is not affected.
-Not Path MTU issue.
-Watch out for TOS value is matched and on the route-map is set to drop it to null0 interface.
-The DF bit can be cleared using route-map. set ip df 0.

-Check MTU issue
-Check local policy-map
-Check ip ips
-Check route-maps applied to the interface, make sure it is not dropping it.
-enable http server on each router as a test to web traffic.

ip http server
ip http path flash:
copy http://x.x.x.x/test null:
sho ip policy
show ip ips all
show ip int virtual-access x | i access

Leave a Comment

Posted in CCIE | Tags:

Posted by: Mar Apuhin | February 24, 2010

How the bgp deterministic-med Command Differs from the bgp always-compare-med Command

Introduction

There is sometimes confusion between the two Border Gateway Protocol (BGP) configuration commands bgp deterministic-med and bgp always-compare-med. This document explains the differences in how the bgp deterministic-med and bgp always-compare-med commands can affect Multi Exit Discriminator (MED)-based path selection and how each command changes the behavior of BGP when choosing a best route.
Prerequisites
Requirements

There are no specific requirements for this document.
Components Used

The information in this document is based on the Cisco IOS® Software Release 12.2(10b).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Background Information

There are two BGP configuration commands that can influence the MED-based path selection, the bgp deterministic-med and the bgp always-compare-med commands.

Enabling the bgp deterministic-med command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the bgp always-compare-med command ensures the comparison of the MED for paths from neighbors in different autonomous systems. The bgp always-compare-med command is useful when multiple service providers or enterprises agree on a uniform policy for setting MED. Thus, for network X, if Internet Service Provider A (ISP A) sets the MED to 10, and ISP B sets the MED to 20, both ISPs agree that ISP A has the better performing path to X.

Note: The bgp deterministic-med and bgp always-compare-med commands are not enabled by default. Also, the two commands are separate; enabling one does not automatically enable the other.
Command Examples

The examples in this section demonstrate how the bgp deterministic-med and bgp always-compare-med commands can influence MED-based path selection.

Note: Cisco Systems recommends enabling the bgp deterministic-med command in all new network rollouts. For existing networks, the command must either be deployed on all routers at the same time, or incrementally, with care to avoid possible internal BGP (iBGP) routing loops.

For example, consider the following routes for network 10.0.0.0/8:

entry1: AS(PATH) 500, med 150, external, rid 172.16.13.1
entry2: AS(PATH) 100, med 200, external, rid 1.1.1.1
entry3: AS(PATH) 500, med 100, internal, rid 172.16.8.4

The order in which the BGP routes were received is entry3, entry2, and entry1. (Entry3 is the oldest entry in the BGP table, and entry1 is the newest one.)

Note: When BGP receives multiple routes to a particular destination, it lists them in the reverse order that they were received, from the newest to the oldest. BGP then compares the routes in pairs, starting with the newest entry and moving toward the oldest entry (starting at top of the list and moving down). For example, entry1 and entry2 are compared. The better of these two is then compared to entry3, and so on.
Example 1: Both Commands Disabled

Entry1 and entry2 are compared first. Entry2 is chosen as the better of these two because it has a lower router ID. The MED is not checked because the paths are from a different neighbor autonomous system. Next, entry2 is compared to entry3. Entry2 is chosen as the best path because it is external.
Example 2: bgp deterministic-med Disabled, bgp always-compare-med Enabled

Entry1 is compared to entry2. These entries are from different neighbor autonomous systems, but since the bgp always-compare-med command is enabled, MED is used in the comparison. Of these two entries, entry1 is better because it has a lower MED. Next, entry1 is compared to entry3. The MED is checked again because the entries are now from the same autonomous system. Entry3 is chosen as the best path.
Example 3: bgp deterministic-med Enabled, bgp always-compare-med Disabled

When the bgp deterministic-med command is enabled, routes from the same autonomous system are grouped together, and the best entries of each group are compared. The BGP table looks like this:

entry1: AS(PATH) 100, med 200, external, rid 1.1.1.1
entry2: AS(PATH) 500, med 100, internal, rid 172.16.8.4
entry3: AS(PATH) 500, med 150, external, rid 172.16.13.1

There is a group for AS 100 and a group for AS 500. The best entries for each group are compared. Entry1 is the best of its group because it is the only route from AS 100. Entry2 is the best for AS 500 because it has the lowest MED. Next, entry1 is compared to entry2. Since the two entries are not from the same neighbor autonomous system, the MED is not considered in the comparison. The external BGP route wins over the internal BGP route, making entry1 the best route.
Example 4: Both Commands Enabled

The comparisons in this example are the same as in Example 3, except for the last comparison between entry2 and entry1. The MED is taken into account for the last comparison because the bgp always-compare-med command is enabled. Entry2 is selected as the best path.

Leave a Comment

Posted in CCIE

Posted by: Mar Apuhin | February 24, 2010

Featured Article: Flexible Packet Matching

Featured Article: Flexible Packet Matching By Steve Means

One of the issues facing network and security engineers is defending the network against dynamic threats. This means traffic that cannot easily be identified by regular means, such as an application that changes layer 4 ports or tunnels within an existing protocol. Because of this, a solution is needed to match and filter based on specific information within the packet that is unique to the application you want to block.

Enter “Flexible Packet Matching”, otherwise known as FPM. FPM works by loading XML files called “Protocol Header Description Files” that define fields within the protocol header: IP, TCP, UDP, ICMP, etc…. Once defined, information within the fields can be matched and acted on using MQC.

As a simple example, we’re going to allow ICMP but block echo requests that come from 192.168.9.10 with a length greater than 500.

To enable FPM, you need to first load the PHDFs for the protocol stack you’ll be working with. We’ll be using ETHER, IP and ICMP, so those files are loaded with the “load” command:

load protocol system:/fpm/phdf/ether.phdf
load protocol system:/fpm/phdf/ip.phdf
load protocol system:/fpm/phdf/icmp.phdf

Next you have to tell FPM the correct protocol stack to examine. This is done with a class-map type stack. Notice that we start at layer 2, match the ethertype for IP, then move to layer 3, matching IP protocol 1 or ICMP.

class-map type stack match-all IP_ICMP
stack-start l2-start
match field ether type eq 0×800 next IP
match field layer 3 IP protocol eq 1 next ICMP

With the stack defined, we’re now free to match the specific information we’re after, FPM uses “class-map type access-control”.

class-map type access-control match-all BAD_ICMP
match field icmp type eq 8
match field ip source-addr eq 10.6.6.6
match field ip length gt 500

Now we’ll create a “policy-map type access-control” to drop any traffic that is a part of this class. This policy map is then nested within another policy map that matches our previously defined protocol stack. It is then applied to the interface:

policy-map type access-control DROP_BAD_ICMP
class BAD_ICMP
drop
policy-map type access-control FPM
class IP_ICMP
service-policy DROP_BAD_ICMP
!
int fa0/1
service-policy type access-control input FPM

Verification is simple. First we’ll ping from a router with an interface IP of 192.168.2.10 with no options:

R2# ping 10.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 50/58/60 ms

The ping is successful as expected. It matches the stack, ICMP type and source address, but not the size. Now we can repeat the ping, upping the size:

R2# ping 10.6.6.6 size 1000
Type escape sequence to abort.
Sending 5, 1000-byte ICMP Echos to 10.6.6.6, timeout is 2 seconds:
….
Success rate is 0 percent (0/5)

This time the packets were dropped. We can further verify by checking the policy-map on the router using FPM. Notice that we have lots of packets matching the stack class-map, but only our 5 echo requests were dropped:

R1#sho policy-map type access-control interface
FastEthernet0/1

Service-policy access-control input: FPM

Class-map: IP_ICMP (match-all)
136 packets, 15468 bytes
5 minute offered rate 0 bps
Match: field ETHER type eq 0×800 next IP
Match: field layer 3 IP protocol eq 1 next ICMP

Service-policy access-control : DROP_BAD_ICMP

Class-map: BAD_ICMP (match-all)
5 packets, 5070 bytes
5 minute offered rate 0 bps
Match: field ICMP type eq 8
Match: field IP length gt 500
Match: field IP source-addr eq -1062729462
drop

This is a fairly basic example that is easy to verify and learn with. FPM can be much more detailed, even going so far as to match specific strings within the data payload itself. The preferred method of applying this in the field is to sniff the traffic you’re interested in, find something that is unique to this traffic and match based on it.

Leave a Comment

Posted in CCIE

Posted by: Mar Apuhin | January 21, 2010

Free Lab Book (download) – Narbik

Here is Narbik’s post from GS

To All,

First of all I would like to apologize for the delay.

Secondly, please excuse any typos, I kind of rushed to get this out so you guys will enjoy the lab.

Once again there are no registrations, no sign-ins or any other requirements to download the lab.

Please go to

http://www.micronicstraining.com/classes/index.php?dispatch=categories.view&category_id=93

And then, click on *CCIE Routing and Switching Trouble Shooting Workbook* and then, click on *Download FREE sample chapter*.

Please let me know if you experience any problems.

The initial config file is also included. You need to have winrar to unzip the directory, it also includes the diagrams.

This lab is one of the 10 Troubleshooting Mock labs and hope it would NOT be a waste of your precious time. PLease go through and read the answers and see the steps that one has to go through to resolve a trouble ticket.

I have also included another FREE lab work book that you guys can download; it has 338 pages of good labs (They help reduce your blood pressure, whereas, the TS labs help reducing the cholestrol). You should see it there as well.

The security work book and the SP will be our next priority and they should be completed before the end of the year.

There will also be a FREE VOD on ZBFW, that should be finished within a week or so.

Enjoy and I hope to see you guys later.

–
Narbik Kocharians
CCSI#30832, CCIE# 12410 (R&S, SP, Security)
www.MicronicsTraining.com
Sr. Technical Instructor
YES! We take Cisco Learning Credits!

2 Comments

Posted in CCIE

Posted by: Mar Apuhin | December 22, 2009

CCIE Policies

Candidates should be familiar with the policies for CCIE program participation, as stated below. If you have any questions regarding the policies please contact CCIE customer support through the Certifications Online Support tool.

  • Conduct
    Candidates must agree they will not compromise the integrity or confidentiality of any Cisco certification exam or certification program. Prohibited actions are described in the Cisco Career Certifications and Confidentiality Agreement. Remedies for violating the policy can include a lifetime ban on all future exams and voiding of all previous certifications.

    Return to Top

  • Confidentiality
    The questions and answers of the certification exams are the exclusive and confidential property of Cisco and are protected by Cisco’s intellectual property rights. Candidates taking Cisco exams must agree they have read and will abide by the terms and conditions of the Cisco Career Certifications and Confidentiality Agreement before beginning each exam.

    Return to Top

  • Correspondence
    All official correspondence to certified CCIEs and candidates is sent to the email address in the CCIE database. This database is SEPARATE from the Cisco customer database. Changing an email address in the Cisco customer database does not automatically update the CCIE database. CCIEs and candidates must keep their CCIE email address updated in order to ensure they received all official correspondence.

    Return to Top

  • Exam Violations
    Disclosure of test content is strictly prohibited. Please report any suspicious activity as described in Cisco’s Exam Violation Rules.

    Return to Top

  • Lab Exam: Double Booking
    CCIE candidates are allowed to schedule only a single CCIE lab exam date at any location for each CCIE track. Double booking for lab exams in the same track, at either the same location or different locations, is not permitted by the database. Candidates will be allowed to simultaneously schedule lab exams for different tracks.

    Return to Top

  • Lab Exam: Exam Rules
    Candidates for the CCIE written exam or lab exam are not allowed to bring anything into the exam room or take anything out. This includes, but is not limited to: notes, documentation, watches, laptops, keyboards, pagers, PDAs, and mobile phones. DO NOT confer or consult with anyone about the exam while taking the exam or after the exam is completed. During an exam, you may only discuss your exam with the lab engineer.

    Return to Top

  • Lab Exam: Payment

    Price not confirmed and is subject to change until full payment is made.

    Types. Lab sites in China and Japan will only accept payment via wire transfer. All other locations accept online credit card payment (American Express, Visa, Mastercard, or Eurocard) See “Lab Exam: Scheduling and Payment” for details. You are responsible for any fees your financial institution may charge to complete the payment transaction.

    Due Date. Full payment must be received at least 90 days before the lab exam date. Only one e-mail notice is sent as a payment reminder. Payments generally take one to seven business days to process, so be sure to initiate payment in advance of the due date. It is important that if payment will be made by wire transfer, that the payment is scheduled well in advance to prevent the lab date being dropped. Exams for which payment is not received by the due date will be automatically dropped from the schedule. If you still wish to take the lab, you must rebook the exam online and complete your payment. There is no guarantee that your original date will still be available once it has been dropped for non-payment. If you book an exam for a date less than 90 days away, you must complete payment on the day you book the exam or the registration cannot be submitted. Candidates are ultimately responsible for making the lab payment in a timely manner and Cisco will not be held liable for any candidates automatically dropped due to non-payment.

    Processing. Credit card payments entered into the system will be processed on the payment due date, exactly 90 days prior to your lab date, as will invoices for all payment types. Be sure the company name, invoicing address and email address are complete and accurate to ensure proper delivery of your invoice. No invoices will be generated before the lab exam due date.

    Return to Top

  • Lab Exam: Rescheduling, Canceling and Postponing
    Prior to Due Date. Cancellations or changes to the exam date, location, or track must be made prior to the payment due date–90 days before the scheduled lab date. To make any changes, you must log into the Lab Scheduling tool and drop your current lab. Then you can reschedule according to preferred date, location and track. You may book an exam for a date less than 90 days away, if you complete payment on the day you book the exam.

    If you need to cancel an exam before the due date, and paid via a wire transfer that has already cleared, you are eligible for a full refund by requesting support via the Certifications Online Support tool.

    After Due Date. Changes and cancellations are not permitted after the payment due date–90 days prior to the scheduled lab date–and no refunds will be issued. If you are not able to attend your scheduled lab date, contact support to let them know the lab seat will not be used. You will still forfeit your payment, but you will be allowed to book another exam date immediately. If you do not contact support, you will be marked as a “no show” for the exam and be barred from booking another exam for 30 days.

    Candidates Requiring Visas. If you require a visa to attend your lab exam, it is strongly recommended you apply 10-12 weeks before your lab date. Candidates who fail to obtain required visas will still be bound by these cancellation policies and must cancel their lab exam before the payment due date to be eligible for a full refund. For more information in requesting a CCIE Invitation Letter, please visit our CCIE: Invitation Letter (Entrance Visa) Instant Answer.

    Return to Top

  • Lab Exam: Reevaluation of Lab Results

Exam results appeals are available for the routing and switching, security, and service provider technology tracks. Only exams with potential to change from fail to pass will have the option to request an appeal, based on years of historical data. Appeals are not available for the voice or storage tracks due to equipment limitations.

An appeal consists of a second proctor loading your configurations into a rack to recreate the test and re-score the entire exam. This process takes up to three weeks after receipt of payment. Only one appeal per lab attempt is permitted.

The result of the appeal is a confirmation of the existing fail or an update to a pass.

Payment Terms

Make your request within 14 days following your exam date by using the “Request for Reread” link next to your lab record. Each appeal costs $250.00 USD plus any applicable local taxes. Payment is made online via credit card and your card will be charged upon receipt of the request. You may not cancel the appeal request once the process has been initiated. Refunds are given only when results change from fail to pass.

Return to Top

  • Lab Exam: Retakes
    All candidates must wait 30 days between CCIE lab attempts. Please note the 30 days starts from the day after a failed lab exam.

    Return to Top

  • Lab Exam: Scoring
    You must obtain an overall score of at least 80% to pass the lab exam. You can view your lab exam results online (login required), usually within 48 hours. Results are Pass/Fail and failing score reports indicate major topic areas where additional study and preparation may be useful.

    Return to Top

  • Lab Exam: Start Times
    Start times for exams are indicated in email can also found on the web page associated with each lab location (for a list, see Lab Exam Locations). Please verify your email address in your candidate profile so we can notify you of any changes. If you have any questions about the start time of your exam, please contact CCIE customer support through the Certifications Online Support tool . If you arrive more than two hours after the start of your exam, you will not be allowed to start. If you arrive less than two hours late, you will be allowed to start but you must finish with the rest of the group.

    Return to Top

  • Logo Guidelines
    Certified CCIEs may only use the CCIE logo as provided and in accordance with the published Logo Guidelines.

    Return to Top

  • Recertification
    To maintain active CCIE status, CCIEs are required to pass either a CCIE written exam of their choosing from among all of the currently available written exams, or a CCIE lab exam in a new track every 24 months. Candidates can only apply one passed written exam towards recertification for every 24 month recertification period. Certification candidates are responsible for keeping track of their certification expiration dates; your recertification deadline can be viewed online anytime (with login) at Certification Status. Subsequent recertification deadlines are always based on your original certification date, not on when you took your last recertification exam.

    If your CCIE recertification requirements are not completed on or before the certification’s expiration date, your CCIE certification will be suspended for one year. Candidates have one year to recertify their CCIE certification by passing the required written exam. If a candidate does not recertify prior to the one year suspension period, all CCIE certification requirements must be completed again to obtain the certification (pass both the written exam and the lab exam.) Please see Recertification for detailed information.

    Return to Top

  • Travel Costs
    Under no circumstances will Cisco reimburse travel costs for CCIE lab exams.

    Return to Top

  • Written Exam: Expiration
    Candidates must make an initial attempt of the CCIE lab exam within 18 months of passing the CCIE written exam. Candidates who do not pass must re-attempt the lab exam within 12 months of their last scored attempt in order for their written exam to remain valid. If a candidate does not pass the lab exam within three years of passing the written exam, he or she must retake the written exam before being allowed to attempt the lab exam again.

    Return to Top

  • Written Exam: Retakes
    There is no limit to the number of attempts that can be made on the written exam. However, candidates must wait 5 calendar days between exam attempts. Once a candidate passes a particular written exam, he or she may not retake that same exam for at least 180 days. (Though rare, this may occur in certain recertification situations.)

    Return to Top

  • Written Exam: Scoring
    Pass marks are set by using statistical analysis and are subject to change. The pass score is given on the Examination Score Sheet at the end of the test. Along with the candidate’s score, there is a notation of either PASS or FAIL. Scores on written exams are automatically downloaded from testing vendors, but may take up to 10 days to appear in the CCIE database.

    Return to Top

Leave a Comment

Posted in CCIE

Posted by: Mar Apuhin | December 17, 2009

IP Routing Tech Notes and Troubleshooting Guides

  • Border Gateway Protocol (BGP)
  • Classless Interdomain Routing (CIDR)
  • Enhanced Interior Gateway Routing Protocol (EIGRP)
  • Integrated Intermediate System-to-Intermediate System (IS-IS)
  • Interior Gateway Routing Protocol (IGRP)
  • Multiprotocol BGP (MBGP)
  • On-Demand Routing (ODR)
  • Open Shortest Path First (OSPF)
  • Routing Information Protocol (RIP)

I found the above link from Cisco’s website very usefule.

Happy Labbing!

1 Comment

Posted in CCIE

Posted by: Mar Apuhin | December 9, 2009

Core Knowledge Questions Now on All CCIE Labs

Effective January 4, 2010, the CCIE® Service Provider, Storage, and Wireless Lab Exams will add 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 which require a short written response be entered into the computer–typically several words. The questions will be randomly drawn from a pool of questions on topics eligible for testing. Candidates can review the topics by visiting the CCIE track information on Cisco.com or Cisco Learning Network. No new topics are being added as a result of this change. Candidates will have up to 30 minutes to complete the Core Knowledge section and may not return to it once they have moved on. A passing score on the Core Knowledge section is required to achieve certification. Core Knowledge questions were implemented on Routing and Switching labs in February 2009, Security labs in June 2009, and Voice labs in July 2009, and allow Cisco to maintain strong exam security and ensure only qualified candidates are awarded CCIE certification. Candidates with exam dates January 4, 2010 or later should expect to see the new question format on their lab exam.

To find out more information regarding updates to the CCIE Lab and scoring format, please click here to go to the CCIE Q&A section.

2 Comments

Posted in CCIE | Tags:

Posted by: Mar Apuhin | December 8, 2009

Cisco IOS Zone-Based Firewall and Intrusion Prevention System Overview VOD’s

To all my active and loyal CCIEPILOT.COM’s followers…

Training session Webex Recordings

Cisco IOS Zone-Based Firewall Concept, Configuration, and Troubleshooting

https://ciscosupport.webex.com/ciscosupport/ldr.php?AT=pb&SP=MC&rID=1908767&rKey=af5f55c7874a225b

Cisco IOS Intrusion Prevention System Overview and Troubleshooting

https://ciscosupport.webex.com/ciscosupport/ldr.php?AT=pb&SP=MC&rID=1922807&rKey=22339b09e0dc96d0

1 Comment

Posted in CCIE

Posted by: Mar Apuhin | December 1, 2009

PPP – no peer neighbor-route

Trivia: PPP

Diagram:

R4-s0/1<<——–Serial-back-2-back———>>s0/1-R5

Question:

Configure PPP on the Serial connection between R4 and R5 using dialer
interfaces.

Answer:

R4 and R5

interface Serial0/1
no ip address
encapsulation ppp
dialer in-band
dialer pool-member 1
pulse-time 1

interface Dialer0
ip address 45.45.45.x 255.255.255.0
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer persistent
end

Routing Table:

C       45.45.45.x/32 is directly connected, Dialer0
C       45.45.45.0/24 is directly connected, Dialer0

R4#sh dialer

Se0/1 – dialer type = IN-BAND SYNC NO-PARITY
Dialer pool 1, priority 0
Idle timer (never), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Interface bound to profile Di0
Time until disconnect never
Connected to <unknown phone number> (<unknown phone number>)

Di0 – dialer type = DIALER PROFILE
Idle timer (never), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Number of active calls = 1

Dial String      Successes   Failures    Last DNIS   Last status

Trivia: PPP – I dont want the /32 in you.

We always see a /32 host route every time we use PPP. What if you dont like and want it? What

will you do?

Diagram:

R1-s0/1<<—–Serial-Connection——>s0/1-R2

Answer Configuration: use “no peer neighbor-route” interface command.

R1 and R2

interface Serial0/1
ip address 12.12.12.x 255.255.255.0
encapsulation ppp
no peer neighbor-route

Routing Table:

12.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       12.12.12.0/24 is directly connected, Serial0/1
C       12.12.12.2/32 is directly connected, Serial0/1 <<<<< Get rid of this!

After:

Gateway of last resort is not set

12.0.0.0/24 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, Serial0/1

Verification:

R1#ping 12.12.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.12.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/38/56 ms
R1# ping 12.12.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.12.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/68/120 ms
R1#

Show to know:

R1#sh int s0/1 | i Open
Encapsulation PPP, LCP Open
Open: IPCP, CDPCP, crc 16, loopback not set
R1#

That’s it!

Leave a Comment

Posted in CCIE

Posted by: Mar Apuhin | November 30, 2009

CDP Neighborship but not a directly connected endpoints

Trivia: CDP

• SW1 and SW2 should see each other as CDP neighbors via SW3
across the routed link that connects them.

Diagram:

SW1———-f0/1–SW3–f0/2———SW2

Answer:

SW2:

interface FastEthernet0/1
l2protocol-tunnel cdp
no cdp enable

interface FastEthernet0/2
l2protocol-tunnel cdp
no cdp enable

That’s it!

Leave a Comment

Posted in CCIE | Tags: ,

Older Posts »

Categories