There was some interest in me writing about my lab experience. Naturally yesterday I felt devastated after the results coming back. I feel a bit better today but it still hurts but I’m planning my revenge as we speak. This post will describe the experience and point out some lessons that I learned by taking the lab.
My lab journey starts at Landvetter which is the airport of Gothenburg. I arrived there 15:45 which left plenty of time until my plane was leaving at 17:30. When I arrived I noticed there were a lot of police officers and when I was going to walk into the area for international flights and was stopped and they said I should go to the area for domestic flights instead. I did not reflect so much about it but when I got to the domestic area I saw there was a tonne of people and started to realize that something was wrong. I tried to talk to people working at the airport and they told me that they had found a suspicious bag that someone had forgotten. Probably only a honest mistake but they took every precaution possible. Instead of leaving at 17:30 my plane finally left at around 20:30. I was supposed to arrive 19:30 in Brussels but arrived about 22:45 instead. Lesson learned: Leave more room for incidents when flying, next time I’m going mid day or morning instead.
I finally arrive in Brussels and get my bag and then I walk to the area where the Taxis are. I try to get a taxi but the driver says that there are shuttles available to the hotel downstairs. I walk down to the shuttle area and find a timetable only to realize that the last one had already left. I go back upstairs again and try to get a Taxi. The driver does not want to drive such a short distance to the hotel (4km). I’m starting to get really stressed out by now.
I phone the NH hotel and ask them and they send a taxi for me. It takes about 20 min before it arrives and at around 23:45 I finally arrive at the hotel. I check in and go upstairs to the room. Naturally by now I’ve had a really bad day and I am feeling really stressed. I am worried that I will not get enough sleep for the lab. I try to relax but it’s not that easy and the AC in the room is making a lot of noise so I can’t go to sleep. I finally leave bed and turn it off and at around 01:00 I go to sleep.
I wake up at 06:30 and then I meet Gavin for breakfast at 07:00, he is a new friend which I found on IEOC(congrats on pass). We leave the hotel at 07:45 to go to the lab. Gavin had checked out the location the day before so everything should be cool. At around 08.10 we are surprised to not see any other candidates and also no Cisco employees. We realize that we are in the wrong location. We were at the back of the Cisco main building, this is not the lab location! The lab location is one building further away close to DHL. You will pass a bridge when you are at the right location.
We arrive there at 08:15 and sign in at the reception. We see a few other guys waiting in the sofa. Shortly after the proctor arrives. We take the elevator up to the lab location. The proctor tells us what rack we are assigned and we sit down. We have to leave personal belongings like wallets and phones in a locker and only bring identification to our allocated seat. We get two laminated papers with general instructions for the labs. The proctor gives a brief description and what times we will break for lunch etc.
The troubleshooting begins. The troubleshooting section is 2h with about 10 tickets to solve. It is a bit stressed for time but by my count I had solved 9 tickets or at worst 8 which should be good enough to pass that section. The TS section is totally virtualized running IOU for both routing and switching. There is about 30 devices and every tickets shows you whereabout the error can be. This will be everything from 2-3 devices to about 8-10 devices. When I got my score back I was surprised to see I had a much lower score than expected, unfortunately I don’t know why.
Then the configuration section began. I read through the entire lab at first trying to pick up dependencies and stuff like that. I saw a few things that needed some attention. I then started working on the configuration. When we went to lunch I had almost finished layer2. For my next attempt I want to be finished with IGP at this stage. The lunch was your average lunch except that nobody was talking very much. I tried to use the time to think about a task that I had for the l2 section. This actually helped and gave me some extra time to think about it.
We went back from lunch and back to the configuration. I got stuck on some tasks that I usually do very quickly otherwise, clearly it must be nerves. Finally I had a working IGP and redistribution and started testing with TCL script and macro. I was nervous so at first I could not get the TCL syntax correct, this is what nerves will do to you. Finally I got it right and I had full reachability.
I went on with some other tasks. I got stuck on some things for too long. Next time I will try to move along faster and then go back later if there is time left. When there was about 45 min left I still had lots to do and started to realize that I would probably not pass. I went into do or die mode, I’m not going to give up now, I will give it a final push and at least try my best. I configured like a mad man the last 45 min and did a lot of tasks. Unfortunately I probably got a lot of stuff wrong since I was in such a rush and did not have time to verify properly.
When time was out I still had 3 tasks I couldn’t solve. I realized that I probably had failed but still had some hopes. The lab I got was very advanced with some features I did not expect to see so heavily tested. I really can’t say more than that. The lab is about details and veryfing, I got too stressed for time and lost a lot of points due to this. I will have to spend my time better next time. I will also try to practice on scenarios where the goal is to go from scratch to IGP full reachability in as short time as possible.
We go back to the hotel at around 17:00. Gavin and I share a couple of beers. He feels he did well on the config but I felt I probably did not have a chance. I spend the evening in the hotel and try to catch some sleep early but I just could not go to sleep. Finally at 01:30 the e-mail from Cisco is in my inbox. I thought the result would be in the e-mail but you need to login to the portal to see your result. To login there you need your Cisco candidate ID, written track, written date and written passing score. I was able to get all information from Pearson Vue and Cisco certification tracking system except for the written score. I knew the first two digits of the score and tried a couple of times before I got it right.
I saw the fail and then the percentages and my world pretty much came to a stop. I was devastated and just wanted to stop studying, quit my job and go into the woods or something. I got home to Sweden in the morning and felt crappy all day. Later in the evening I started feeling a bit better and now I’m building up my motivation to go for a 2nd attempt. I will probably go again in a couple of months.
One other mistake I’m definately guilty of is asking too few questions. I did go to the proctor a single time, I just got stressed and it’s easy getting glued to your chair in those situations. I will not make that mistake again. I tried to keep my sugar levels up by eating some bananas and chocolate at the lab, this worked fairly well. You are allowed to bring some snacks in if you want to. There will also be coffee and water available to drink. I only drink water but if you drink Coffee don’t overdo it. You don’t want to be running to the toilet every 5 min.
That is my story and the next time I write one I hope to have some better news. Thanks for reading.
I’m home from Brussels now, unfortunately without a number. I got a very difficult lab and a rough time coming into the lab since my flight was delayed several hours due to a bomb threat at Landvetter, Gothenburg.
Right now I don’t have much motivation but I’ll get back on the horse as soon as I can.
Did a final mock before lab and barely failed. I got 71/100. To my defence I did loose at least 3 points due to a bug. I had BGP configured correctly but session would not come up, BB was expecting other AS then the one I was coming from but SG had the same solution.
The TS section had some very stupid tasks. I hope I don’t have to see anything like that on the lab.
The config section went pretty well but lost some few points due to bug and a few points from reading the tasks wrong. I need to cut down on those definately. Everything has to be taken literally. If it says that put interface x in OSPF with /64 mask for IPv6. Then you need to see it as /64 so if it is a loopback you need to announce it as point-to-point.
Good news is I pretty much nailed IGP and redistribution went according to plans. Full reachability! I was also able to finish all tasks on time so I’m at least on the right path.
I’ll post more next week.
Continuing to check things off from the blueprint. Did some ZBFW labbing today. Here are some important stuff to be aware of.
ZBFW is basically a wrapper for CBAC. We create policys between zones and assign interfaces to zones instead of applying CBAC rules to interfaces.
By default all traffic to the self zone will be allowed (router from and to router itself). If we apply policys to self zone then everything is dropped except for the traffic that is explicitly permitted. We need to be aware of this to not mess with the routing if we get such a task at the lab.
The self zone can only inspect TCP, UDP and ICMP but not protocols like telnet and SSH. To work around this we can do a class-map matching an ACL AND the protocol TCP if we are matching telnet traffic.
It’s not very intuitive to see which traffic is dropped. We can turn on logging with ip inspect log drop-pkt. This helps a lot to see which traffic is being dropped.
ZBFW is massive in configuration, you will be typing a lot. It is easy to get confused and mix things. Name things intuitively, name class-maps CM_INSIDE_PROTOCOLS, name policy-maps PM_INSIDE_TO_OUTSIDE or names similar to that. If you don’t you will easily get lost after a while due to the massive config.
Packet counters for ZBFW can’t be trusted, this seems to be due to a bug. Verify by pinging or telneting to create traffic.
Use Notepad when creating the config, it is faster and less prone to errors.
All traffic flows are unidirectional so we need to create zone pairs for both directions depending if we want traffic to flow both ways.
We can have three different actions for traffic in the policy-maps.
Pass – Traffic gets through but not return traffic is permitted. Useful for “stateless” protocols like RIP
Inspect – Allow traffic through and also allow the return traffic back.
Drop – Drop the traffic
If we have a policy-map that allows some traffic through, the rest of the traffic not matching any class will be implicitly dropped, this is even if we don’t specify a class class-default.
That are the most important things you need to be aware of when configuring this feature.
To enable AAA we need the AAA new-model command but what does it really do? Many of us makes assumptions about this command.
By default if we have an empty config then we will be able to use the console and get straight into enable mode (priv15). If we try to telnet in (VTY) then we can’t login since no password has been set. If we set a password then we can login to priv 1 but we won’t be able to enable since no enable password has been set.
When configuring AAA we use method lists. We can use the list called ‘default’ or create our own. The sneaky thing about aaa new-model is that when we enable this the ‘default’ list goes active which is applied to the VTY. What surprised me is that this is not applied to the console. Someone had a theory that Cisco wanted to apply it to both console and VTY but too many users got locked out of their routers so they had to back on this implementation, true or not, I don’t know.
When aaa new-model has been enabled the device will ask for local authentication. If we haven’t defined any users then no access for you (VTY-nazi). Console will still work though, we will have to enable to enter priv 15 as usual.
Now if we define a user we will be able to login remotely as well, we do need to configure an enable password to get into priv 15 though.
For the lab I have seen that if people get a task with AAA they will create a new method list with no authentication and no authorization and apply it to the console and VTY. As I pointed out we should not have to enable this to the console but better safe than sorry I guess. This can be configured in the following way:
aaa authentication login VTY none
aaa authorization exec VTY non
line con 0
login authentication VTY
authorization exec VTY
line vty 0 4
line authentication VTY
authorization exec VTY
How would you configure this, what do you do in real life? Post in comments.
I’m going through the blueprint and now I checked off IP accounting. The feature is very simple, it lets us see which source destination pairs that are sending traffic to each other. We can also configure to look what precedence values that are in the packets. There is also an option to look at the MAC-addresses of the packets passing through and also packets that are being denied by an access-list. The topology is dead simple, see below.
Configure your routing protocol of choice to get reachability. I’m using OSPF, it does not matter at all as long as you have connectivity. Now lets say that we are interested in which source and destination pairs that are sending traffic THROUGH the router (transit). Packets destined TO the router will not be seen in the accounting. I’ll configure accounting on R2′s interface to R1 and then initiate a ping from R1 to R3. I’ll send traffic both to the loopback and R3′s FastEthernet interface to see two different source/destination pairs.
OK, lets ping.
Now we will check the accounting database with the show ip accounting command.
So that shows us what sources/destinations are sending traffic to each other, interesting! We can also see the number of packets and number of bytes. If we want to check statistics for only certain hosts we can use the global ip accounting-list command to define what hosts we are interested in. We define hosts/networks as in ACL with network/wilcard combination.
Storing entries in the IP accounting database requires some memory, there could be a risk of exhaustion if we have too many entries but the default is set to max 512 entries. We can define this with the global ip accounting-threshold command.
So now we want to check what IP precedence values pass through our interfaces and also what MAC addresses that are sending/receiving traffic. Lets configure this.
Then we send some pings from R1, I will send with a ToS of 128, what IP precedence/DSCP is that? Think quick.
Lets verify at R2 if we see anything, the command to use is show interface precedence.
So a ToS of 128 was a IP prec of 4 but you already figured that, right? What is that traffic with IP prec 6? Mysterious…We are running routing so that is OSPF which is marked with an IP precedence of 6 automatically by the router itself. We can also check what MAC addresses have been learned.
Here we also see OSPF represented by the MAC address 01-00-5E-00-00-05. We can also see when the last packet was sent which is quite handy. Now we will turn on accounting for access-lists as well, first we will define an ACL denying ICMP to 22.214.171.124 which is the loopback of R3. Note that we need the log keyword in the ACL.
Now we send traffic from R1 to 126.96.36.199.
For some reason I don’t see anything with the show ip accounting access-violations. Maybe this is a software issue? I tried turning off CEF as well. If any of my readers get this working I would be interested.
Lastly lets have a brief look at how traceroute works in IOS. Cisco devices uses UDP traceroute compared to ICMP used by Windows. The router sends packets with TTL of 1 and then N+1 the further away the probe goes. Traceroute sends three packets for every hop. The first hop will have a destination port of 33435, the second one will have 33436 and so on. If we want a router to not respond to traceroute we can turn off IP unreachables. Note that this will not hinder traceroute for which this router is not the final destination. Only the final device will send an ICMP unreachable (port unreachable) which is ICMP code 3. The other routers will send time exceeded which is ICMP code 11.
If we did want to block traceroute going through the router we could block this with an ACL denying packets that have ttl-exceeded or all packets lower than a certain TTL. If we need to find ICMP codes we can reference the ASA library. This should be available at the lab. You can find the reference by following this path.
Products > Security > Firewalls > Firewall Appliances > Cisco ASA 5500 Series Adaptive Security Appliances > Configure > Configuration Guides > Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 > Reference > Addresses, Protocols, and Ports > ICMP types
So this is just another feature that is handy to have.
Lab is coming up real fast now. I am checking off boxes in the blueprint for the stuff I feel comfortable with. I have maybe 70% checked but some of the stuff I want to revisit is QoS, multicast and a few filtering scenarios for routing and also NAT. There are also a few services that I want to check briefly in case I get them at the lab.
I don’t feel 100% prepared but I do feel that I do have a chance if everything goes well. All I can do is my best. I will also review a few labs down the final stretch. The last few days I will try to keep my brain fresh instead of cramming by only doing light review and by visiting the gym.
These topics are probably not very likely to appear at lab but it still good to at least have seen them once so you don’t get stumped if you should get a task like that at the lab.
Frame relay multilink (MFR) is defined in FRF.16.1 as defined by The Frame Relay Forum. See this URL for complete specification.
The basic idea is to take several frame-relay interfaces with the same DLCI and bundle them into one logical interface. Kind of like an Etherchannel. The reason I write this post is that the DOCCD isn’t really intuitive for this topic and there does not seem to be a lot of documentation how to configure this rather simple feature.
I will be using a simple topology where router R1 is dually connected to R2 and R3 is also dually connected to R2. R2 will be acting as the frame switch, we could have used a separate frame switch in Dynamips but this is a bit more fun and shows how to configure the SP side as well.
The configuration on the customer side is rather simple. First we create the logical interface which is named mfr and then a number. We will use number 1. All configuration like IP address and access-lists or anything like that goes to this interface.
Then we have to define which interfaces are part of the bundle. This is done with the encapsulation frame-relay mfr command.
Then we do the same thing on the other side but with a different IP address of course. Then we can verify that the link is up with show frame-relay multilink. We verify with a ping.
If you want to check that both links are being used then you can clear the counters and then do a ping. The number of packets should be equal or close to.
This is how a show frame pvc looks.
Note that the multilink interface is shown here instead of the physical interfaces. The MFR interface works the same way as a regular frame relay interface. Since I’m using a physical interface all DLCI’s will be mapped to it automatically and inverse ARP is used to resolve the remote layer 3 address to the local DLCI.
We also have the option of running the MFR interface on a subinterface, both as multipoint or point-to-point. Multipoint does not really make sense in this case but it can be done. The regular rules apply, if using multipoint we can either use a frame map statement or the frame-relay interface-dlci and rely on inverse ARP. For point-to-point interfaces we just use the frame-relay interface-dlci command as usual.
Now to the configuration of the FR switch. We enable frame-relay switching as usual. The configuration for the MFR is the same as for the customer side but we need to define that this interface is DCE and then we have the frame-relay route statements which map to the MFR interfaces instead of physical interfaces.
This is the configuration of R2.
Now we will look at MLPPPoFR which is another way of doing bundling of links by using PPP. First we start with the basic configuration. We bind the DLCI’s to the virtual template.
We do the same configuration on R2 and then we will configure the virtual-template to use multilink functionality.
You will see that several virtual-access have been created. We can verify with show ppp multilink command.
That is basically it. Now you know how to configure FRF.16 and MLPPPoFR.
So I’m going through the blueprint checking off everything before the lab. I know FR pretty well by now but there are always some details you forget. As I was going through FR again I thought about possible failure scenarios and restrictions that could be used at the lab. Here is a sample task I thought of.
Router R1 is running frame-relay on interface serial0/0. Via LMI 4 PVC’s have been learned, DLCI 102, 103, 104 and 105. Disable inverse ARP for all DCLI’s except 102. Do not use the no frame-relay inverse arp command. For this task you are allowed to create an additional interface.
Post solution in comments.