Thursday, September 18, 2008

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.

Wednesday, September 10, 2008

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

Wednesday, September 3, 2008

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.

Tuesday, September 2, 2008

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.