Author: ccie14023

Hub and Spoke VPN Part 1

One of the JNCIE-SP exam objectives I found difficult was hub and spoke VPN. Conceptually it’s not easy, and as is often the case, the documentation is only somewhat helpful. This series of posts is designed to walk you through the concepts of hub and spoke VPN, as well as its basic configuration using BGP, and then OSPF as the PE-CE protocol. Finally I will talk about route reflector issues when using H/S VPN. It is an important topic to master for your JNCIE exam, and if properly explained you will find it’s not as difficult as it seems. This article assumes you are familiar with basic configuration of Layer 3 MPLS VPN, including vrf import and export policies. Note: I recommend that you only use vrf import/export policies for the JNCIE lab and avoid the vrf-target command for layer 3 VPN. We’ll take a simple example topology with three sites.  Normally, if these sites are configured in a Layer 3 MPLS VPN, site 1 and site 2 are able to talk directly over the MLPS network. That is, the traffic between site 1 and site 2 is never seen by the hub site. This is, of course desirable. Routing the site-to-site traffic through a central site could produce significant delays, especially if the geographic distance between the sites is large. It also would consume bandwidth unnecessarily on the...

Read More

The joy of being an “expert”

Ah, the joys of being an “expert.”  I had forgotten what happens after you pass an exam like the JNCIE.  One of my colleagues starts grilling me on various topics for which I am unprepared, since they weren’t covered on the exam.  MX architecture, MC-LAG, MX virtual chassis, etc.  Be careful what you wish for.  The second you put “expert” on your title some people will take it as a challenge.  Of course, being in a very non-hands-on position, I am not an expert in many of the things day-to-day engineers know quite well.  I certainly know the topics on the test.  Then again, having obtained a CCIE 10 years ago, I know better than to start parading myself around as an expert on anything.  The JNCIE number goes on the blog and the bottom of my LinkedIn, but I am not putting it in my email signature.  Meanwhile, time to start reading Doug Hanks’ book on MX...

Read More

TAC Tales #3: GSR

Shortly after I went to work at TAC, my first team, which was dedicated to enterprise customers, was dissolved, and I ended up on the Routing Protocols team.  The RP team supported both enterprise and service provider customers, and I had zero experience on the SP side.  There was quite a learning curve ahead. One day my phone rang with a P1.  I dreaded P1’s.  When a P1 came in, you were thrown head-first into a potentially huge outage with no knowledge of the case in advance.  Often times a case that had been worked by another engineer got raised to P1 and you had to deal with someone else’s mess. On this particular day, the case was a line card problem on a 12000-series, or GSR.  GSR was a service provider box and I knew nothing about it.  I didn’t even think it ran IOS (it does).  I had no idea where to start.  You would think they would have given me training on every product we covered, but at HTTS, at least when I worked there, the general approach was to throw you to the wolves. So, I politely put the customer on hold and started running around the second floor of building K where HTTS is located, shouting:  “Does anyone know GSR?  Anybody around to help me?!”  Finally I stumbled across my teammate Abe in the break room...

Read More

JNCIE-SP Experience

This is a follow-up to my previous post on the JNCIE-SP exam. Some thoughts about the experience of taking the JNCIE exam, especially versus Cisco: The JNCIE exam has a much more relaxed feel to it. When I took my CCIEs (2004 and 2008), the test was administered in a dedicated lab. At that time, you actually had a rack of hardware sitting next to you. You no longer touched the gear, but you could look at it. I developed a habit of talking to my routers while taking the exam, silently of course. I’d look over and say “stop misbehaving” or some such. Hey, it’s a long day. Anyhow, the proctors were seated in cubes around the periphery. I had the impression that they were permanently seated there, even when not administering the exam. Lunch was at the Cisco cafeteria with the proctor as a chaperone, to make sure we didn’t discuss the exam. The JNCIE, on the other hand, was administered in an education services classroom. There was no equipment in sight. The test computers were laptops. I had been advised to bring my own keyboard, which I did both times, and some folks brought their own monitors. I don’t know if all proctors allow this, but I would have hated doing the full exam on the laptop. The proctor has a session open in SecureCRT the...

Read More

Passed JNCIE-SP: Initial Thoughts

Back to the blog, now that the JNCIE-SP is finished. I got #2332. The last time I did an expert-level exam was 2008, and I forgot just how challenging it is. I passed my JNCIP in June and it took me until November, working solidly most of the time, to get my number. It’s been a great experience. I work in a director-level architecture role at Juniper, and I am getting more and more removed from day-to-day, hands-on work. When I was in Cisco TAC, it was extremely technical, detailed work every day. Now it is meetings and PowerPoints. However, my ability to contribute at this level is entirely dependent on my technical expertise, and it feels great to refresh the knowledge and hit the CLI again. They say CLI will be dead with automation and SDN–don’t count on it. They can’t change the fundamental way networks operate, and when you look at SDN solutions, they are a lot more complicated then how they are presented. Being acquainted with MPLS and routing protocols in depth is the best preparation for anything to come, and the only way to learn those topics is at the command line. Period. I will post some more thoughts on the exam and cover specific topic more in depth on this half-neglected blog. Unfortunately it seems to be running a bit slowly, so I will...

Read More