CCIE study plan



  • BardlebeeBardlebee Member Posts: 264 ■■■□□□□□□□
    gorebrush wrote: »
    OK yeah there are many "line items"

    I always just looked at it as: -

    Layer 2
    etc - very high level. But I get what you mean.

    Yeah, exactly. :)
  • IristheangelIristheangel CCIEx2 (Sec + DC), CCNP RS, CCNA V/S/R/DC, CISSP, CEH, MCSE 2003, A+/L+/N+/S+, and a lot more from m Pasadena, CAMod Posts: 4,133 Mod
    Just to give you (OP) an idea, the lab has high level topics such as BGP. So you can think of BGP as one topic but really, it includes a lot of things, not limited to the following:
    - iBGP
    - eBGP
    - BGP messages
    - Neighbor states
    - Message types
    - BGP table
    - Injecting routes and prefixes
    - Redistribution
    - Auto-Summary
    - Manual summaries
    - Weight
    - Local preference
    - MED
    - Origin
    - AS-Path
    - Next-Hop
    - Default routes
    - BGP Updates and their content
    - Backdoor routes
    - Syncing and disabling syncing routes
    - Confederations
    - Route reflectors
    - Multiprotocol BGP

    and so much more with BGP. If you break out all the variables and subtopics in each high-level topic, you'll find an insane amount of things you'll need to learn and be an expert on. With the CCIE, you're not only expected to know the theory, how to configuring or how to troubleshooting this protocol but you're expected to troubleshoot it with every other protocol in the lab in a very very large topology with a lot of issues thrown in the configs.

    Here's an example taken from the walkup labs at Cisco Live:

    You have a topology-

    And you're given very a high level description of the issue or what you have to do:

    Sometimes you have access to the devices, sometimes you do now and you might have to troubleshoot an issue on something that might be reconfigured on the side you can't touch so you're utilizing debugs and show commands - not the actual config - to troubleshoot and repair the issue. Sometimes you're supposed to troubleshoot from one end of the topology to the other so it's up to you to figure out where it's being routed to, where the issue is, and how many issues.

    That's sort of how the lab can be and that's why someone with a lot of book knowledge still can fail horribly. It's a LOT of reading with a LOT of labbing.
    BS, MS, and CCIE #50931
  • creamy_stewcreamy_stew Member Posts: 406 ■■■□□□□□□□
    Actually, I heard cisco are just going to be testing on one topic for a limited time.

    The topic?

    Itchy... Tasty!
    [X] DCICN
    [X] IINS

    [ ] CCDA
    [ ] DCICT
  • tech2010tech2010 Registered Users Posts: 2 ■□□□□□□□□□
    Yes but the gentleman who created it isn't going to be back at work for another week and I don't feel comfortable sharing his content unless I have his permission first.

    @Iris..kindly share the tracker for DC track if possible...Thanks....
  • lostindaylightlostindaylight Member Posts: 43 ■■□□□□□□□□
    And you're given very a high level description of the issue or what you have to do:


    A match the output task. Those can be the toughest ones.

    Like what if this was a route reflector client learned route? perhaps we're interested in igp traffic engineering the path to next hop ip address. maybe we want a different bestpath choice at the route reflector? Maybe we want the As edge router to use next hop self? perhaps cef per packet load balancing is enabled somewhere in the topology? Perhaps there's policy routing going on somewhere?

    You have to understand how the technology interacts and how to *quickly* narrow down the possibilities to diagnose what's needed.
Sign In or Register to comment.