I have been defeated by BGP+MPLS

Today I failed BGP+MPLS for the 3rd time. During the exam I thought I had it this time. Many of the questions were repeats and I felt pretty good about the answers. I did do better this time, but I wasn't quite there.

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:

1. 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.
2. Take the R&S CCIE Written again to renew my cert and then decide what to do next.
3. Jump straight to the SP CCIE Written. I might end up failing it repeatedly as well.
4. 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.
   

I think I'm going to knock out the BGP exam because I shouldn't have any problems with it. Then, depending on how that goes, I'll regroup from there.

Failed BGP+MPLS Again!

I tried to pass 642-691 again today and once again I didn't make it. My score actually went down. My wife asked me if that means I got stupider--apparently I have!

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!

Changed MPLS Books Yet Again!

I've now switched over to MPLS Configuration on Cisco IOS Software. This book seems to be the most readable of the bunch and has lots of pretty pictures. I'm going to review the VPN portions here and lab up some of the exercises. I hope to take another stab at the BGP+MPLS exam by Friday.

Failed 642-691 BGP+MPLS

I attempted the BGP+MPLS exam and didn't quite make it. I was hoping my good knowledge of BGP would be enough to carry my through my limited MPLS knowledge.

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.

CCIE Worldwide Statistical Analysis

PBS has an interesting article here regarding the analysis of the number of CCIEs per nation.

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."

CCIE Numbers

Today marks 6 months since I passed the CCIE lab. My number is 20152. A quick look at internetworkexpert shows the most recent number issued using their materials is #21910.

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.

Isn't it Ironic?

I find it ironic that the word asymmetric is spelled with only a single s but double m's. I keep trying to spell it assymmetric, but I guess it sticks better to the meaning of the word the correct way.

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.