Wednesday, December 31, 2008
A very interesting problem occurs because we're using MPLS VPNs. Remember that a MPLS VPN packet contains an IGP label and a VPN label. The situation encountered is as follows:
................AS1. AS2 ..............
The 2 BGP-ASBR P routers do not run MPLS on their neighboring interfaces. If we were not running VPN, the BGP-ABR router could simply pop the label, do an IP lookup, and then forward the packet to the next router.
But since we use VPN, when the BGP-ABR router pops the label, it now has a VPN label which it does not understand. Therefore, it must drop the packet.
To alleviate this, we need to ensure a single label switched path exists across both AS's.
This is accomplished with the neighbor send-label command.
Tuesday, December 30, 2008
After playing with enough debug commands, I finally came across the following:
R2#debug ip bgp vpnv4 uni upd
*Dec 31 03:03:41.943: BGP(2): 184.108.40.206 rcvd UPDATE w/ attr: nexthop 220.127.116.11, origin ?, localpref 100, metric 0, extended community RT:1:100
*Dec 31 03:03:41.943: BGP(2): 18.104.22.168 rcvd 1:100:10.1.37.0/24 -- DENIED due to: extended community not supported;
Huh? What does it mean extended community not supported?
As it turns out, extended communities, by default, are not accepted from eBGP peers. This is the first lab that I've tried to exchange vpnv4 routes across eBGP, so it's the first time I've run into this.
The command to enable extended communities across eBGP peers is no bgp default route-target filter. The details can be found here.
Prior to this lab, the general rule has been to only peer bgp vpnv4 with PE routers. But in this lab, two separate bgp ASs are peering separate vrf's over separate interfaces. Rather than two providers sharing routes over vpnv4, they split them over the interfaces as ipv4 neighbors.
So it actually ends up with each provider's edge router actually acting like a CE router and a PE router at the same time. Each provider is each other's customer.
I guess this is what back-to-back VRF means. Rather than sharing the vpnv4 information across bgp, we strip the rd information out, but dedicate a subinterface for each vrf. Then on the other side of the link, the router loads the routes back into bgp and reconstructs the vpnv4 routes.
Why do it this way? One reason seems to make sense--what if you need to carry MPLS VPNs across separate providers but each provider is using different route descriptors? This would allow each provider to load their own rd when the routes are imported. If vpnv4 routes were shared, rd's would need to be consistent across the entire path.
Monday, December 29, 2008
There really wasn't anything particularly challenging about this lab, there was just a lot going on. It's definitely required to build each piece step by step and verify along the way. A simple missing mpls adjacency, ospf neighbor, or bgp next-hop-self missing could make troubleshooting really difficult.
The mpls verification was quite interesting. On the PE routers, a separate MPLS adjancency is actually formed inside of the vrf. To check this, the commands sh mpls ldp neigh vrf VPN_A and sh mpls for vrf VPN_A are required.
Aside from that, I had to go back and do a couple of redistribute connected's into bgp. This was required so that I could ping from the outgoing interface rather than the loopback of the true customer routers.
Essentially, the configuration ends up with two separate route reflectors--one for ipv4 routes and one for vpnv4 routes. Amazingly, no real complex configuration is required. There's no need to mess with clusters or anything like that. Instead, simply configuring the route-reflector-clients under vpnv4 instead of directly under the bgp process takes care of it.
I did run into two issues due to simple mistakes. First, one of my PE routers showed all MPLS labels as being untagged. This was due to me forgetting to turn on cef on one of the P routers.
Second, one of my CE routers was not learning any RIP routes. This issue actually threw me for a loop for a bit. It turned out that on the PE router I didn't set RIP to version 2 under the appropriate address-family. By default, rip sends version 2 and receives versions 1 and 2. But when version 2 is specified, rip only sends and receives version 2.
Since the PE router did not specify, it received the version 2 routes from the CE router and entered them into the routing table. It also redistributed its bgp routes into RIP and sent them as version 1.
Since the CE router specified version 2, it ignored the version 1 routes sent by the PE router.
Wednesday, December 24, 2008
But since these remote sites are likely to be within one company's control, having them marked external may not be the best option. Instead, the domain-id can be used on the PE router under the ospf process. When the PE router advertises the ospf route to the CE router, it looks at the domain ids of both routes. If they match, the ospf route is advertised as an inter-area (IA) route instead of an External route.
This seems like it would be important for a couple of reasons. IA routes are always preferred over E routes. Also, E routes are not advertised into stubby areas, while IA summaries are. In more complex scenerios with a mix of nssa areas and redistribution, a company may prefer to use its provider's MPLS network rather than another non-MPLS link. The domain-id allows for this much easier than filtering routes from the edges.
Tuesday, December 23, 2008
I was really amazed at how easy it is to configure a simple instance of isis. Just configure a net address and throw isis on the interfaces, optionally set the interface type, and it's complete. No issues there.
OSPF sham links, on the other hand, I found to be a a much more complicated subject. Its purpose is to deal with a customer that has non-MPLS links neighboring via OSPF, yet the customer still wants to route this traffic over MPLS.
Once these OSPF routes hit BGP, they are seen as iBGP routes, which as an AD of 200, as opposed to the OSPF AD of 110. This means if the prefix-length and default AD is the same, the OSPF route is going to be entered into the routing table.
To prevent this, an ospf sham link must be created. This is configured by setting up an additional loopback interface on the PE router and adding it to the customer VRF. Next, these loopbacks need to be redistributed into the bgp ipv4 vrf. Once the loopbacks are reachable to each other via the P network, under the ospf vrf process, enter area 0 sham-link source-ip dest-ip. This, somewhat similar to a virtual-link, creates a logical link between the newly created loopback interfaces. Then, the path is seen via ospf rather than bgp and the MPLS route can be preferred over the customer link.
Monday, December 22, 2008
Already completed: Volume 1 MPLS VPN labs.
Week of 12/21: Remaining Volume 1 MPLS labs.
Week of 12/28: Volume 1 Multilcast labs.
1/4: Volume II lab 1
1/11: Volume II lab 2
1/18: Volume II lab 3
1/25: Volume II lab 4
1/31: Volume II lab 5
2/1: Volume II lab 6
2/7: Volume II lab 7
2/8: Volume II lab 8
2/14: R&S Graded Mock lab
2/15: Volume II lab 9
2/21: CCIE Assessor R&S
2/22: Volume II lab 10
2/28: R&S Graded mock lab
2/29: Repeat of one of the Volume II labs
So this puts me taking the lab sometime in March. Hopefully I can find a date around there. I'm still waiting for my exam to clear the CCIE site so I can see what dates are available. I should know within the next day or two.
There are only 10 full Volume II labs in the Internetwork Expert labs, as opposed to 20 in the R&S curriculum. I wouldn't expect this to be too much of a problem since I really only went through 10 of the full workbook labs for R&S anyway.
That leaves 3 main gaps to cover. In R&S I relied heavily on a one week bootcamp, about 5 graded mock labs, and the CCIE Assessor.
In actuality, those three pieces were the most helpful to get me ready to tackle the CCIE itself, rather than specifically R&S material. So I think I can still take a couple of graded R&S mock labs to ensure my accuracy is ok. I'm hoping I won't need a bootcamp this time around, but I'm open to it depending on how the studying goes.
Good luck to Route Target as well, who will be taking his SP lab in February.
There was the standard 10-20% of questions that were just plain ridiculously hard. Aside from those, I'd say easily 50% of the exam is pretty basic to anyone with a CCNP and CCIP level of knowledge. Heck, quite a few of the questions were more on the CCNA level to be honest.
So that leaves the remaining 30%. They were difficult but strangely it was pretty easy to weed out the wrong answers. The usual questions such as, "Pick the best 4 out of 6". I'd have no idea about the 4 to pick. But two obviously didn't belong since they were part of a different technology altogether.
As far as written exams go, I'd rank them as follows in order of difficulty:
R&S Written: 9
Remaining CCNP and CCIP exams: 8
SP Written: 7
That's how I feel. If you know the CCIP and CCNP material, 50% the questions on the SP Written exam are actually easier than what's found in the professional level. So if you can deductively eliminate incorrect answers and get lucky on a few of the other half of the exam, you should be able to pass it.
And now it's time to begin studying for the lab. I'll put a study plan together in the coming days. I'm hoping to shoot for my first attempt in April or May.
Friday, December 19, 2008
I'd recommend taking the exams in the following order:
1. BSCI. If you already have a CCNP, you may have already passed the exam. I do find it strange that a CCIE R&S doesn't waive this requirement. I last passed the BSCI in 2002, so I needed to retake this. The only topic in the exam that is not really covered by R&S is IS-IS. This is a topic on the service provider blueprint, so take the opportunity to get some studying done on it.
2. QoS. You should already be pretty familiar with QoS from the CCIE R&S.
3. For the brave, go for BGP+MPLS. I will definitely say I found this to be one of the toughest exams I've taken. It's certainly up there on the CCIE Written calibur of exams. There are lots of very tricky questions that you have to pay close attention to. There's also an abundance of questions from obscure topics that I would have expected to be a small part of the exam.
4. Otherwise, go for BGP separately from MPLS. I did take the BGP exam as well, and found it to be MUCH simpler than BGP+MPLS. Of course having a CCIE R&S means you should already know BGP pretty well. Now I never did take the MPLS exam, so I cannot comment on it.
For BGP+MPLS, the following resources are very helpful. Make sure to know them inside and out. There were some more obscure topics that I could only find covered in the these links.
MPLS Virtual Private Network Enhancements
BGP Case Studies
Cisco Express Forwarding Overview
Configuring Cisco Express Forwarding
BGP: Frequently Asked Questions
MPLS Configuration on Cisco IOS Software (Book)
Also make sure to spend some time on MPLS technology labs from your vendor of choice. Internetwork Expert has a great price on an SP bundle, which includes Class on Demand.
In the SP Written blueprint, Cisco specifically mentions RFC 3439. Amazingly, I'm finding it very readable and interesting.
Thursday, December 18, 2008
Now it's time to start working on the SP Written. One look at the blueprint and I'll need to focus on the following topics:
- Service Provder Network General
- ATM, POS, DPT/RPR
- High Availability
- High End Product
Friday, December 12, 2008
So I've been back an forth trying to decide if I want to even bother with the CCIP or not. I think I'm going to take another stab at either the MPLS exam or the BGP+MPLS exam. I just don't feel up to studing for the SP written yet.
Tuesday, November 18, 2008
When we use as-override, the intention is to work around the loop prevention mechanism of eBGP so that a CE router will accept a route from another CE router with the same AS.
But sometimes that loop prevention mechanism is still needed. This typically occurs when two CE routers have a backdoor (i.e. non-PE) connection to each other, in addition to the PE connection.
Such a connection can create a routing loop when used in conjunction with as-override. This is because the PE router strips the originating AS and then advertises the route back out to the other CE. This CE router has no idea that this is the same route it is learning from its backdoor neighbor, so a routing loop can be created.
To prevent this, the site-of-origin (soo) extended community can be set via a route-map. No filtering is required, everything happens automatically once it is set. When a PE router learns a route with an SOO set, it will not advertise another route with the same SOO set to its CE neighbor.
The catch to this is that the backdoor route cannot be used as a redundant connetion to the other CE router. If the MPLS connection drops, traffic cannot be rerouted dynamically through the other CE router.
To check if SOO is set on the PE router, use sh ip bgp vpnv4 all X.X.X.X
Monday, November 17, 2008
I learned a bit more about the order of operations of MPLS during this exercise. I mistakenly forgot to import the route-targets on R3. During troubleshooting, I noticed that the routes that were supposed to be imported were not present in sh ip bgp vpnv4 all. Apparently this table does not get populated until the specific route-targets are imported by a vrf.
Sunday, November 16, 2008
I think I'm still a little fuzzy on the transition from an IP address to a route descriptor to a route-target, and how they all interoperate with routing protocols and redistribution.
This lab did help to tie it together somewhat. I suppose my understanding is that it goes something like this:
When an interface is setup for vrf forwarding, it is no longer part of the global routing table. Instead, the router performs a lookup to get more details about the vrf that the interface is an instance of. It goes to the vrf configuration and finds the route descriptor, which is uses to relate this interface to IGPs and ipv4 BGP. Then, it sends out a BGP vpnv4 route for each export target. These export targets get flooded throughout the BGP vpnv4 peers, which should encompass all PE routers. Finally, with these vpnv4 routes flooded, the import route-target is used to load the remote vpnv4 routes into the particular vrf routing table.
Saturday, November 15, 2008
The interesting part here is I finally got to play around with import/export route targets. It actually worked pretty intuitively. Under the R5 vrf, I configured it to import and export all of the other route-targets. Once RIP propagated about 30 seconds later, everything magically worked. That was all there was to it. Way too easy.
The solutions guide specified to import R5 into the other 3 vrfs, instead of exporting to the other vrfs from R5. It appears to be 6 one way and a half dozen the other, but I do wonder if there is a standard to try to import when possible. Sort of like in an access-list it's a good idea to set it up inbound. This makes sense on an access-list because filtering it ingress saves processor time and bandwidth utilization.
First, when a route comes in from a CE router, it has its AS listed in the AS path. The route crosses the core to the far end PE router, where it gets advertised out with the original AS number along with the PE AS number. The the CE router receives this, it drops the route because it sees its own AS number in the path.
To prevent this, the neighbor as-override command is placed on the PE ipv4 address-family. This command advertises the routes to the CE router with only the PE's AS in the AS path. This way the CE router does not drop the routes coming from the other PE router.
The second issue I ran into is that I needed to redistribute connected into the PE bgp address-families. I was a little confused as to exactly why, even though the CE routers could only ping each other if this was present. So I removed it to see what was happening.
Here's the BGP table with the redistribute connected removed from the R6-SW2 address-family:
Rack1R3#sh ip bgp vpnv4 all
BGP table version is 74, local router ID is 22.214.171.124
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:57 (default for vrf R5-SW1)
*>i10.1.5.0/24 126.96.36.199 0 100 0 100 i
*> 10.1.7.0/24 10.1.37.7 0 0 100 i
*> 10.1.37.0/24 0.0.0.0 0 32768 ?
*>i10.1.45.0/24 188.8.131.52 0 100 0 ?
Route Distinguisher: 1:68 (default for vrf R6-SW2)
*>i10.1.6.0/24 184.108.40.206 0 100 0 200 i
*> 10.1.8.0/24 10.1.38.8 0 0 200 i
*>i10.1.46.0/24 220.127.116.11 0 100 0 ?
Note there is not a route to 10.1.38.0/24 in BGP. But who cares? And then it dawned on me.
When we ping, the router uses the IP from the outgoing interface, unless a different ip is specified during the ping. Sure enough, pings work fine when sourced by the loopback address, since that is contained in the BGP table. But when the ping is sourced from the outgoing interface, BGP doesn't have a route to it.
This wasn't an issue with RIP, OSPF, or EIGRP, because IGPs automatically add the interface that the protocol is running on to the routing table. But BGP does not do this. It only adds routes specifically injected via the network command, or routes redistributed into BGP.
To prove the theory, I'm going to use a network command for the connected interface rather than redistributing connected. I typically prefer not to redistribute so I can avoid ugly RIB tables.
Sure enough, that did the trick. And note how the origin is internal for the network'ed route as opposed to unknown for the redistributed route.
*>i10.1.38.0/24 18.104.22.168 0 100 0 i
*> 10.1.46.0/24 0.0.0.0 0 32768 ?
Friday, November 14, 2008
When redistributing BGP into OSPF, there's no need to mention the VRF name since OSPF can figure that out by the OSPF VRF.
However, when redistributing OSPF into BGP, you do have to explicitly put the VRF name in addition to the process number. It would seem to me that BGP should be able to figure out the VRF name from the address family.
So the main difference here is that address-families must be created under global RIP process. All the configuration is then applied under each RIP address-family. I found it very interesting at first that none of the redistribution in BGP or RIP requires the naming of the address-family. The router is smart enough to keep track of all this based on the address-family it is under, and the vrf assigned to the interface.
For example, when I first configured RIP, I was concerned about the network statement. Being that multiple interfaces fell under 10.0.0.0, I thought all of the interfaces would be advertised into the particular address-family of RIP and that I'd have to use passive-interface or filtering to block them. Nope. The router only advertises the interfaces that have the vrf of the applicable address-family. Makes perfect sense, and makes my life a lot easier.
I also got stuck for a bit because I couldn't find the RIP routes getting distributed into BGP. Turns out I needed to use sh ip bgp vpnv4 vrf instead of sh ip bgp. Makes sense, as I needed to see the routing table of the vrf instance, not the global bgp table.
I'm feeling a lot better about MPLS VPNs today, and have a better understanding the significance of route descriptors as well.
Thursday, November 13, 2008
First create the vrf and associate the rd and import/export rules
Next assign the interfaces to the vrf and reapply IP addresses
Then configure the BGP vpnv4 address family, activating the other PE router and send both communities
Also under BGP, configure the ipv4 vrf address family, redistributing as appropriate
Finally, configure any necessary ip route vrf's.
Use show ip route vrf *, show ip bgp vpnv4 all, and ping vrf to verify connectivity
I really need to commit to memory when to use the vpnv4 address family and when to use the ipv4 vrf address family. It makes sense conceptually. The vpnv4 family includes the extended communities, and basically acts as a type of tunnel between PE routers. Then, each ipv4 vrf is like a pvc inside of that tunnel. Finally, the vrf itself describes what routes get leaked between each individual vrf.
The router uses rd's to keep track of vrf's. We use the vrf name to associate the vrf with interfaces and bgp.
The router uses rt's to advertise vrf's across vpnv4 through the use of extended communities.
The Basic MPLS lab was just what it says. Just needed to throw OSPF and BGP on a few routers and then put MPLS on the core. It was a nice exercise just to watch the pings propagate even though the core routers don't have a route to the final destination.
I had two mistakes in my configuration that I was able to correct pretty quicly. First, I missed mpls ip on one of the interfaces. Because it was missing, some of my hops were untagged in the mpls forwarding table. Simply checking the mpls neighbors at each router pointed me to the issue pretty quickly.
The second mistake was that I didn't put next-hop-self on the PE routers. This is necessary because the core needs a route to the next BGP hop, just not to the final destination. By deafult, iBGP does not update the next-hop and leaves it as the first eBGP hop.
Monday, November 10, 2008
This is one of my favorite responses to one of my groupstudy posts when I was struggling with BGP and another member made a humerous analogy to learning BGP from a book.
I have to agree with that to a certain extent. I was completely clueless on BGP a few years ago, eventhough I read Internet Routing Architectures cover to cover at least twice. It wasn't until I performed enough complex redistribution labs and worked with it in the real world before I got my arms around it.
I now seem to be having the same struggles with MPLS. I have the fundamentals more or less memorized, but I don't really understand the how's and why's of what's going on. I think that is what's keeping me from getting through the MPLS exam.
So rather than continue to brute force the exam, I've decided to pick up the InternetworkExpert Service Provider material. I'm hopeful reviewing their Class on Demand and working through their techonology labs will help to get me up to speed.
Thursday, November 6, 2008
So on the bright side, I now know I was doing pretty well on the BGP portion of the BGP+MPLS exam. The problem with this is I was doing a heck of a lot worse on the MPLS portion. If my scores were similar, that would mean I must have been getting approximately 50% on the MPLS portion of the combined exam.
Now it's time to focus on MPLS. I've tried just reading books and that doesn't seem to help it sink in. I ran into the same thing with BGP a few years back and just didn't "get it" until I did enough labs. It may be time for the same approach with MPLS.
Wednesday, November 5, 2008
The question I ask is, does a recession make more or less people attain their CCIE? I could see two possibilities here. First, perhaps the fear of a tightening job market would drive some to get this certification knocked out. On the other hand, having less money to pay for training and lab attempts, along with perhaps a lower possibility of rewards from passing, may cause some to put the CCIE on the back burner.
Between March and September, the rate of attainment of new CCIEs was 9.7 per day. According to InternetworkExpert.com, their latest CCIE number as of November 5th was 22542, vs 21910 on September 3rd. Therefore, over the past two months, this equates to 10.0 CCIE numbers awarded per day.
Now this is hardly a scientific study, since I don't have access to the exact amount of CCIEs given out on a particular day and I'm comparing a 6 month timeframe to a 2 month timeframe.
But it certainly does appear that this global economic slump is having no effect, or even a slightly positive effect, to the attainment of new CCIEs.
I hope I can pass this today and get myself back on the right track.
Monday, November 3, 2008
I'm throwing in the towel on this one. I'm pretty sure what's killing me is that I just don't have the practical experience with BGP.
Jumping in to CCIE studying would certainly give me the hands on. I was hoping to use the CCIP to springboard into that, and to be honest I feel like it has already served that purpose. I understand the concepts of MPLS pretty well, I think it's just some of the peculiarities that are throwing me off.
So what now? I've had it with this exam and I'm giving up on it. I was hoping to be into CCIE SP studying by the end of this month. I really want to recertify my CCIE R&S by the end of the year as well.
That basically leaves me with three options:
- Take the BGP and MPLS exams separately. I think that would be helpful because the score reports should be a little more granularized. That way I should at least know what my weaknesses are. The BGP+MPLS score report is pretty vague.
- Take the R&S CCIE Written again to renew my cert and then decide what to do next.
- Jump straight to the SP CCIE Written. I might end up failing it repeatedly as well.
- Jump straight to studying for the CCIE Lab. I should get enough hands on experience with MPLS to come back and knock out the CCIP after a little while with it. Of course once I'm a month or two into labbing it up on the IE, I probably wouldn't want to bother backtracking for the CCIP.
Friday, October 10, 2008
So what to do now? Do I split them up and take BGP and MPLS exams separately, or keep banging my head against the wall on this exam.
I'm going to digest this for a bit and make up my mind when I'm a little less pissed off at the people who make up these ridiculous questions!
Tuesday, October 7, 2008
Thursday, September 18, 2008
The BGP portion went fine. I'd estimate I got over 90% on those questions. Unfortunately many of the MPLS questions were from areas I didn't study enough on. That being said, I had an idea on many of the MPLS questions, I just wasn't quite sure what the correct answer was.
The bottom line is I have to do a lot of studying on MPLS VPNs. I think if I get more comfortable with them I'll be ready to go. I'll try to focus on that topic and take the exam again next week.
Wednesday, September 10, 2008
The writer makes the bold statement that "Looking 30 years into the future I think it is clear that the regional leaders will be China and Korea, NOT India and Japan."
Wednesday, September 3, 2008
Knowing this yields the following statistics:
- There have been 1758 new CCIE numbers awarded in the past 6 months
- Averaged out, this is 293 per month or approximately 10 per day.
For those of you who want a number in the 20,000s, you have approximately 2 years and 4 months left, assuming the rate stays the same.
Tuesday, September 2, 2008
So, not much MPLS studying was completed last week due to an asymmetric routing issue I ran into at work that took a bit of time to figure out. There is a great article here that explains it.
Asymmetric routing happens when a packet leaves a network through one path and comes back in through a different path. Take a look at the following picture, disregarding the Multicast lingo.
Imagine if a packet comes into the switch on the left, leaves the router on the left to the cloud. Then, a return packet enters the router on the right, back to the switch on the right, and finally back to the switch on the left.
Now, when the packet enters the switch on the left originally, the switch updates its cam table with the source mac address. The packet passes up to the router on the left, and out to the cloud.
When the packet returns, it comes through the router on the right, and down to the switch on the right. This is where there is a problem.
Since the outbound packet never went out the switch on the right, the switch never loaded it's mac address. And what does a switch do when it doesn't know the mac address? By default it floods the packet out all interfaces associated with that vlan (extra credit for CCIE students who know how to turn this floding off). This includes access links, trunk links, etherchannels, and whatever else. So if there is a chain of 15 switches, this packet is likely to get flooded across all interfaces of all of those downstream switches.
Now how do we stop this from occurring? We need a little help from ARP. When the host wanted to send an outbound packet, it had to send an ARP request. An arp request is a broadcast IP packet that sends an IP address and awaits the response of the MAC address associated with that IP address.
Since this is a broadcast packet, it is flooded throughout the broadcast domain (i.e. vlan). This causes all of the switches to update their cam tables and stop flooding the packet.
So why does this happen to begin with? One of the main reasons is due to mac aging-time. A router by default generally has a mac aging time of 4 hours. A switch by default generally has an aging time set to 5 minutes. So, when a router learns a MAC addresses, it doesn't need to relearn it for 4 hours. However, when a switch associates a MAC address with a port, it loses this information after 5 minutes. After 5 minutes, the only way a switch that's not in the path can update its cam tables once again, is for another broadcast to occur.
A switch will not send an arp request when it loses an entry from its cam table, however, a router must since it needs the mac address to send traffic to the host. At default mac aging settings of 4 hours for routers and 5 minutes for switches, asymmetric traffic will be flooding for 3 hours and 55 minutes of every 4 hours. This is probably not desired operation. Therefore, when asymmetric routing exists, routers and switches need to have their mac aging times set identically.
Thursday, August 21, 2008
MPLS Fundamentals (ISBN 1-58705-197-4) seems to be the most readable of what I've seen. In general, I just find the whole MPLS topic to be extremely dry--I'm not sure why. Possibly since most of my career has been spent as an ISP customer, the inner workings of MPLS was never really relevant to me.
It could be worse, I could be studying storage...
Thursday, August 14, 2008
- Multiple labels can be inserted, and the bottom-of-stack bit is set on the last label
- Labels consist of a 20 bit label, 3 bit experimental field, 1 bit bottom-of-stack indicator, and 8 bit TTL
- Ethertypes: 0x0800 is IP, 0x8847 is unicast with at least one label, 0x8848 is multicast with at least one label
- More than one label is used for VPNs and TE
- An LSR can push, swap, or pop labels
- MPLS is split into the control plane and data plane
- FEC: Packets forwarded based upon a common characteristic
- For Unicast IP Routing, an IP routing protocol and a Label distribution protocol are required
- Label distribution protocols match labels with networks
- FEC is the destination network
- PIM can be used for multicast, and the FEC is the destination multicast address
- TE requires OSPF or IS-IS with extensions
- RSVP or CR-LDP establishes tunnels and propagates labels
- With QoS, the FEC is the destination network and CoS
- In VPNs, two labels are used: Top points to egress router, second points to the outgoing interface on the egress router, or a routing table
- FEC is the site descriptor or VPN routing table
Tuesday, August 12, 2008
My score was a bit higher than on QoS, and passing, but still low enough where I'm not concerned that I overstudied for the exam.
On to BGP+MPLS, which will complete the CCIP. After that it's finally onto the SP Written, which will renew my CCIE certification.
Even though I'm planning on doing the SP lab after that, it is a little tempting to just knock out all of the professional level exams. I have enough experience in Voice and Security as well where I could probably hit an exam every couple of weeks and have the CCVP and CCSP complete by the end of the year.
The CCIE lab is just such a time and energy suck. But I'm leaning toward going ahead and studying for the lab sonner rather than later. There are three main reasons for this.
First, I'll be freshest on the lab material after just studying for the CCIP and written. If I switch tracks I'll probably have to relearn a few things.
Second, assuming I eventually pass the Service Provider lab, I can then jump right into the CCSP, which would give me a break before working on the Security lab. I'm definitely saving voice for fourth just because it has the reputation for being the toughest. Storage would be last since I have absolutely no experience with it and it will probably take me a lot longer.
Monday, August 11, 2008
According to the certification progress website, the version of BSCI exam I passed over 4 years ago is too outdated to count. So I have to knock this exam out instead.
As far as I can tell, there is only one topic that isn't covered by the R&S written: IS-IS. I'm guessing they're just going to be asking questions about the intricacies of L1, L2, and L1/L2 behavior.
Aside from that, I'll need to brush up on all the "booksmart" material such as timers and metric computation.
I think I'm going to shoot to have this knocked out by Friday.
Wednesday, August 6, 2008
Monday, August 4, 2008
I'm off to do my Master's presentation on Friday, so I won't be starting to study for another exam until next week sometime.
Thursday, July 31, 2008
As there's a lot of overlap with my R&S CCIE and my previous voice experience, I'm not stressing out much over this. Of course, there's always the fear of taking it for granted and failing and wondering how the heck I can pass the CCIE written and Lab and bomb the QoS exam.
Anyway--here are the topics I need to commit to memory:
- Higher drop precedence means more likely to be dropped. But higher IP precedence means less likely do be dropped. Huh? Who designs this stuff anyway? Just remember, AF11 will be dropped before AF21; however AF12 will be dropped before AF11. That last number means drop precedence, as in higher priority to be dropped. Whereas the first number means the traffic itself is higher priority, and less likely to be dropped. It makes me think they designed it this way simply because they knew they'd get a few good test questions out of it.
- RTP Header Compression also compresses the UDP and IP headers, and therefore must be enabled on both sides of a link. Could the name be any more misleading?
- COPS, aside from one of my wife's favorite TV shows, is a protocol that allows centralized monitoring and control of RSVP. Bad packets, bad packets, what'cha gonna do? What'cha gonna do when QoS comes for you?
- ECN is like frame-relay adaptive shaping, except it's not shaping and there's no frame-relay. If a router is nearing congestion, it can use the last two bits of the ToS field to notify the upstream host. Then the upstream host relays this information to the sender. Finally, the sender slows down sending. It's like FECN and BECN, and like being issued a warning before WRED steps in and destroys your packet.
- BGP can use communities to propagate QoS policy information (bgp-policy command)
Monday, July 28, 2008
I'm considered studying for the lab first and then knocking out the written once I'm comfortable with the hands on, but I'm changing my approach.
I'm going to go ahead and knock out the CCIP first. This should put me well on the way toward passing the written. It's also a little more manageable to cover the material this way.
The first exam I'm going for is QoS, since there's a lot of overlap with R&S and I've had a decent amount of experience with it. I picked up the Boson ExSim test for the exam. I've always been pretty fond of Boson and have been using them for over 6 years. They have a heck of a lot of material, are inexpensive, have great explanations, and the questions cover the topics well without being too close to the real exam.
My strategy is as follows:
- Take a 20 question Boson practice test every day
- Review the DocCD on anything I miss
- Review Safari Books Online if I need further explanation of the topic
Friday, July 25, 2008
This is not true with Randy Pausch. I can honestly say his lecture changed my life. I'm going to paraphrase a bit, but two points in particular had a big impact on me:
- Brick walls aren't there to stop you, they're there to prove how bad you want something
- You have four categories of tasks: urgent and important, non-urgent and important, urgent and unimportant, and non-urgent and unimportant. Do the non-urgent important tasks before the urgent unimportant ones.
Thank you Randy, you will be missed.
Thursday, July 10, 2008
- Get all of the CCIEs (probably Service Provider next)
- Get a PhD in Computer Science (finishing MS this summer)
- Author/co-Author a book
I was previously thinking of going for a CCIE in Security next, but that was mostly because I didn't see myself doing much with SP networks. As it turned out, that has changed so it makes more sense now.
Wednesday, July 9, 2008
If you've ever had a Tivo, it's a similar concept to that, but for websites. When you're on a webpage, you give it a thumbs up or thumbs down.
From there, it ranks pages (which you can view on Google in an Amazon style star raking system), or you can have it give you random pages based on your preferences.
You can even view the pages I gave thumbs up to here.
Thursday, July 3, 2008
Last year I installed Vista on my home PC because I got the business version for free--or I should say included with the $20,000+ I paid Towson University over the past 3 years in the quest for a Master's degree.
I'm not a Vista hater. It was ok, but more than anything it's just plain slow. With 1GB of ram and a 3GB single core processor it was having a rough time. Like my MCSE, my computer's upgrade path had expired (DDR1 RAM, Socket 478, no PCI Express).
So I could have went back to XP, which has reached end-of-sale status, or give something else a try. I chose the later and went with Ubuntu.
I've always had a linux box on the side, but never ran one full time. Now I'm running two. There are some things I like, and some things I'm not so fond of. But without a doubt the single biggest thing I love is the sheer speed. The install took 20 minutes. My computer takes about 20 seconds to boot up or shut down. Gone are the days of starting it up and getting a cup of coffee. No more hard drive thrashing or blue screens of death.
So far there are only four needed programs I haven't been able to get to work natively. Wine solved two of these by simulating a Windows environment for the program. Unfortunately two other programs (I'm not naming them because they may work and I just haven't quite figured them out yet) don't work and I am stuck with vmware for these two programs for the time being.
I'm liking Ubuntu more and more every day. If you've thought about giving it a try, here are some reasons.
Wednesday, July 2, 2008
One thing to keep in mind is dealing with the virtual MAC address HSRP uses. By default, this MAC address is 0000.0c07.ac00, if no group number is specified. If a group number is used, it is added to the last word. For example, group three becomes 0000.0c07.ac03. Further details here.
In general, you will usually only use one HSRP group per vlan, so this isn't a problem. But if you have another device spanning multiple vlans that needs to talk to multiple HSRP speakers simultaneously, this can create MAC address conflicts if the same HSRP groups are used.
Saturday, June 21, 2008
If any of you out there are concerned about the occasional stories about how the CCIE is becoming worthless, let me assure you it is definitely not. Posting my resume on Monster yielded a barrage of opportunities.
After everything was said and done, I'm now working for Cisco Systems in RTP. Everything is going great and it's truly an excellent company to work for. Now I have the unusual experience of going from being one of the most knowledgable in my company to realizing I have a long way to go.
Long story short, my previous story of becoming board will not be coming to fruition any time soon.
Monday, April 7, 2008
Do I go for a CCSP or CCVP? Or straight to the CCIE written in voice or security?
I'm a little reluctant to work on a second CCIE because I'd like to reap some of the benefits of the first one before working on the next.
My weaknesses in Security have shown over the past few weeks when I've missed little things here and there.
And then there's other non-Cisco options such as CISSP or Ethical Hacker. This summer I'm finishing a Master's in Computer Science, so I just don't think those two certs would matter much with a Master's and a CCIE.
Then there's always the thought of going for an MBA or a PhD in Computer Science. Neither seem too appealing to me at this time.
Friday, April 4, 2008
RFC 5241 - Naming Rights in IETF Protocols
RFC 5242 - A Generalized Unified Character Code: Western European and CJK Sections
I've also added a couple of my all-time favories to the list of links to the right.
Wednesday, March 19, 2008
The issue now lies on the inside network. Anyone who accesses a site via its public FQDN now must use the outside public IP rather than the inside private IP. As long as sites resided in the DMZ, this was taken care of by reconfiguring the static translation to use the outside public instead of the inside private.
There are two issues where this could not be resolved, however. First, if the server resides on the private network, instead of the DMZ. Unfortunately I inherited a bunch of these. I'm trying to get them removed, but still have a ways to go. Fortunately, I haven't found one that was a show stopper yet. If I do, I'll probably have to NAT it on our inside core switch. But I'd like to avoid that if possible.
The second issue is for people who accesses our DMZ services from remote sites across the VPN. Since they now reference a public instead of private address, they traverse the public Internet. This has created issues for people trying to do things like edit the public website remotely. Naturally the firewall doesn't allow this from the public internet.
We've been able to survive the little issues thus far. We also discovered the reason for the problem. Sever static NAT translations that I inherited were applied backwards. This was causing DNS doctoring to occur to the public internet! I'm not sure why this wasn't broken before.
So we know the fix, now I just have to convince my VP that we won't break the public website again. It's looking like it will be at least 2 weeks before we can put the change through. I just hope we don't put in too many band-aids between now and then that we can't go back to the correct way.
Sunday, March 16, 2008
Now I really haven't messed wtih DNS doctoring much since the alias days. It seems to be a lot easier now, since all one needs to do is to add the dns option to the static translation.
But the real question is, why wasn't this failing before the upgrade. I don't know. I turned off DNS inspection to kill this. That fixed the issue, but it took time to propogate.
The Default DNS TTL is 3 hours, so anyone who grabbed a bad record would have to wait up to 3 hours for their upstream DNS servers to get corrected.
To check the TTL remaining, nslookup can be used
Default Server: cns.manassaspr.va.dc02.comcast.net
> set debug
Got answer: HEADER: opcode = QUERY, id = 5, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS: www.somecompany.com, type = A, class = IN
ANSWERS: -> www.somecomapny.com internet address = 10.1.1.100
ttl = 205 (3 mins 25 secs)
As it turns out, a transparent firewall that permits everything still runs packet inspection. We placed one in between two mail servers. It was inadvertently inspecting SMTP and occasionally killing communication between the servers. This only seemed to happen with a high message load.
Over the years, Cisco has been driving me and many others crazy with smtp. This was actually the first place I looked on our external firewall, and it was not present. I never even thought to look at the transparent firewall until later.
A primer on mailguard, etc.
Since PixOS 4ish, Cisco dabbled in application inspection with the mailguard feature. Since SMTP only has a handful of commands (HELO or EHLO, DATA, etc.) mailguard attempted to only allow these commands and to play with some banners and things as well to help protect the mail server.
In Pix 6ish this was now called fixup smtp 25
And now in Pix 7 it's called inspect esmtp
And over all of these years, the general rule is always to disable it immediately.
There are certain things that Cisco does that amazes me. Why, when after 10 years of configurations being changed out of the box, does Cisco not just make them default? Off the top of my head, some examples are
- Turn off SMTP proxying/fixup/inspect/mailguard
- Disable auto-summarization
- Turn on service password-encryption
- Turn on service timestamps
- Automatic "terminal monitor"
Saturday, March 15, 2008
- HSRP with object tracking
- dot1q trunking to a router
- transparent firewall BPDU passthrough
- BGP advertise-map configuration
Just from my experience with the CCIE lab, I changed my normal plan of attack here. In the past I was more one who prefered to gut everything and replace it all at once. Now, I tend to follow lab strategy and do one piece at a time, verifying as I go.
As with the lab experience, things go much slower this way, but it gets done right. When something doesn't come up I know exactly where to look for the issue instead of having to troubleshoot everything.
As expected, there were a few bugs to work out, but just about everything ended up as designed. The great work up front and during the implementation by the whole team really paid off.
Some of the learning experiences were
- A firewall in transparent mode can pass layer 2 information, but not CDP. A ethertype access list is required to allow BPDUs to pass. This was necessary so that a backup link can be used while letting rstp block the link. If this didn't work, another option would have been the "switchport backup" option for the 2560/3560 series switches, which functions a bit like a layer 2 version of the backup interface router configuration command.
- It always helps when default gateways are set correctly
- When using Hyperterminal to paste commands, make sure to set the character delay to prevent buffer overflows
- Duplicate IP addresses are very bad things
Saturday, March 8, 2008
While one ISP got it correct, the second did not. My router wasn't maxed out on memory, so I needed to ensure I didn't have the entire BGP table. Sure enough, once the BGP adjacency came up, I began to receive more than I bargained for.
Now the race was on. I had to filter everything but the default route before the router ran out of memory. Of course, just about any CCIE should be able to do this.
ip prefix-list DEFAULT permit 0.0.0.0/0
route-map NODEFAULT deny
match ip address prefix-list DEFAULT
route-map NODEFAULT permit 20
router bgp xxxxx
neigh xxxx route-map NODEFAULT in
It took about 30 seconds. No DocCD needed. I didn't even have to use the ?. It worked right the first time.
This is why the stress and pressure and time constraints exist in the lab. Unexpected things happen. Sometimes you have to act quickly. Consequences can be severe.
My life has changed already though. It's Saturday and I did not wake up at 6am. I slept in until nearly 11. My wife and son are out of town this weekend, so I have been watching movies and hanging out with my dog. At some point I need to lower my son's crib since he's very close to pulling himself up.
The next change is that I'm finding it difficult not to brag. I called a few friends and sent a few more emails. But most people would probably not know unless they paid attention to my new email signature. I'm not sure if I'll keep it in there long-term, but I will for at least a week or two.
I'm also not sure what to do next. I'm planning on casually studying for the security track. I'm really not in a rush. It took me 10 years to get the first CCIE, so that should be too difficult to improve upon.
One thing I did notice. There are a lot of blogs of people either talking about studying for the CCIE or helping others to get there. But what are you supposed to do after you're certified?
There is no official blueprint for what to do after you're certified.
So, the new purpose of this blog is to discuss what happens next.
Sunday, March 2, 2008
Saturday, March 1, 2008
The first task of the lab, that many seem to fail, is getting a good night's sleep the night before. I bombed that miserably at my first attempt. I came down to RTP with my family and my dog. My 7 month old son was still collicky at the time and thought he'd help me study until 4am. Unfortunately I don't understand babytalk so all it meant was that I only got about 2 hours of sleep. I ended up getting to the lab about 15 minutes late. By 6 hours in I was feeling pretty drained and didn't have much motivation to do a detailed 2nd verification of everything.
Due to some misconceptions I had that I realized in later studies, I probably would not have passed anyway. But I'm going to do everything I can to get some solid sleep tonight. I did a test drive to the Cisco campus to make sure I know the way. I have a 6am wakeup call scheduled, my cell phone alarm, and hotel room alarm set for that time as well. So I'm calling my sleep preparations task 1/2. Let's just hope I can follow through.
If you happen to read this, Laura, thanks for all of your support this year. You've allowed me to get a heck of a lot of studying done on the weekends and I really appreciate it.
Friday, February 29, 2008
I've told my wife I'm only taking 5 attempts. If I don't get it by then I'll give up. That gives me 4 attempts left.
I do get a little frustrated with IPExpert and IE labs. There are a number of mistakes that are obviously from failure to properly upgrade their workbooks over the years. I personally find this to be detremintal to my studying. I've had to get use to assuming things might need to be a little different than they way they are worded. On the actual lab, this is BAD. I need to make sure to assume absolutely nothing.
I don't feel there's anything else to learn with a free retake of the IPexpert bootcamp. Perhaps taking it with Scott for a different perspective would help.
There has been a lot of "testimonials" on the Narbik bootcamp lately. It's to the point that I'm actually steering away from it. From the reviews I'm reading, it's sounding more like he's teaching "stupid router tricks" than anything else. My impression could be wrong, so I'd open up some discussions on Monday if I need to.
I really feel the best preparation for me at this point is the Mock Labs. I've taken all but 2 of the IE mock labs. Another option would be to take the IE Mock Lab bootcamp.
Another possibility would be to swtich to NetMasterClass. A lot of people seem to recommend using them in tandem with IE. Their CheckIt labs are pretty expensive though--$250 each or 3 for $635. They also have a DoIT volume 2 plus 5 CheckIt labs package for $1324, which is about the same cost as a lab attempt.
Since I have been successful at studying at home, I think this would be a good approach to take. It would give me 1 graded lab a weekend and 1 workbook lab a weekend with 5 weekends before another attempt.
So that's my plan of attack. Purchase the $1324 package from NMC and reschedule for a month out.
Here is a list of things that I still feel I could use some work on:
-Catalyst QoS mutation maps
-OSPF NSSA Type 7 suppression
-Reachability Verification--I always seem to miss a BGP route somewhere
-Multicast Troubleshooting--I'm still slower than I'd like to be
-PIM Mapping Agent placement
-CBAC and Reflexive ACLs--I'm still gunshy to implement these
-NTP--remembering to apply the trusted key to the ntp server
-Extended login options
Wednesday, February 27, 2008
Sunday, February 24, 2008
Take extra time verifying every single last thing
Don't worry too much about time
Take extra time playing around with multicast
Do each QoS question using MQC and Legacy formats
Play with NAT
7:41 diagram complete
7:54 readthrough complete
8:18am 1.1 complete, 3 points
8:18am 1.2 complte, 3 points
8:19am 1.3 complete, 2 points
8:23am 1.4 complte, 2 points
8:27am 1.5 complete, 3 points
8:31am 1.6 complte, 3 points
Switching complete, 16/16
8:48am 2.1 complete, 3 points
8:48am 2.2 complete, 3 points
8:48am 2.3 complete, 2 points
Frame complete, 8/8, 24/24
8:54 3.1 complete 3 points
8:59 3.2 complete, 3 points
PPP complete, 6/6, 30/30
9:08 4.1 complete, 3 points
9:17 4.2 complete, 3 points
9:23 4.3 complete, 2 points
9:28 4.4 complete, 3 points
9:41 4.5 complete, 2 points
9:45 4.6 complete, 2 points
9:49 4.7 complete, 2 points
9:57 4.8 complete, 2 points
10:06 skipping 4.9, 0/3 points
IGP compelte, 19/22, 49/52 total
10:24 complted 4.9
IGP complete, 22/22, 52/52 total
10:29 pingtests complete
10:56 5.1 complete, 3 points
11:13 5.2 complete, 3 points
11:41 5.3 complte, 3 points
BGP complete, 9/9, 61/61 total
12:26 pingtests complete
12:39 6.1 complete, 3/3
12:55 6.2 complete, 2/2
12:55 6.3 complete, 3/3
Multicast complete, 8/8, 69/69 total
1:00 7.1 complete, 3 points
1:08 7.2 complete, 3 points
IPv6 complete, 6/6, 75/75 total
1:10 8.1 complete, 2 points
1:14 8.2 complete, 3 points
QoS complete, 5/5, 80/80 total
1:27 9.1 complete, 2 points
1:32 9.2 complete, 2 points
Security complete, 4/6, 84/86 total
1:38 10.1 complete, 3 points
1:38 10.2 complete, 2 points
System management complete, 5/8, 89/94 total
1:59 11.1 complete, 3 points
2:05 11.2 complete, 3 points
IP Services complete, 6/6, 95/100 total
Lab complete, 95%, under 7 hours
Saturday, February 23, 2008
I did not pass. I broke this down into three reasons:
40% stupid mistakes
40% not enough time
20% not enough knowledge
Stupid mistakes hurt me on switching and redistribution. The main fault here was lack of verification.
Lack of time hurt me on Multicast and IP Services. I mostly blame this on not looking things up on the DocCd. If I had more time I would have looked them up and more than likely got correct.
Lack of knowledge hurt me on Multicast and QoS. There were items here I more than likely wouldn't have got correct, even if I had enough time.
So what does this mean? If I make no stupid mistakes, verify everything, and use the DocCd exhaustively for anything questionable, I can barely pass.
I have 8 days left until my next attempt. I need to get better with Multicast, QoS, and IP Services quickly. As far as stupid mistakes--VERIFY EVERYTHING!!!
7:03am Diagrams complete
7:14am Readthrough complete
7:22am 1.1 complete, 2 points
7:30am 1.2 complete, 2 points
7:38am 1.3 complete, 2 points
7:41am 1.4 complete, 2 points
7:44am 1.5 complete, 2 points
Section 1 complte, 10 points
7:49am 2.1 complete, 3 points
8:09am 2.2 complete, 2 points (unable to verify)
8:19am 2.3 complte, 3 points
8:25am 2.4 complte, 3 points
8:30am 2.5 complte, 2 points
8:32am 2.6 compelte, 3 points
8:35am 2.7 complte, 3 points
IGP complete, 19/19, 29/29 total
Pingtests complete, 8:47am
8:53am 3.1 complete, 2 points
9:14am 3.2 complete, 2 points
9:17am 3.3 complte, 2 points
9:23am 3.4 complete, 2 points
9:25am 3.5 complte, 2 points
BGP complete, 10/10, 39/39 total
9:27am 4.2 complete, 1 point
9:37am 4.3 complete, 1 point
Sunday, February 17, 2008
8:15am Lab started
8:36am diagrams complete
9:15am readthrough complete
9:32am 1.1 complete, 3 points
9:47am 1.2 complete, 3 points
9:55am 1.3 complete, 3 points
10:02am 1.4 complete, 3 points
Switching complete, 12/12
10:12am 2.1 complete, 3 points
10:49am 2.2 complete, 3 points--bridge 1 route ip
10:53am 2.3 complete, 3 points
10:55am 2.4 complete, 2 points
WAN complete, 11/11, 23/23 total
11:06am 3.1 complete, 3 points
11:43am 3.2 complte, 3 points
12:09am 3.3 complete, 3 points
12:17am 3.4 complete, 3 points
12:19pm 3.5 complete, 3 points
IGP complete, 15/15, 38/38 total
12:19pm taking lunch
1:02pm back from lunch
1:50pm Task 4.1 complete. There was missing information on the lab, 3 points
2:02 Task 4.2 complete, 3 points
2:05 Task 4.3 complte, 3 points
2:20 Task 4.4 complte, 3 points
2:24 Task 4.5 complete, 3 points
BGP complete, 15/15, 53/53 total
2:32 Task 5.1 complete, 2 points
3:24 Task 5.2 complete, 3 points
3:31 Task 5.3 complete, 3 points
Multicast complete, 8/8, 61/61 total
3:37 Task 6.1 complete, 2 points
3:41 Task 6.2 complete, 3 points
4:04 Task 6.3 complete, 3 points
4:35 Task 6.4 complete, 3 points
IPv6 complete, 11/11, 72/72 total
4:42 Task 7.1 compelte, 3 points
4:58 TASK7.2 complete, 3 points
5:03 Task7.3 complte, 3 points
QoS complte, 9/9, 81/81 total
5:05 Task8.1 complete, 2 points
5:08 Task8.2 complete, 3 points
Security complete, 5/5, 86/86 total
5:18 Task 9.1 complete, 3 points
Saturday, February 16, 2008
I now understand:
- How to set cost and port priority for mstp
- BGP address families
- ip forward-protocol
- ospf demand routing
- ospf authentication null
- bgp next-hop-self
- bgp cluster-id
- police cir
I've changed my strategy as follows:
- I now make a detailed L2 diagram
- I now make a loopback checklist
- I now add multicast information to the L3 diagram
- I now use 10 telnet windows instead of a single console
I'm still weak with:
- attention to detail
- verification plan
- multicast troubleshooting
- Catalyst QoS
5:24am lab started
5:42am diagrams complete
6:08am readthrough complete
6:23am troubleshooting complete, 2 points
6:42am 1.1 complete, 3 points
6:42am 1.2 complete, 3 points
6:50am 1.3 complete, 2 points
6:52am 1.4 complete, 2 points
Switching complete, 12/12
7:05am 2.1 complete, 3 points
7:16am 2.2 complete, 2 points
7:24am 2.3 complete, 2 points
Frame relay complete, 7/7, 19/19
7:27am 3.1 complete, 3 points
7:39am 3.2 complete, 2 points
7:39am 3.3 complete, 4 points
8:00am 3.4 complete, 3 points
8:00am 3.5 complete, 3 points
8:15am 3.6 complete, 3 points
8:15am 3.7 complete, 3 points
8:18am 3.8 complete, 3 points
8:36am 3.9 complete, 3 points
8:53am Pingtests complete
9:11am 3.10 complete, 3 points
IGP complete, 30/30, 49/49
9:26am 4.1 complete, 4 points
9:38am 4.2 complete, 3 points
9:43am 4.3 complete, 3 points
10:17am 4.4 complete, 3 points
10:22am Pingtests complete
EGP complete, 13/13, 62/62 total
11:21am 5.1 complete, 3 points
11:25am 5.2 complete, 2 points
11:31am 5.3 complete, 2 points
Multicast complete, 7/7, 69/69 total
11:33 6.1 complete, 2 points
11:46 6.2 complete, 3 points
11:49 6.3 complete, 2 points
IPv6 complete, 7/7, 76/76 total
12:12 7.1 complete, 2 points
12:20 7.2 complete, 3 points
12:29 7.3 complete, 2 points
12:35 7.4 complete, 2 points
12:51 7.5 complete, 2 points (iffy)
QoS complete, 11/11, 87/87 total
12:54 8.1 complete, 2 points
1:00 8.2 complete, 3 points
Security complete, 5/5, 92/92 total
1:07 9.1 complete, 3 points
1:09 9.2 complete, 3 points
System management complete, 6/6, 98/98 total
1:10 10.1 complete, 2 points, 100/100 total
I have 14 minutes left to review
1:28 lab complete. In review I found I missed the CDP domain name.
- port security recovery cause is psecure-violation
- cannot use MAC access-list to filter IP. Use static mac entry instead
- ip ospf demand circuit
- I actually got the multicast helper-map figured out, but was testing it wrong. Need to use ip sla to test specific multicast ports
Thursday, February 14, 2008
Configured an IP on an interface instead of on a vlan, as specified on the diagram. I changed two of these from the initial config, but I must have missed one. -2
Loopbacks were not summarized. I'm suprised here, I spent quite a bit of time on them. It's possible some of my later EGP redistribution broke this again. -2
Missed an OSPF adjacency password. -2
Incorrect IGP metric. -2
Multicast, -4 because of incorrect L2 vlan.
I seem to have lost a point in the wash somewhere.
- Compare the diagram to the configuration for review. Device by device.
- Re-verify summarizations and metrics after EGP is complete
- Check each ip ospf interface for authentication
These mistakes were nothing to do with the complexity of the lab. I think I just get overwhelmed with review near the end of the lab and don't check every little detail. This happened to me on the actual lab as well. I need to get more disciplined with this.
With the difficulty of this lab, I really feel I have a pretty strong grasp of the technologies and concepts. I just have to do better at verification. Because of this I'm going to adjust my study schedule to the following:
2/16: IE Mock Lab #1. Pretty easy and I better get near 100% on it. Only 41% last time due to little mistakes.
2/17: IE lab #12. Just taking this for the sake of practicing with something new.
2/23: Cisco CCIE Assessor. By now I better be doing a good job of verification. I want to make sure I'm doing tasks to Cisco's level of expectation.
2/24: IE Lab #16. Again, doing something new.
3/2: Lab Attempt #2
Sunday, February 10, 2008
7:21am diagrams complete
7:43am readthrough complete
7:53 1.1 complete, 4 points
8:03 1.2 complete, 3 points
Switching complete 7/7 points
8:07 2.1 complete, 2 points
8:13 2.2 complete, 2 points
8:14 2.3 complete, 2 points
Frame relay complete, 6/6 13/13 total
8:24 3.1 complete, 2 points
8:54 3.2 complete, note traffic share count in sh ip route
9:00 3.3 complete, 2 points
9:03 3.4 complete, 3 points
9:22 3.5 complete, 3 points--virtual links can extend for area 0 preference as well
9:26 3.6 complete, 3 points
9:28 3.7 complete, 2 points
10:10 3.8 complete, 3 points--weird stuff. a /24 was getting redis as well. I still don't understand why but it's blocked now
10:14 3.9 complete, 3 points
10:22 3.10 complete, 3 points
IGP complete, 27/27, 40/40 total
10:30 pingtests complete, no issues. Taking lunch
10:45 back from lunch
10:58 4.1 complete, 3 points
11:08 4.2 comlete, 3 points. Had to go back and filter out a default route from ospf->eigrp
11:19 4.3 complete, 3 points.
skipping 4.4. I know how to do this, but it would kill BGP reachability.
12:01 4.5 complete, 3 points
12:31 pingtests complete. Had some sloppy routing decisions to fix up
EGP complete, 12/15, 52/55 total
12.40 5.1 complete, 2 points
12:50 5.2 complete, 3 points
12:50 5.3 complete, 3 points
12:56 5.4 complete, 3 points
Multicast complete, 11/11, 63/66 total
1:00 6.1 complete, 2 points
1:12 6.2 complete, 2 points
1:18 6.3 complete, 3 points
Ipv6 complete, 7/7, 70/73 total
1:38 7.1 complete, 4 points. OSPF doesn't care much for frame-relay fragmentation
1:51 7.2 complete, 3 points. available bandwidth feeds off mincir
2:53 8.1 complete, 3 points. Couldn't verify for some reason
skipped 8.2, 0/3 points. not sure how to change telnet port
3:07 9.1 complete, 3 points
3:07 9.2 complete, 2 points
3:15 10.1 complete, 3 points
3:22 10.2 complete, 3 points
3:27 103 skipped, 0/3 points. Not sure how to renew dhcp every 3 hours outside of interface
Lab 10 complete. 91 points possible. Time to check.
1.1 because I can't read. sw2 transparent -4
4.4 looks like killing reachabilit was fine -3
8.2 rotary -3
9.1 banner exec -3
10.3 funny, I was thinking kron -3
Total score: 84
Saturday, February 9, 2008
Today I'm taking IE Mock lab #4. It has a difficulty of 9, which means it's supposed to be harder than the actualy lab. To make things worse, they put a timer on now and will automatically kick me off the equipment 8:30 after I start.
I'm going to try one different approach this time. I'm going to open 10 terminal windows instead of just the 1. I was afraid before that I would get confused, but I'm sure there'd be a big benefit to catching debug ip routing messages and others if I go this way. I hope by practicing a month with this I'll get the issues straight.
6:32am Started Lab
7:00am Diagrams complete
7:18am Readthrough complete
7:42am 1.1 complete, 2 points
7:42am 1.2 complete, 3 points
8:10am 1.3 complete, 2 ponts
8:10am 1.4 complete, 3 points
8:10am 1.5 complete, 3 points
Bridging and Switching complete, 13 points
8:25am 2.1 complete, 3 points
8:35am 2.2 complete, 2 points
8:35am 2.3 complete, 2 points
8:35am 2.4 complete, 2 points
8:38am 2.5 complete, 2 points
Frame-Relay complete, 11 points
8:45am 3.1 complete, 3 points
HDLC/PPP complete, 3 points
8:52am 4.1 complete, 2 points
8:56am 4.2 complete, 2 points
9:01am 4.3 complete, 2 points
9:22am 4.4 complete, 4 points
10:07am 4.5 skipped, 0 of 2 points
10:20am 4.6 complete, 2 points
10:28am 4.7 complete, 2 points
10:32am 4.8 skipped, 2 points
10:36am 4.9 complete, 2 points
10:39am 4.10 complete, 2 points
10:42 4.11 complete, 3 points
10:47 4.12 complete, 2 points
10:50 4.13 complete, 2 points
IGP complete, 27 of 29 points
11:16 pingtests complete, beginning lunch
11:35 back from lunch
11:45am 5.1 complete, 3 points
12:04pm 5.2 complete, 2 points
BGP complete, 5 points
BGP Pingtests complete
12:40pm 6.1 complete, 3 points
12:40pm 6.2 complete, 1 point
12:44pm 6.3 complete, 1 point
skipping 6.4, 0/2 points
Multicast isn't working right, I may lose all 7 points here
1:06 7.1 complete, 2 points
1:09 7.2 complete, 1 point
IPv6 complete 3 points
1:17 8.1 complete, 2 points
1:36 8.2 complete, 1 point
1:36 8.3 complete, 2 points
1:36 8.4 complete, 2 points
1:36 8.5 complete, 2 points
QoS complete, 9/9 points
1:42 9.1 complete, 2 points
10.1 complete, 3 points
10.2 complete, 3 points
10.3 complete, 3 points
10.4 complete, 3 points
4.5 -2 points. I was close, need to play with the area command some more
4.8 -2 points. ip ospf authentication null
6.4 -2 points. I knew this--need to research ip pim nbma-mode some more
9.2 -3 points. Need more practice with reflexive acls to be mroe comfortable
9.3 -2 points. aaa authentication password-prompt, username-prompt, login local
10.2 -3 points. snmp-server tftp-server-list
11.1 -2 points. Need more pracitce wtih NAT
Total estimated score, 84
Sunday, February 3, 2008
7:05am lab started
7:26am initial diagrams complete
7:55am final diagrams and readthrough complete--I may complete a mcast diagram later
8:04am troubleshooting complete, 2 points
8:12am 1.1 complete, 3 points
8:14am 1.2 complete, 2 points
8:32am 1.3 complete. It took me a bit to get inarp figured out. Needed a multipoint interface along with the interface-dlci command. Switching from subinterface p to m required a reboot as well., 2 points
8:36 1.4 complete, 2 points
Section 1 and troubleshooting complete. 11 of 11 points
8:41 2.1 complete, 3 points
8:53 2.2 complete, 4 points
9:00 2.3 complete, 3 points
9:02 2.4 complete, 2 points
9:12 2.5 complete, 4 points
Bridging and Switching complete, 16 of 16 points, 27/27 total
9:21 3.1 complete, 3 points
9:25 3.2 complete, 3 points
9:35 3.3 complete, 2 points
9:37 3.4 complete, 2 points
9:40 3.5 complete, 2 points
9:49 3.6 complete, 2 points
9:59 3.7 complete, 3 points
10:14 3.8 complete, 3 points
IGP complete, 20 points, 47/47 total
12:27 pingtests complete. A couple of redis conn needed and all was well
11:06 4.1 complete, 2 points
11:54 giving up on task 4.2. In the real lab I would have moved on much faster
11:59 task 4.3 complete, 3 points
12:02 task 4.4 complete, 3 points
BGP complete, 8/10, 55/57 total
12:22 back from lunch
12:28 task 5.1 complete, 3 points
12:52 task 5.2 complete, 3 points
12:58 task 5.3 complete, 2 points
1:00 task 5.4 complete 1 point
1:07 task 5.5 complete, 2 points
Multicast complete, 12/12, 67/69 total
I'm pretty comfortable with IPv6 so I'm going to skip it
1:14 task 7.1 complete, 3 points
1:22 task 7.2 complete, 2 points
1:39 giving up on task 7.3, how to set the queue depth
2:04 task 8.1 complete, 3 points
2:09 task 8.2 complete, 3 points
2:17 task 9.1 complete, 3 points
2:19 task 9.2 complete, 3 points
2:29 skipping task 10.1, no idea
2:30 skipping task 10.2, no idea
Lab complete, 84/100. Barely passed, but I skipped IPv6 which would have been a relatively easy 7 points
Here's what I missed
Task 4.2--neighbor x.x.x.x remote-private-as
Task 5.2--I needed to use ip pim rp-announce-filter rp-list x group-list y on R1
Task 7.3--I should have trusted my instincts, it used the shape max-buffers command
Task 8.1--I should have used the established keyword on the telnet access list.
Task 8.2--I didn't even think of using a VACL
Task 10.1--Transport preferred non fixes the annoying dns lookup issues
Task10.2--I stink at privilege levels. Learned a little more though.
Saturday, February 2, 2008
12:17 OSPF complete, 10 points
12:32 pingtests complete
12:42 BGP complete, 10 points
12:52 Router Redundancy complete, 8 points
1:04 Multicast complete, 9 points
1:40 IPv6 addressing complete, 8 points
3:45 had to take a break at about 2:30 for some other commitments. Now I ran out of time. I was most of the way through ipv6 routing, so I'll give myself 6 of 9 points.
I'll do QoS in notepad by hand
3:57 QoS completed, 5 points
The focus of this lab was obviously IPv6. I was disappointed I ran out of time because it was a pretty difficult IPv6 scenerio. I was picking things off one by one, just hadn't quite had it finished yet.
Interestingly, there was no ipv6 routing protocol running in between two ipv6 IGPs. I setup a tunnel to overcome this. The answers went with a default route and policy routing instead.