Archive for April, 2008
IPMA is yet another well-known CCM application that you may encounter on your CCIE Voice lab exam. While IPMA Proxy mode is clearly a legacy approach to configure this application its still a topic you could see in the lab. Before we discuss the configuration steps, let’s take a quick overview of a simplified model for IPMA Proxy mode operations. Refer to the diagram for IP Phone extension numbers.
The whole purpose of IPMA proxy is to intercept calls going directly to manager’s IP Phone primary line (“1001”), and proceed them using IPMA configurable call routing logic – usually divert calls to the assistant’s so-called Proxy line (“1112”). In other words, calls placed to manager phone, gets re-routed to assistant’s “proxy” line. Of course, manager has some control of the call-routing logic from it’s IP Phone, using special set of softkeys (plus a Web-interface for advanced configurations).
Now the whole idea of Proxy mode is to put the IPMA application in the call routing path between a caller and the manager’s primary extension. To accomplish this goal, manager’s primary line should be isolated into a separate partition – let’s call it PT_MANAGER. No other IP Phone in the system should have direct access to this partition – their respective CSSes should not contain this partition. Let’s name the CSS used by all IP Phones in the system as CSS_DEFAULT.
Now recall that IPMA is a Java application running in Cisco Tomcat server. IPMA uses CTI interface to control various call-routing components in the CallManager. Specifically, a CTI Route Point should be created in the CallManager system, and IPMA application should take control of it. Next, a “wildcard” extension “100X” should be associated with the CTI RP line and placed in partition PT_INTERNAL – the default partition used for all IP Phone lines within the system (Well, the DocCD recommends using a separate partition for the CTI RP – and indeed, this is a more flexible approach. However, for the sake of the configuration speed, it makes sense to use the minimum set of partitions). The “wildcard” extension number is actually used in configurations where many managers with the primary extension numbers in range “100X” should be covered with the IPMA application. If you are providing call coverage for just one manager’s phone, you can use “1001” here. Also, you may want to set the CFNA number to “100X” or “1001” – this will provide call routing backup in a case when IPMA application would happen to fail.
With the above configuration, when any phone in the system calls “1001” – the manager’s primary line, the call gets routed to “100X/PT_INTERNAL”, and eventually hits the IPMA application. At this point, the IPMA application may want to direct the call to the manager’s real line – “1001/PT_MANAGER” – and this is why the CTI RP should have a special CSS assigned, which has access to PT_MANAGER partition. Let’s name this CSS as CSS_IPMA. As a minimum, CSS_IPMA should contain PT_MANAGER and PT_INTERNAL – since the IPMA may need to redirect call to some other internal extension. (Note that “1001/PT_MANAGER” precedes “100X/PT_INTERNAL” when using CSS_IPMA. This order resolves the ambiguity, even in case when one assigns number “1001” to CTI RP).
To complete the picture, recall the proxy line on assistant’s phone. This is where IPMA application direct calls to by default. Since the assistant may need to direct the call back to manager’s phone, this proxy line should be configured to use CSS_IPMA as the Line CSS. With this setup, the proxy number “1112” is placed in PT_INTERNAL partition (so the CTI RP can reach it) and is allowed to call the manager’s primary line directly. Of course, the primary line of assistant’s phone (“1002”) has no special Line CSS configured, and will therefore hit the IPMA application when calling “1001”.
Per the recommended design, you should also create two intercom lines on both manager’s and assistant’s IP Phones. An intercom is simple a line, which has auto-answer with speakerphone turned on. On the opposite side, you just add a speed dial to reach the intercom number. Thus, you need to intercom lines plus two speed dials to accomplish the intercom configuration.
Now let’s move to the actual configuration. While CallManager has a special built-in IPMA Wizard, personally I’d prefer not to mess with it – unless you’re absolutely sure about what you are doing – the wizard will modify your partitions and CSSes, and may do that in the way you don’t expect. Configuring IPMA proxy mode manually takes a little more time, but once you understand it completely, it won’t take that much. Plus, you get full control of your configuration. So it’s a good idea to create your own IPMA configuration checklist, and use it during your practice. Here is how a checklist may look like.
1) Create Partitions & CSSes: PT_MANAGER & CSS_IPMA
2) Create CTI RP, assign extension number “100X/PT_INTERNAL” to it, set CSS_IPMA as the device CSS. You may also use “1001” extension to cover just one manger
2.1) Set CFNA to “100X” or to “1001” if you provide call coverage for just one manager. This will provide call backup if the IPMA application fails.
1) Create a new Button Template, say “3+3 7960” to allow more than two lines on an IP Phone. You will need this template for assistant’s phone, to accommodate three lines: primary, proxy and intercom.
2) Configure the Manager’s Phone
2.1) Set Softkey template to “Standard IPMA Manager”
2.2) Configure the primary line in “PT_MANAGER”
2.3) Add an intercom line, “*1001” and a speed-dial to “*1002” to reach the assistant
2.4) Create IPMA IP Phone service & subscribe the IP Phone to it (URL could be found on DocCD)
3) Configure the Assistant’s Phone
3.1) Set Softkey template to “Standard IPMA Assisant”
3.2) Set Button Template to “3+3 7960” (assistant needs extra lines)
3.2) Add a proxy line “1112/PT_INTERNAL” and set the Line CSS to “CSS_IPMA” for this line
3.3) Add an intercom line, “*1002” and a speed-dial to “*1001” to reach the assistant
1) Create a new user named “manager”
1.1) Allow it the use of CTI Application & CTI Super Provider
1.2) Associate this user with manager’s IP Phone
2) Create a new user named “assistant”
2.1) Allow it the use of CTI Application & CTI Super Provider
2.2) Associate this user with assistant’s IP Phone
3) Get back to “manager” user
3.1) Start the Cisco IPMA configuration dialog and disable automatic configuration
3.2) Configure the settings per your setup
3.3) Add a new assistant to the manager
3.4) Configure the assistant, matching proper primary manager’s line against the assistant’s proxy line
1) Choose Service Parameters for Cisco IPMA Application
2) Configure CTI Manager IP Addresses (primary/backup). In simplest case just use your Publisher IP
3) Configure IPMA Application IP Addresses (primary/backup). In simplest case just use your Publisher IP
4) Set the CTI RP name for the IPMA application
5) Restart the Cisco Tomcat Windows Service or go to Tomcat manager interface at http://[IPMA server IP Address]/manager/list and restart the service there
1) Check that manager’s phone has IPMA softkey set on it’s screen
2) Install the Cisco IPMA Console Application and log in there as “assistant”
3) Place a call to manager’s primary line, ensure it get’s routed to the assistant phone, and pick it up from the IPMA console. Forward the call back to manager’s primary line
4) Configure from the manager’s phone to accept all calls and place a call to manager’s primary line once again
Making checklists for complex tasks is a must when preparing to CCIE Voice lab. The above list suggests a simplified manual approach to configure all IPMA application settings, in the order specifically optimized for speed. However, if you are pretty much comfortable with the IPMA Wizard, you can use it for your setup. Just make sure you performed a thorough verification after that.
The final note is about interaction of IPMA proxy mode with the voicemail system. Since we isolate the manager’s primary line in separate partition, we need to make sure MWI CSS is able to access it, in order to light the MWI lamp. Make sure you wont forget about it, since this may cost you some precious points.
GLBP, an acronym for Gateway Load Balancing Protocol, is a virtual gateway protocol similar to HSRP and VRRP. However, unlike its little brothers, GLBP is capable of using multiple physical gateways at the same time. As we know, a single HSRP or VRRP group represents one virtual gateway, with single virtual IP and MAC addresses. Only one physical gateway in a standby/redundancy group is responsible for packet forwarding, others remain inactive in standby/backup state. If you have R1, R2, R3 sharing the segment 174.X.123.0/24 with the physical IP addresses 174.X.123.1, 174.X.123.2 and 174.X.123.3 you may configure them to represent one single virtual gateway with an IP address 174.X.123.254. The physical gateway priority settings will determine which physical gateway takes the role of the active packet forwarder. The hosts on the segment will set their default gateway to 174.X.123.254, staying isolated of the physical gateway failures.
GLBP brings this idea to new level, by allowing multiple physical gateways to participate in packet forwarding simultaneously. Considering the example above, imagine you need the hosts on the segments to fully utilize all existing physical gateways, yet provide recovery from a gateway failure. For instance, you may want 50% of outgoing packets to be sent up to R1, 30% to R2 and 20% to R3. At the same time, you want to ensure, that hosts using either of the gateways will automatically switch to another if their gateway fails. On top of that, all hosts in the segment should reference to the virtual gateway using the same IP address 174.X.123.254. This is a complicated task, which has being addressed by GLBP protocol design.
To begin with, we should recall that every host on the segment needs to resolve the virtual gateway IP address 174.X.123.254 to the MAC address using ARP protocol. When we use HSRP or VRRP, the ARP response will be the virtual MAC addresses, which is assigned to the active physical gateway. At this point, GLBP responds with different virtual MAC addresses of the physical gateways in the GLBP group. So the key idea with GLBP is accomplishing load-balancing by responding to ARP requests with different virtual MAC addresses.
Here are the implementation details. One of the routers in a GLBP group is elected as an AVG – Active Virtual Gateway. There is only one active AVG in a group, and its task is to respond to ARP requests sent to the virtual gateway IP address (e.g. 174.X.123.254) replying different virtual MAC addresses in response packets. The AVG will also implement load-sharing algorithm, e.g. by sending the replies in proportion to weights configured for physical gateways. Aside from AVG, the other logical component of GLBP implementation is AVF – Active Virtual Forwarder. Any physical gateway in a GLBP group may act as AVF – in fact all physical gateways are usually AVFs. Every AVF has a virtual MAC address assigned by an AVG and a weight value configured by an operator.
Now let’s discuss redundancy – the primary goal of any virtual router protocol. There are two logical entities used to build a GLBP group: AVGs and AVFs, and each of them needs a backup scheme. Since there is just one AVG per a GLBP group, the procedure is pretty simple: each candidate AVG has a priority value assigned; the highest priority router becomes an active AVG, the next by priority becomes a standby AVG. You may configure AVG preemption, so that a newly configured router with highest priority value becomes AVG, preemption the old one.
What about AVF redundancy? First, we need to understand that AVFs are always “active” in the sense that they are always used by a load-balancing algorithm. (However, by setting an AVG weight value below threshold, we may effectively take the AVF out of service. The weight value could be combined with object tracking to bring powerful traffic manipulation options). Next, with respect to redundancy, all AVFs backup each other. For instance, take any AVF: with respect to the other AVFs it is “Active”, and the remaining AVFs are in “Listen” state. If the AVF would fail, other gatewyas will detect the event using Hold timer expiration, and immediately try to take over the failed AVF virtual MAC address. Among the competitors, the AVF with highest weight value would win, and the remaining AVFs will switch back to “Listen” state. At this point, the “winner” will start accepting packets for two virtual MAC addresses: it’s own, and the one it has obtained from the failed AVF. At the same moment, two timers would start: Redirect and Secondary Hold. The Redirect timer determines how long will AVG continue to respond to ARP requests with the virtual MAC of the failed AVF. The Secondary Hold timer sets the amount of time the backup AVF will continue to accept packet for the virtual MAC address taken from the failed AVF.
This is basically how GLBP works. Different load-balancing algorithms are supported – the default one is round robin, with options for weighted load balancing and source-MAC based. The last one will always respond with the same vMAC to the same source MAC address, thereby defining sort of host-gateway “stickiness”. Now for a sample GLBP configuration, for the above mentioned R1, R2 and R3:
! ! We set load-balancing to weighted only on R1 ! So if R2 will become the AVG, it will use round-robin ! load-balancing technique ! R1: interface FastEthernet0/0 ip address 188.8.131.52 255.255.255.0 glbp 123 ip 184.108.40.206 glbp 123 preempt glbp 123 weighting 50 glbp 123 load-balancing weighted ! ! ! R2: interface FastEthernet0/0 ip address 220.127.116.11 255.255.255.0 glbp 123 ip 18.104.22.168 glbp 123 priority 50 glbp 123 preempt glbp 123 weighting 30 ! ! ! R3: interface Ethernet0/0 ip address 22.214.171.124 255.255.255.0 glbp 123 ip 126.96.36.199 glbp 123 priority 25 glbp 123 preempt glbp 123 weighting 20
Some show output:
Rack1R1#show glbp FastEthernet0/0 - Group 123 State is Active 2 state changes, last state change 03:12:05 Virtual IP address is 188.8.131.52 Hello time 3 sec, hold time 10 sec Next hello sent in 0.916 secs Redirect time 600 sec, forwarder time-out 14400 sec Preemption enabled, min delay 0 sec Active is local Standby is 184.108.40.206, priority 50 (expires in 8.936 sec) <-- Standby AVG Priority 100 (default) Weighting 50 (configured 50), thresholds: lower 1, upper 50 <-- <-- Should the weight go below thresh, AVF is taken offline Load balancing: weighted Group members: ca00.0156.0000 (220.127.116.11) local <-- Hardware MACs ca01.0156.0000 (18.104.22.168) cc02.0156.0000 (22.214.171.124) There are 3 forwarders (1 active) Forwarder 1 State is Listen <-- All other AVFs Listen to us MAC address is 0007.b400.7b01 (learnt) <-- Virtual MAC Owner ID is ca01.0156.0000 <-- This is R2 Redirection enabled, 598.928 sec remaining (maximum 600 sec) <-- <-- ARP replies with this vMAC are being sent by AVG Time to live: 14398.376 sec (maximum 14400 sec) Preemption enabled, min delay 30 sec Active is 126.96.36.199 (primary), weighting 30 (expires in 8.368 sec) <-- <-- The AVF reports it’s own IP as active Arp replies sent: 1 Forwarder 2 State is Active <-- Active mean it’s us 1 state change, last state change 03:12:45 MAC address is 0007.b400.7b02 (default) Owner ID is ca00.0156.0000 <-- R1 MAC address Redirection enabled Preemption enabled, min delay 30 sec Active is local, weighting 50 Arp replies sent: 1 Forwarder 3 State is Listen <-- All other AVFs Listen to us MAC address is 0007.b400.7b03 (learnt) Owner ID is cc02.0156.0000 <-- This is R3 Redirection enabled, 597.916 sec remaining (maximum 600 sec) Time to live: 14397.916 sec (maximum 14400 sec) Preemption enabled, min delay 30 sec Active is 188.8.131.52 (primary), weighting 20 (expires in 7.916 sec) Rack1R2#show glbp FastEthernet0/0 - Group 123 State is Standby 4 state changes, last state change 03:16:56 Virtual IP address is 184.108.40.206 Hello time 3 sec, hold time 10 sec Next hello sent in 0.236 secs Redirect time 600 sec, forwarder time-out 14400 sec Preemption enabled, min delay 0 sec Active is 220.127.116.11, priority 100 (expires in 9.148 sec) Standby is local <-- We are the standby AVG Priority 50 (configured) Weighting 30 (configured 30), thresholds: lower 1, upper 30 Load balancing: round-robin Group members: ca00.0156.0000 (18.104.22.168) ca01.0156.0000 (22.214.171.124) local cc02.0156.0000 (126.96.36.199) There are 3 forwarders (1 active) Forwarder 1 State is Active 1 state change, last state change 03:18:06 MAC address is 0007.b400.7b01 (default) Owner ID is ca01.0156.0000 <-- This is R2 Preemption enabled, min delay 30 sec Active is local, weighting 30 Forwarder 2 State is Listen MAC address is 0007.b400.7b02 (learnt) Owner ID is ca00.0156.0000 Time to live: 14398.644 sec (maximum 14400 sec) Preemption enabled, min delay 30 sec Active is 188.8.131.52 (primary), weighting 50 (expires in 8.636 sec) Forwarder 3 State is Listen MAC address is 0007.b400.7b03 (learnt) Owner ID is cc02.0156.0000 Time to live: 14399.260 sec (maximum 14400 sec) Preemption enabled, min delay 30 sec Active is 184.108.40.206 (primary), weighting 20 (expires in 9.260 sec)
Now let’s check how ARP redirection works:
Rack1SW1#ping 220.127.116.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds: ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 8/12/16 ms Rack1SW1#sh ip arp Protocol Address Age (min) Hardware Addr Type Interface Internet 22.214.171.124 0 0007.b400.7b01 ARPA Vlan1 Internet 126.96.36.199 - cc06.0156.0000 ARPA Vlan1 Internet 188.8.131.52 0 ca01.0156.0000 ARPA Vlan1 Rack1SW1#clear arp-cache Rack1SW1#ping 184.108.40.206 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 220.127.116.11, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 4/13/32 ms Rack1SW1#sh ip arp Protocol Address Age (min) Hardware Addr Type Interface Internet 18.104.22.168 0 0007.b400.7b02 ARPA Vlan1 Internet 22.214.171.124 - cc06.0156.0000 ARPA Vlan1 Internet 126.96.36.199 0 ca01.0156.0000 ARPA Vlan1 Repeat the above actions a few more times Rack1SW1#sh ip arp Protocol Address Age (min) Hardware Addr Type Interface Internet 188.8.131.52 0 0007.b400.7b03 ARPA Vlan1 Internet 184.108.40.206 - cc06.0156.0000 ARPA Vlan1 Internet 220.127.116.11 0 ca01.0156.0000 ARPA Vlan1 Internet 18.104.22.168 0 cc02.0156.0000 ARPA Vlan1
To summarize, GLBP is a virtual gateway protocol, with built-in load-balancing capabilities. Load balancing is based on manipulating ARP responses to the requests sent to the virtual gateway IP address. AVG role is used to load-balance and respond to ARP requests. AVF role manages one or more virtual MACs and is responsible for packet forwarding. AVG redundancy is controlled by GLBP priority and AVF redundancy is implemented using AVF weight value and two additional timers.
IPv6 NAT-PT is to be used with IPv4 to IPv6 migration scenarios and it’s purpose is to provide bi-directional connectivity between IPv4 and IPv6 domains. Cisco points out that many other transition techniques are possible, and NAT-PT (Network Address Translation – Protocol Translation) should not be used when other, more “native” options exist, such as having dual stack hosts communicate directly through dual stack routers. Another example provided of when NAT-PT is not needed is when two islands of IPv6 want to communicate over an IPv4-only backbone. We know that many different tunnels exist for this purpose. For more information about these tunnel techniques, see the Transition Technique series in this blog category.
For the job of NAT-PT, a dual-stack router with interfaces in both IPv4 and IPv6 networks is capable of performing this task. The difference from classic IPv4 NAT is that translations should be done both ways: IPv6 packets routed towards IPv4 hosts should have their src/dst addresses changed to some IPv4 equivalents and vice versa, while IPv4 packets sent toward IPv6 hosts should get both src and dst addresses replaced with IPv6 addresses.
There are a lot of rumors floating around in regards to diagrams in the R&S CCIE lab. Cisco officially has said little in regards to this other than the following “the lab document has L1/L2 diagrams for the physical connectivity as well as an IP or topology diagram and an IP Routing diagram”. This is similar to what we provide in our labs but I would venture to say that they don’t take the time we do to ensure that they look as nice as ours What Cisco and we do not provide is a true layer 2 “logical” diagram but Cisco and we do provide is a physical diagram of the connections in the lab. A physical diagram is not the same as a logical layer 2 diagram. A logical layer 2 diagram will include the VLAN assignments, trunks, EtherChannels, dot1q tunnels, VTP and possibly spanning tree information like root bridges, root ports, designated ports, etc. The choice to draw out the spanning tree information will really come down to the lab itself. If there are a lot of tasks that relate to spanning tree or layer 2 traffic engineering (i.e. traffic for VLAN 100 should transit SW3, etc) then adding the spanning tree information will help answer these types of tasks.
The logical layer 3 diagram will be provided BUT the diagram they provide may not have the level of detail you want or need plus you can not write on the diagram they give you. Technically you can write on it but they will suspend you from the lab for one year We ALWAYS recommend making your own layer 3 logical diagram. You should also draw out the diagram for every practice lab you do. Do not wait until the real lab to draw out your first diagram. As I have said before you never want to do anything in the CCIE lab for the first time other than get your number
There are two main benefits to making your own logical layer 3 diagram. First off you will find it is easier to remember what the network looks like when reading the tasks and secondly you will be able to draw and/or take notes on your own diagram. Smart people fail the lab all the time because they make stupid mistakes in the lab and by drawing out the network you will hopefully lower the chances of making these stupid mistake (i.e. configuring RIPv2 on the wrong interface, applying an ACL inbound on one interface when it should have been outbound on another, configuring a feature on the wrong router, etc). All it takes is two or three of these little mistakes and you have lost 8 or 9 points in the lab. We all know that it is hard enough to pass the lab without adding in stupid mistakes into the mix You will also find tasks related to BGP to be easier to answer when you have a diagram that you can take notes on (i.e. who is peering with who, which exit point to use to reach another AS, etc). It is possible that when you get into the lab that basic BGP is done for you. It is normally easier to work on a network that you built from the ground up so working on a network that is 50% complete without first taking the time to discover and document what is already done will be harder.
I am sure someone will comment on this and say, “but I won’t have time to draw out the network in the real lab”. If this is the case you should not be in the lab in the first place. If it is taking you the full 8 hours to just configure the network you more than likely will not pass the lab to begin with so taking the 10 minutes to draw out the network is not going to really matter in this case. The percentage of people who pass the lab while configuring the network for the full 8 hours is slim. Most people who pass the lab complete the lab within 5.5 or 6.5 hours and have the extra time to do the diagram in the beginning.
First off be sure to arrive at the lab at least 15 minutes early. I’ve done both arrived early and arrived late. I can tell you from personal experience that arriving early is the best option. When you arrive you will be waiting in the lobby until the proctor comes out to escort you into the lab. When you get into the lab the proctor will give you a quick introduction before starting. This introduction will cover the facilities (i.e. restrooms, break room, etc), the start and stop times and then the proctor will normally ask if anyone has any questions before starting. If you have any general questions I would recommend that you clear them up with the proctor now. For any questions related to the lab itself (i.e. do I need to ping myself over Frame Relay) I would recommend that you wait until you read over the lab before asking as most of these types of question will be answered in the lab itself. After this introduction the lab will officially start. You can now go to your assigned seat and start the lab.
Bring earplugs (the small disposable type) as the lab can in some locations be a little noisy (routers and switches buzzing, phones ringing from the voice racks, etc). Dress in layers (i.e. light jacket or sweater) so that you can remain comfortable. Leave your cellphone, pager and any other electronic devices at your hotel or in your rental car. If you do bring them with you to the lab they will have a place for you to store them. This also holds true for your luggage. If you are going to the airport after the lab you can bring your luggage to the lab and they will have a place for you to store it during the exam. You may want to bring a certain drink or snack. Officially the policy is that you can not bring anything into the lab but normally the proctors will allow you to bring a drink or snack in. If you are taking the lab in RTP the lunch will be catered. You will not have a big choice as to what to eat. This being the case you may want to bring your own lunch if you are a very picky eater or on a special diet. Personally I’ve found the food to be just fine but to be honest what’s for lunch in the lab is the least of my worries as it should be for you.
But before even stepping into the lab you should have a detailed plan. This plan should include what you are going to do when you first arrive. Below is my recommended plan as to what to do when you first arrive in the lab.
1 ) After taking your seat remove the lab and diagrams from the binder. You don’t want to be flipping through the binder all day. The pages themselves will be in plastic sheet covers. Do not remove the pages from the sheet covers. I normally make two stacks for the lab material. One for the pages I haven’t completed or am still working on and the other the pages I have completed.
2 ) The pencils (colored and regular) and pens that they supply will be on your desk. Pick out the ones you will be using and sharpen any if needed. Since they are supplying you with the colored pencils you may end up with different colors then you are used to. This being the case don’t use the same colors all the time and mix it up a little between labs. Now you may try to bring your own colored pencils into the lab and sometimes the proctor will allow them but the official policy is that you can’t bring them in. In that case just use whatever they are supplying and don’t worry about it. But if you feel you can’t pass the lab without your own “magical” set of colored pencils you may want to stop preparing for the lab now and just use your $1400 for a good psychiatrist
3 ) Draw out your own diagrams. Drawing out your own diagrams has two big advantages. First off, you can’t write on the diagrams they give you without being suspended from the lab for one year. By being able to write on your own diagram you can make lots of little notes when working through the lab. Secondly by drawing out the network it will help you learn the network and remember what the network looks like when reading the tasks without the need to repeatedly look back at the diagrams. I can’t tell you how many people I see during the mock lab classes make little simple mistakes like configuring a feature on the wrong device or on the wrong interface. Just one little mistake like this can be the difference between passing or failing.
4 ) Take a quick read over the entire lab to get a general idea of what you are going to be doing throughout the day. Don’t spend time trying to figure out the solution to each task but just get a feel for what they are looking for. You may also find that the order they give you the tasks in is not the ideal order in which you should do the task and you want to figure that out now. I see people in the mock lab workshop make the mistake of just starting with the first task without reading over the lab. By doing this they run into issues when a solution they implemented in an earlier task causes problems with a later task.
5 ) Now log onto your rack using the Windows XP PC provided. You will have shortcuts on the desktop to your devices. By just click on the SecureCRT shortcuts on the desktop you can connect either to the console of the access server or the individual lines. This is the same way we have our rental rack access setup. If you connect directly to the console of the access server you can then reverse telnet (i.e. R1, R2, etc) to the console of the devices. If you want to connect directly to the device’s consoles you can do so but be forewarned that you will need to have ten SecureCRT windows open. Newer versions of SecureCRT support the concept of tabs but the version of SecureCRT in the CCIE lab will not support tabs. This means that you shouldn’t use tabs during the last month or so before your lab date if you plan to connect to the devices directly. Personally I think that working with ten windows is awkward to say the least but it’s going to boil down to a personal preference.
6 ) Now that you are connected to the devices in your rack take a quick minute to ensure that the initial configurations loaded on them match the diagrams provided. To do this just compare the IP addressing on your devices with the ones on the diagram to ensure you have the correct initial configurations loaded. Although rare it does happen that someone either gets the wrong lab or initial configurations loaded.
7 ) Next open three Internet Explorer windows. The first one for the IOS 12.4 documentation, the second one for the 3550 documentation and finally the last one for the 3560 documentation. Do not expect to have a version of Internet Explorer that supports tabs. If the administrative privileges on the PC do not allow you to open multiple instances of Internet Explorer you can go to the one that you could open and then do “File->New Window”.
8 ) Using one of the scratch sheets of paper that they give you make a quick table with the following columns: Task, Point Value and Notes. Use this to document your progress as you do the lab. Also note on here when you complete each section. Include the number of points you achieved in the section, the total points you feel you have and the time you completed the section. Remember that time is not your friend in the lab so you need to make sure don’t loose track of it and you know exactly where you are in the lab at all times.
9 ) If you want to apply additional configuration (alias, logging synchronous, etc) create them in notepad now. Then paste them into the devices. A few I personally would recommend are below:
a) clock set (set the clock on all devices if they are not already set)
b) ensure the logging level for the console is set to debugging
c) logging buffered
d) ip tcp syn-wait 5
e) no ip domain-lookup
f) line con 0
history size 256
Personally I don’t use aliases other than the default ones in the IOS but its a personal preference.
Do not take more than 30 to 35 minutes to get to this point. You should be ready to start the lab now. In the next part I will cover getting up to full reachability in the lab exam.
The scoring in the CCIE lab is done on a per task basis and not a per section basis. If you do not pass the lab you will receive a breakdown of how you did by section (i.e. IGP, Multicast, etc) but they will not give you a breakdown on a task by task basis. The logic behind this is that the CCIE exam is designed to be a testing tool and not a learning tool.