SUMMARY: How I learned to stop worrying and love the LAB. A structured logical approach for taking CCIE Lab is proposed. The key idea is to perform in-depth analysis in the beginning of the lab exam. Good plan should give you confidence and guidelines to finish your exam. Excellent DocCD knowledge should backup your weak areas. Five main stages of proposed approach: 1) Relax. 2) Analyze and plan. 3) Ask the proctor and do the preparations. 4) Implement & Troubleshoot your plan. 5) Verify your solution. APPENDIXES A. Redistribution techniques B. Router QoS options C. 3550 Catalyst QoS options Axiom: CCIE Lab is 50% of discipline & methodology, and another 50% of knowledge. You should spend 1 hour planning, 6 hours of actual configuration, 1 hour of verification. THE PLAN #0 Things you should better take on lab/do before lab begins are: a) Bring Color pencils. It's been a long time discussion on wherever you are allowed to bring color pencils with yourself or not. Better e-mail a question regarding your site to ccie@cisco.com :). I would recommend at least: Red, Green, Blue, Black, Violet, and ordinary pencil. b) Take ear plumbs :) Really good thing to help you concentrate, just practice to use them before actual lab. And don't forget to take them out, when you visit the proctor. c) Bring some standard legal drugs (painkillers, etc) just in case your health (especially stomach) suddenly plays bad joke on you. d) Ask for enough scrap paper sheets from proctor, before lab begins. #1 Relax. Spend a few minutes to understand the topology at first glance. Take a quick look over all tasks, noting keywords, taking a "first feel" and relaxing a little. Look for points distribution, summarize Core (L2/3, IGP, BGP) and non-Core (IOS Srv, IPv6, Mcast, Security, QoS) points. Don't spend more then 5 minutes on relaxation. Plan to spend about 1 hour of your time on analysis. Divide that hour on two parts, accordingly to point distribution. E.g. if you have 60 or Core and 40 non-Core, spend 36 minutes on Core and 24 on non-Core analysis. #2 As far, as your brain in not yet frustrated nor tired, start lab analysis & plan your attack. You will need to read scenario thoroughly twice, to gain in-depth understanding of tasks. Some general guidelines here: a) Pay exteme attention to wording, read every task at least twice. Note every minor stuff, especially things related to RIDs/OIDs in IGP, BGP, Mcast and non-standard prefix masks. b) Verify your diagrams. Once you redraw it, make a quick check with original. Compare VLAN & IGP diagrams, check them for consistence. c) If you have multiple options coming in your mind, choose the most simple one. And don't forget to ask the proctor to be 100% sure. #2.1 Rediagram, part 1. We need to make separate diagrams for #2.1.1 IPv4 IGP. Includes link addressing and IGP domains. #2.1.2 IPv4 BGP (BGP domains, internal/external links, BGP networks). You'd better have two BGP diagrams: you put first one over IGP diagram, and second separately. First diagram will help you catch IGP-BGP interaction problems, and second would help with developing traffic-engineering and policy-routing strategy. #2.1.3 IPv4 Redistribution diagram/table. In simple cases there should be enough just to draw arrows over IGP diagram, showing route-redistribution points, route-injection paths, mark backup and primary injection points. In complex scenarios, (and case-studies) you probably will need to draw redistribution diagram separately. More on that in IGP redistribution section. #2.1.4 VLAN table (includes port types, VLAN to port assignment, allowed vlan, VTP comments, trunk types). I would recommend drawing two big boxes on the left and right sides of paper sheet (they represent two 3550 Catalysts) putting routers and trunk links between. You should then use color pencils for different VLANs, and look how they all interconnects inside/between switches. This diagram should give you clear understanding of VLAN assignment, and trunks' allowed VLANs. #2.1.5 IPv6 IGP/BGP. That one resembles IP4 IGP/BGP diagram, but should probably be smaller in size. So you can safely put IGP/BGP on the same diagram. #2.1.6 Mcast distribution diagram. You should draw a separate diagram with links, involved in Mcast routing, and also draw IGP domains over it. Comments: a) AFAIK, they give you IPv4 IGP diagram on a lab, and some physical connectivity diagrams too. Don't know if BGP domains are there. You probably won't be able to make all diagrams from the very start. Just redraw what they give you, and make the stuff look comforatable for you. #2.2 Read the lab, 1st pass. Now you probably have IPv4 IGP diagram and VLAN table, with clear understanding of link addressing. Open notepad and start reading the tasks. Put short comments on your diagrams while reading, put more detailed comments in notepad, paying attention to key moments and insights. Also, put clues regarding verification commands for specific sections in your notepad too. Don't forget to make you notepad text structured in accordance to task list. And last, but not least - make a list of questions for the proctor, by the way. Present them in multiple-choice format, on separate list of paper. Use any shortcuts you find comfortable. ---- Core topics Analysis (approx 30-40 minutes) -- L2/L3: #2.2.1 Serial interfaces. You will need to enhance your IGP diagram in this section with interface information. Divide and conquer, looking for: #2.2.1.1 Frame-Relay. Figure out FR topologies (H&S,Full-mesh, etc) interface types (p2p, mp, phy), b2b FR, LMI/encapsulation types, inverse-arp requirements, compression. Put inteface types on your IGP diagram (I prefer shortcut name like: P=Phys, M=Multipoint, 2=p2p) Look out for weird stuff like PPPoFR/MLPPPoFR, FRF.16. If you cannot figure out some of the stuff, leave it for 2nd pass, some clues may be provided later (e.g. in IGP section, you may deduce that you need p2p/mp interface types) #2.2.1.2 PPP/HDLC. Make a note about peer-neighbor route, and comments on PPP/HDLC features (authentication, compression, negotiation options, etc). Pay attention to clock-rates and bandwidths. #2.2.2 Catalysts 3550 configuration & Ethernet interfaces. This is where you actually build VLAN diagram. Pay special attention here, don’t put VLANs in the wrong places. You will need to determine if you have: #2.2.2.1 Access/trunk links on routers, their encapsulation, allowed VLANs #2.2.2.2 dot1q tunnels (note mtu change, possible ospf problems), figure out passenger vlans, and metro-tags, native vlan tagging issues. #2.2.2.3 Transparent bridging (IRB/CRB). Mark interfaces, selected for bridging, introduce BVIs where necessary, add them to IGP diagram if you want. #2.2.2.4 Fallback bridging on Catalysts (only non-ip!), if this is required by scenario, mark ports/VLANs selected for F/B. #2.2.2.5 STP issues. Watch for STP root election, timers tuning, STP load balancing, advanced STP stuff like MSTP/RSTP. In complex cases (e.g. complex IRB and large STP) draw a separate STP diagrams, mark root ports, locate possible problems (e.g. STP over FR H&S topology). Look out for signs of STP features like portfast, bpdufilter/guard, protected ports etc. #2.2.2.6 VTP issues, VTP password/version, pruning etc. After you finished with Ethernet & Catalysts, you should have VLAN diagram and some sort of plan to resolve STP issues. #2.2.3 Virtual interfaces: There is strong chance, that IRB, dot1q tunneling, virtual interfaces, etc are hidden in tasks along the list. Just keep in ming that you may enconunter them, add comment if you suspect that this is the case. #2.2.3.1 GRE/IPIP Tunnels #2.2.3.2 mGRE Tunnels #2.2.3.3 IPsec tunnels (VTIs fall into this category too). #2.2.3.4 IPv6 tunnels (ipv6ip, ipv6 generic, 6to4, isatap). You should put virtual interfaces on corresponding IPv4/v6 IGP diagrams. Special thing to remember about virtual-interfaces: if you run some IGP over them, you should be ready to fight with additional IGP challenges (e.g. if you run a tunnel over OSPF domain, and enable OSPF over tunnel). -- IGP #2.2.4 IGP Section. This your goal #2 in Lab. Goal #1 was L2/L3 connectivity. Pay special attention here. You may found clues for L2/L3 section inside IGP. If you don't know exactly how to cope with particular task, make a note to do a DocCD scan later, and continue. Remember to make a prefix-list/acls for each protocol's prefixes. (you should give them names that make real sense, e.g. RIP-PREFIXES, OSPF-PREFIXES, EIGRP100-PREFIXES). When you are required to do summarization, create filtering acl etc, you'd better do that at analysis stage. Perform a bit-decomposition, ANDs, XORs, etc. You should be prepared to face authentication challenges for IGP later in security section. #2.2.4.1 OSPF. You need to determine: RIDs, links origination methods, network types, area types, DRs/BDRs, authentication, virtual links, NSSA translators, FA issues. This may be tightly related to L2/L3 section, especially with Frame-Relay. Note if you are required to do OSPF tuning: timers adjustment, LSA filtering, additional OSPF features like NSSA suppress FA etc. #2.2.4.2 RIP. Remember basic stuff like: split-horizon on FR physical, TTL 2 in unicast packets, summary-address issues, auto-summary issues. You can filter with offset-list and distance command. Build necessary route-filters at the planning stage. #2.2.4.3 EIGRP. Remember EIGRP unicast issues (no passive), EIGRP split horizon, bandwidth pacing, EIGRP stub feature. Don't forget that offset-list and distance commands work in EIGRP as well as in RIP. If you need to achieve unequal-cost load-balancing, try to manipulate Delay metric, since it's additive along the path and more predictable. Also, you could not adjust external routes distance selectively. #2.2.4.4 ODR. Don't forget about CDP on Frame-Relay interfaces, and do l2protocol-tunnel on Catalysts. Finishing this section, you should have clear understanding of most L2/L3 stuff you'll need to configure, and (hopefully) good understanding of all the IGP requirements. If not, don't panic, you will have a second pass over scenario to help you gain additional understanding. #2.2.5 IPv4 Redistribution. You should read and find redistribution points, (if they are specified), backup requirements, and redistribution limitations (e.g. use tagging, don't use filtering, etc). Determine if you have routing loops appearing, because of route re-injection. Now, next steps may really look overall complex, but I find them useful to achieve more clear undestanding of redistribution things. As I mentioned before you could use a detailed redistribution diagram here, at least on practice labs, to make youself comfortable with hard cases. In real lab, you probably should limit yourself to IGP diagram marking, and simple recommendations that I'll give later. To draw detailed redistribution diagram, place routing protocols as graph vertexes, with edges (routers that do redistribution) connecting them. e.g. __________(R1)_________ / \ / ____(R2)_____ \ / / \ \ OSPF--(R1)--EIGRP----(R3)----RIP \ / \___(R3)__/ Now a quick idea: If you need a loopless routing, you should build SPT here. Choose a core protocol, and build a spanning-tree, rooted in that protocol. if you choose OSPF you may end up with _________(R1)__________ / \ / \ / \ OSPF--(R1)--EIGRP RIP This is how you could quickly build loopless redistribution, almost without filtering. Note, that you have NO redundancy here, too. Redundant configurations should enable some of secondary pruned links, guarding primary with filtering. After that, plan to implement rule of good redistribution: NATIVE prefixes SHOULD be reachable through NATIVE protocol. Adjust AD to achieve that goal. That was a little theoretical part :). Now for the real life. If you are not limited to redistribution techniques, you'd better follow three simple rules: a) Select core & edge protocols. b) Plan prefix injection and traversal via core. Use prefix-lists/acls filtering with route-maps. (Name route-maps like: OSPF-->EIGRP, RIP-->OSPF, CONNECTED-->OSPF). c) Adjust AD to fulfill rule of NATIVE_via_NATIVE. In step (b) you could use prefix-lists created in #2.2.4, as match criteria in route-maps. You can achieve backup in routing domain by doing redundant redistributions with higher metric. You can achieve backup on the same router by using administrative distance. if you have routing enabled on tunnels, watch out for recursive prefix injection. This is especially important if you run tunnel over the same routing protocol's domain, which is enabled on tunnel itself. Plan filtering to evade potential dangers. Don't forget, that you can simply match internal/external prefixes with OSPF/EIGRP, for filtering. EIGRP also carries external protocol information in redistributed routes (e.g. external-metric). OSPF could use type-3 LSA filtering, and route-maps with distribute-list. Keep in mind, that actual OSPF filtering could be only performed on ABRs/ASBRs. Watch out for p2mp networks types with OSPF, and that /32 routes - you may need to do an additional summary. You should have redistribution diagram ready by the end of this section. That stuff may sound really complex. But it is really not :) #2.2.6. BGP. Determine BGP domains (ASes), BGP RIDs, iBGP/eBGP links, (directly connected, peered over loopbacks, ebgp-multihop, etc). Determine if you need confederation, route-reflectors, local-as, dual-as, peer-groups, peer/policy templates. Determine prefix origination technics (IGP/redist) , route filtering (prefix-list/distribute-list, as-path filter, community signalling). Watch out if you are required to originate prefix in BGP and some other protocol at the same time. Choose traffic-engineering options (Loc-pref,as-path prepend, metric, cost, community signalling). Watch for load-balancing issues, redistribution issues. Draw traffic flows, primary and backup paths, if required by scenario. Be very careful with nex-hops and reachibility issues, especially if you are running BGP over Frame-Relay topologies. Determine if you need to do route redistribution, to achieve full BGP prefixes reachibility. If you are required to work with BGP syncronization, remember OSPF/BGP RIDs rules, route-reflector problems. Also, with synchronization you pass actual routing information via IGP, so if you need to change next-hops here, you need to work with IGP. E.g. you can change next-hop in RIP prefix doing summary. Remember rule of best-path selection: N WLLA OMNI (as seen in W. Odom's book). Remember BGP commands (e.g. bgp maxas-limit, bgp bestpath as-path ignore, allowas-in etc). Check command-reference on DocCD at last resort, if you have no ideas. ---- Non-core topics analysis (approx 20-30 minutes). #2.2.7 IPv6 Two biggest differences from IPv4: you use hex and colons, and you configure routing on per-link basis. Remember that, when you do summarization: addresses are actually in HEX, so 16, 17 is 22 and 23 decimal :). #2.2.7.1 IPv6 addressing. Determine if you have any tunnels here, their types. Draw a separate IPv6 diagram. Note Link-local address, where needed (e.g. FR physical, where you need to map them statically). #2.2.7.2 IPv6 OSPFv3. The same thing as with OSPFv2: determine network types, area types, etc. Remember that you may run more then one instance of OSPFv3 on a link, and that you should use link-local addresses for neighbors. #2.2.7.3 RIPng. Not so advanced as its IPv4 counterpart (no full offset-list functionality, e,g), but otherwise should be the same. #2.2.7.4 BGP IPv6. This is almost the same as IPv4 BGP, but you may find some problems with nex-hops here. watch out for next-hop problems. #2.2.7.4 IPV6 Redistribution. Don't forget to do include-connected, and use prefix-filtering in tought cases, to prevent routing loops. I don't actually think IPv6 will be tought in real lab, since it's non-core topic. You should have IGP IPv6 diagram and redistribution plan by the end of this section. #2.2.8 IOS Features That topic may cover really wide range of features: SNMP, NTP, HSRP, RMON, syslog, NAT, DRP, NetFlow, DHCP, WCCP, Terminal lines, buit-in services, object-tracking, config-management, routing protocols features, ad infinitum. The only sure way to nail them down is to be familiar with all features as much, as possible, and be able to navigate DocCD *really* quickly to find details on any of them. This is where you should really put priorities: don't spend time on unfamiliar topics with low points value. Another moment to remember: you may find some of the features to be linked with Core/Security/QoS topic: e.g, HSRP and bgp next-hop, HSRP+NAT+BGP, NAT+RIP, IRDP+GDP, HSRP+Port security. Try to figure hidden issues as soon as possible. #2.2.9 Security Remember, Security may be linked with QoS section, e.g. you may be required to filter based on QoS marking. You may also find this section depending on IOS features. So get ready to do some DocCD lookups. Remember the worst thing: you could break your IGP/BGP configuration, with improper security implementation. If you have doubts, write a question for the proctor. Next, you need to decide, where are you required to do security stuff: Routers or/and Switches. Each topic has it's own specifics. #2.2.9.1 Router-based security #2.2.9.1.1 ACLs (std, extd, reflexive, dynamic). Just know them inside and outside. This is major security tool, so only way to beat acls is to know them well. Remember how to make a shortest-length acl. if you need port-maps use nbar commands. Remember how Lock & Key works with AAA. #2.2.9.1.2 CBAC/Appfw. Not really complex, just remember that you can redefine port mapping, and play with options. #2.2.9.1.3 TCP intercept. This may overlap with CBAC features, so watch scenarios' wording. If neither is better, choose TCP Intercept, it's simpler. #2.2.9.1.5 IPsec encryption. Remember VTI 12.3T features like VTI, and don't be afraid of crypto-maps - just don't try to encrypt wrong traffic, i.e. watch acls :) #2.2.9.1.6 uRPF. Not very hard by itself, just keep your eye on that access-list and logging features. On the other hand, you may get in trouble, if you have asymmetric traffic flows, due to bad redistribution, so check out redistribution diagram twice, if you have uRPF. #2.2.9.1.7 Protocol-specific authentication (NTP, IGP, BGP etc). Just choose the right option, and remember IPv6 routing protocols authentication is based on IPsec. Remember OSPF virtual-links, and OSPF key-transition technique. #2.2.9.1.8 Secure infrastructure (ssh, login enhancements, role-based CLI etc). The only thing that could catch you, is role-based CLI and privilege-bound commands. You may simply miss some of the pieces there, so leave them to the end of lab. Remember login lockouts require AAA enabled. #2.2.9.1.9 AAA & Security Server protocols. Things change with AAA, so watch out. You may need to define AAA lists and apply them to vty lines, create usernames, and tune enable mode authentication. On other hand, RADIUS & TACACS+ are pretty simple to configure. #2.2.9.2 Catalyst security features (20%) This is not as complex as Router-based security, but this one has its own specifics. #2.2.9.2.1 Port ACLs. Remember: input only, IP acls for IP-traffic, MAC acls for non-IP traffic. And don't forget, that Port ACLs are not compatible with VLAN filters and input RACLS. #2.2.9.2.2 RACLs. IP-only, in/out; in RACL confict with Port-ACLs, work fine with VLAN filters. #2.2.9.2.3 VLAN filters. Be careful, and remember, that by default VLAN filter forwards traffic. But once you specify an IP acls in any line, all non-matched IP traffic is dropped. The same thing goes to MAC-acls and non-IP traffic. again, IP traffic is not matched agains MAC acls, and vice-versa. #2.2.9.2.4 DHCP Snooping, IP Source guard, Dynamic ARP inspection. Carefully select trusted ports, and provide static ARP mappings where necessary. Plan verification of your future configuration, don't forget about option 82. #2.2.9.2.5 Port security, protected ports, storm-control. Remeber storm-control functions, and all port-security options as well. #2.2.9.2.6 dot1x authentication, VMPS. Watch for multiple-host option, and AAA configuration. By the end of this section, You should have ACLs writen in your notepad, and ports marked, according to security features, on VLAN diagram. Carefully watch for traffic you want to permit, you may need to adjust your acls on second pass. #2.2.10 QoS & PBR QoS is one complex task in real life, but in CCIE Lab it is secondary topic. On the other hand, there are so many options with QoS, that should just forget some of them. Try to use the most simple solutions here. I plan to write separate summary regarding QoS options. At first, you need to determine what class of QoS solutions you are required to do, and check out where you need to implement them: on routers or on catalyst switches. A short summary of QoS options is: #2.2.10.1 Router QoS #2.2.10.1.1 Classification & Marking. MQC & CAR, table-maps, policer/CAR markdown, FR commands. You can mark with policer/CAR too, set DE bit in several ways. Remember to rely on NBAR for classification if this is not prohibited. #2.2.10.1.2 Congestion Management and Avoidance. Fancy-Queueing, CBWFQ, LLQ, PQ, WRED, tx-ring. if CBWFQ, understand bandwidth options (priority, percentage, remaining) and additional features. CBWFQ may work with Fancy-qeueing on interface, but try to choose the most simple way of doing things, and don't complicate your solution. Remember WRED works per interface/per class, flow-WRED works on interface. #2.2.10.1.3 Regulating traffic flow (policing & shaping) MQC policing, CAR, GTS, CBTS, FRTS. VATS, CBTS may work with Fancy-qeueing on interface. You may change shaper's queue with nested policies, and you may have up to 3-levels of policer hierarchy. You may have multiple CAR entries on interface. You may use VATS to adapt to priority traffic, or you may use interface-congestion options with FRTS/MQC. #2.2.10.1.4 Signaling. RSVP, SBM. Remember how to enable rsvp sender/receiver, to verify you configuration. Remember to enable fair-queue, or LLQ for RSVP. #2.2.10.1.5 Link optimization cRTP, tcp header compression, link payload compression, LFI. Remember that you could compress in MQC now, remember voice-adaptive fragmentation. You could do FRF.12 with FRTS only, or enable fragmentation on interface, but not with MQC. #2.2.10.2 Catalyst 3550 QoS #2.2.10.2.1 Classification & Marking MQC (You could use only a single match in a class), IP/MAC acls, trust, dscp-mutation, passthru, per-VLAN classification, markdown. #2.2.10.2.2 Congestion Management & Avoidance WRR, PQ, WRED, buffer tuning, autoqos. Remember to use lowest possible weigths with WRR, and tune buffers in global configuration for FE interfaces. #2.2.10.2.3 Traffic policing Single-rate, Inbound & outbound. Outbound matches DSCP only. Per-VLAN inbound policing. #2.2.10.3 QoS measurements, IP SLA monitor. RTR, in older versions of IOS. RTT, Jitter measurement. May be useful to generate UDP traffic, and other ways to verify configuration. There could be some tricks with QoS, for example QPPB, so you should keep you eyes open, and watch for hidden task dependancies. As for PBR, you should plan route-maps and write-down skeletons for route-maps you want to use in your solution. Draw traffic-engineered routes on your diagram, decide where to place route-maps. #2.2.11 Mcast Two common problems with Mcast are: RPF failure, OLIST problem. Most often, those problem occurs on partial-mesh FR topoligies. RPF problems are usually solved with static mroutes, or IGP manipulation. OLIST problems are usually fixed with tunnels and sometimes adjusting Assert winners. Mcast highly depends on IGP configuration, so you may try to solve some mcast tasks, by adjusting IGP configuraion. This is why I find reasonable to put IGP domains on Mcast diagram. You will probably encounter only PIM configurations in lab, so let's take a look what may happen with PIM. Suppose you already have Mcast diagram (links & IGP domains, sources and receivers). #2.2.11.1 PIM Dense mode. Mark RPF interfaces on diagram, plan to solve possible RPF issues (which usually arise on multipoint FR interfaces). Two common ways to solve RPF issues are: tunnels, and static mroutes. OLIST problems may arise on the same multipoint interfaces, if spoke router wins assert. Adjust metrics/distances accordingly to fix assert problems. #2.2.11.2 PIM Sparse mode. Select method to RP information dissemination (BSR, AutoRP, Static). Place RP and BSR/MA on diagram, watch for possible RPF/OLIST issues with BSR/MA information delivery. if you need to choose RP point yourself, put it above, or exactly on hub interface, in H&S FR topology. The same goes to MA/BSR. Draw shared and SPT trees, mark RPF interfaces. You may use static mroutes to fix RPF problems with RP information, or, adjust IGP. Think of PIM NBMA mode on NBMA interfaces, that could solve OLIST problem. Remember, PIM NBMA works on broadcast interfaces too. Remember about SPT switchover, SPT may take different ways then shared tree, and you may encounter additional RPF/OLIST problems here. #2.2.11.3 PIM Bidir mode. You could also try to solve OLIST problems with Bidir mode, which permits router to forward data up the shared tree, towards RP. There are some more issues with multicast, you should remember of. #2.2.11.4 IGMP. State limiting, query filtering, and IGMP timers adjustement. You can use igmp static memberships for stub multicast routing. If you are not permitted to filter IGMP on router, try Catalysts. #2.2.11.5 IGMP Snooping on Catalysts. Static memberships,static mrouter ports, IGMP membership filtering, using IGMP profiles. You should also remember that Catalyst could act as an IGMP querier itself, or be a CGMP router/proxy. Remember MVR is also an option of multicast delivery, so check it in case nothing else comes in mind. #2.2.11.6 AnycastRP. You need to carefully plan which router picks what RP, setup MSDP and watch out for usual RPF/OLIST problems as with PIM-SM. #2.2.11.7 PIM-SSM. You need to setup proper IGMPv3 signalling, join (S,G), enable SSM range and that's all for SSM. Since there is no RP, you need not to worry about BSR/AutoRP. #2.2.11.8 Some more mcast options: mcast<->bcast conversion with mcast helper, stub multicast routing, unidirectional interfaces. At the end of multicast section, you now probably know all the caveats you may encounter in mcast. But be careful - it is not that easy to catch everything, you may get a false feeling of safety. You're finished with first pass of scenario analysis. You should have all diagrams completed by now, short plan in notepad, questions for proctor on separate list. Read your scenario for second time, resolving any questions you may had arreared on first pass. Correct redistribution tables, acls, introduce new interfaces, if needed. Basically, this is just a plan verification and naildown. If you have enough time, check DocCD for topics you are unsure about. After you finished your seconds pass, go visit the proctor. As you have questions already written in multiple-choice format, all you need to take with yourself is you scenario. Write down comments and any useful information you receive. Don't spend more then 10-15 minutes on proctor inteview. At that moment, you should not have any missed parts in your scenario analysis, and you could proceed to next step of your plan - Preparation and Implementation.