GNS3: Redundant Phase 2 (P2P) DMVPN with Certificate Authentication

I was recently tasked with converting a VPN WAN mesh with 19 nodes on ASAs over to routers. The client initially wanted statically defined VPNs, similar to what they were used to in the ASA scheme. However, that is a lot of keys and configurations. Thankfully, we were able to convince them to allow us to build a DMVPN mesh to avoid all of that static assignment and just let the protocol sort it all out.

As an aside, the calculation to find out how many connections there would be in a VPN mesh is n*(n-1)/2. For 19, that means we were nearly tasked with manually configuring 171 static profiles. Not something I’d relish.

Anyway, the client’s security team asked us to investigate building the dmvpn mesh with certificates to authenticate peers, rather than passwords. A CA infrastructure can be much more secure and manageable than passwords, so we said sure, how hard can it be?

Here’s what the design looks like:

Because DMVPN relies on a “hub and spoke” design, let’s make sure the hub is redundant. Unfortunately there isn’t a good way on Cisco routers to define two hubs under a single interface, so let’s use two tunnel interfaces – tunnel1 (DC1 router is the hub) and tunnel2 (DC2 router is the hub). To allow the hubs to be aware of each other, let’s establish a ‘backplane’ connection between the routers via DMVPN over the WAN. Effectively, this creates two redundant dmvpn networks over the same WAN infrastructure, and then connects them – a redundant, self-healing WAN infrastructure. 

So let’s build it!

1. Crypto – let’s use some SuiteB strong encryption for our WAN (all routers)

crypto isakmp policy 5

 encr aes 256

 hash sha512

! authentication rsa-sig   <-- Note, this is the default, no need to configure it

 group 16

crypto ipsec transform-set dmvpnPhase2 esp-aes 256 esp-sha512-hmac

 mode tunnel

crypto ipsec profile dmvpnCrypto

 set transform-set dmvpnPhase2

2. DMVPN

IP information:

Tunnel1 subnet: 10.255.254.0/24

Tunnel2 subnet: 10.255.255.0/24

Tunnel subnets, host IP: DC1: X.X.X.1 / DC2: X.X.X.2 / Site1: X.X.X.3 / Site2: X.X.X.4

DC1 router public IP: 1.1.1.1

DC2 router public IP: 2.2.2.2

! --- DC1 router – Hub for Tunnel1 DMVPN cloud

! Hub tunnel

int tun 1

 description Tunnel1 - Hub

 ip add 10.255.254.1 255.255.255.0

 ip mtu 1440

 ip nhrp map multicast dynamic

 ip nhrp network-id 1

 tunnel key 1

 tunnel source Ethernet1/1

 tunnel mode gre multipoint

 tunnel protection ipsec profile dmvpnCrypto shared

! Client tunnel

int tun 2

 description Tunnel2 - Client

 ip add 10.255.255.1 255.255.255.0

 ip mtu 1440

 ip nhrp map multicast dynamic

 ip nhrp network-id 2

 ip nhrp map 10.255.255.2 2.2.2.2

 ip nhrp map multicast 2.2.2.2

 ip nhrp nhs 10.255.255.2

 tunnel key 2

 tunnel source Ethernet1/1

 tunnel mode gre multipoint

 tunnel protection ipsec profile dmvpnCrypto shared

! --- DC2 router – Hub for Tunnel2 DMVPN cloud

! Client tunnel

int tun 1

 description Tunnel1 - Client

 ip add 10.255.254.2 255.255.255.0

 ip mtu 1440

 ip nhrp map 10.255.255.1 1.1.1.1

 ip nhrp map multicast 1.1.1.1

 ip nhrp nhs 10.255.255.1

 ip nhrp map multicast dynamic

 ip nhrp network-id 1

 tunnel key 1

 tunnel source Ethernet1/1

 tunnel mode gre multipoint

 tunnel protection ipsec profile dmvpnCrypto shared

! Hub tunnel

int tun 2

 description Tunnel2 - Hub

 ip add 10.255.255.2 255.255.255.0

 ip mtu 1440

 ip nhrp map multicast dynamic

 ip nhrp network-id 2

 tunnel key 2

 tunnel source Ethernet1/1

 tunnel mode gre multipoint

 tunnel protection ipsec profile dmvpnCrypto shared

! --- Client site routers

int tun 1

 description Tunnel1 - Client

 ip add 10.255.254.XXX 255.255.255.0

 ip mtu 1440

 ip nhrp map 10.255.255.1 1.1.1.1

 ip nhrp map multicast 1.1.1.1

 ip nhrp nhs 10.255.255.1

 ip nhrp map multicast dynamic

 ip nhrp network-id 1

 tunnel key 1

 tunnel source Ethernet1/1

 tunnel mode gre multipoint

 tunnel protection ipsec profile dmvpnCrypto shared

! Client tunnel

int tun 2

 description Tunnel2 - Client

 ip add 10.255.255.XXX 255.255.255.0

 ip mtu 1440

 ip nhrp map multicast dynamic

 ip nhrp network-id 2

 ip nhrp map 10.255.255.2 2.2.2.2

 ip nhrp map multicast 2.2.2.2

 ip nhrp nhs 10.255.255.2

 tunnel key 2

 tunnel source Ethernet1/1

 tunnel mode gre multipoint

 tunnel protection ipsec profile dmvpnCrypto shared

3. Routing – EIGRP

Pro tip #1: Make sure to “no next-hop-self” (to allow phase2 direct pathing to occur) and “no-split-horizon” (to allow DMVPN clients to learn about other other client site routes)

Pro tip #2: If you want to redistribute ‘connected’ routes into the routing process, use a route-map to filter the tunnel’s “source” interface, or you’ll end up with eigrp looping errors due to stacked routers – the neighbors will think the best way to get to the tunnel source interface is through the tunnel, which doesn’t make any sense and will break things.

!--- Hub sites

router eigrp ECorp

 !

 address-family ipv4 unicast autonomous-system 5

  !

  af-interface TunnelXX 

   no next-hop-self

   no split-horizon

  exit-af-interface

  !

  topology base

   redistribute static

  exit-af-topology

  network 10.0.0.0

 exit-address-family

!--- Client sites

router eigrp ECorp

 !

 address-family ipv4 unicast autonomous-system 5

  !

topology base

   redistribute static

  exit-af-topology

  network 10.0.0.0

 exit-address-family

4. Certificate infrastructure

Okay, now we have a respectable DMVPN infrastructure. We could either add some static pre-shared keys, or we could build the certificate infrastructure on the routers to allow dynamic, flexible management. Let’s do it. 

Pro tip: On all routers, make sure to set up ntp to an accurate time-source. Certificates are time-stamped, and if your clocks drift too far, your infrastructure might fall apart for what appears to be no reason.

! – NTP, clocks (all routers)

ntp server 132.163.4.101

clock timezone MST -6

clock summer-time MDT recurring

!-- To build certs we need a hostname and domain (all routers)

hostname Hub1

ip domain-name ecorp.com

!-- To allow clients to download their certs (CA server only)

ip http server

!—Certificate server (Only on CA server – we’ll use Hub1 router)

Pro tip: Because of a limitation of GNS3 to store files in flash, I’m storing the certs in nvram. You’re able to store them with ftp, tftp, direct to flash, and many other ways if you’d like.

crypto key generate rsa label hub1-ca modulus 2048 exportable

crypto pki server hub1-ca

 issuer-name CN=Hub1.ecorp.com

 grant auto

 hash sha512

 auto-rollover

 database url nvram:

 database level complete

 no shut

!—Register the router to the CA and get a signed identity certificate.

Pro tip #1: Even the CA server (If participating in DMVPN, like we are doing here) needs to check in with the CA (itself) to get an identity certificate.

Pro tip #2: This doesn’t have to occur over a local network or over a VPN link on the internet – it works just fine over the internet. And the routers are only exchanging public keys, never their private signing keys, so there is little risk here.

crypto key generate rsa label Hub1-dmvpn modulus 2048 exportable

crypto pki trustpoint dmvpn-client

 enrollment url http://1.1.1.1:80

 subject-name CN=XXXX.ecorp.com  <-- Use a unique name, like the router’s hostname

 revocation-check crl

 rsakeypair Hub1-dmvpn

 storage nvram:

 exit

!—Once the trustpoint is built, we need to activate it to accept the CA as valid and get our own router identity certificate to be used for dmvpn authentication.

crypto pki authenticate dmvpn-client

! Provided your router can reach the IP of the CA (public IPs work just fine), the router will download the CA certificate and store it locally. You are asked to accept it.

crypto pki enroll dmvpn-client

! You are asked several questions about downloading your identity certificate. Make sure to say “yes” to downloading your own cert, and the routers will negotiate the rest. 

5. Debugging

If you have any issues, you can use the following commands to troubleshoot the issues. In my experience, these aren’t incredibly useful, but it might help! 

! Debug hub

debug crypto pki messages

debug crypto pki server

debug crypto pki transactions

! Debug spokes

debug crypto pki messages

debug crypto pki server

debug crypto pki transactions

debug crypto isakmp

debug crypto ipsec

debug crypto engine

Profit! 

And that’s it. Clients will be able to authenticate to the hubs and to each other. Clients will automatically roll-over to new certificates when the certs reach their expiration point, and no more user interaction is required at any point.

Also, any routes injected into the routing domain by any client or hub devices will propagate through the dmvpn clouds and direct routing will take over nearly immediately.

Possible venues for making this situation more redundant are more hubs, redundant CA infrastructures, and regionalizing initial routing. 

To regionalize WAN routing so the shortest path is used for the initial connection (before phase2 routing utilized p2p connections), lessen the delay (default 50,000u sec) on the tunnel interface pointed at the local DMVPN hub site. 

Download and play with the topology here. 

Have fun and good luck!

Kyler

Dynamic Group Policy Assignment (Cisco ASA, Windows Radius, Cisco DAP, AnyConnect)

I had the opportunity to set up automatic group-policy assignment on a Cisco ASA from a Windows Radius server. This guide walks through that setup, instructs on Cisco DAP (Deep client inspection). This only shows one group assignment, but it's easy to use these instructions in a lego-like manner and build out dozens of group policies with different access rules.

Requirements

1. Use Radius/AD credentials and user accounts
2. Ease of use for network personnel in order to quickly troubleshoot
3. Simple, extensible features which can be customized to meet future needs
4. Ability to customize access for specific users or specific groups of users to prevent users/partners/contractors from receiving more access than they require for their jobs
5. Ability for non-network IT staff to add remote access to users, but limit non-network staff ability to provide too much access to users
6. Use of familiar tools to ease the transition for affected teams
7. Deep inspection of AnyConnect clients - treat on-domain computers differently from off-domain, same with mobile, mac, linux, etc.

Technical Building Blocks

Each technical building block is covered in turn. When a user attempts to connect, Radius passed a value to the ASAs, instructing them which ‘group policy’ to use on the ASA for that user. ‘Group Policies’ can have ACLs and other security measures implemented on them. We can also utilize Dynamic Access Protection via AnyConnect to ‘deep inspect’ clients that attempt to connect to the network.

Active Directory Security Groups

The security of this system is rooted in Active Directory (AD) security groups, which meets the need to allow non-network IT staff to provide users remote access.

Windows-based Radius

When run from Windows, Radius is natively integrated with AD and can read membership in AD security groups. We should build radius remote access policies based on a specific security group membership.

• These groups are evaluated top to bottom, so if users are part of multiple “VPN” security groups, the first match will be used.
• Based on this remote access policy match, we send an attribute called “Class” as a string to the firewalls when users attempt to VPN in, and this tells the ASAs which “group policy” to use for inbound VPN’d users.

Specific Group-Policies and Associated ACLs

A group policy with the same (caps-sensitive) name as the “class” attribute in radius is created on the ASA. This is where inbound users that match the radius connection policy will be placed.

Access is limited across an entire group policy by associating an ACL that exists on the ASA with a group policy. This ACL is dynamically associated with the inbound VPN session when a user connects. This allows for an extensible, dynamic solution to limit access for inbound connections.

# Create unique subnet
 ip local pool ITNetworkVPNPool 172.16.1.0-172.16.1.250 mask 255.255.255.0

# Create object groups for ACL
 object-group network ITNetworkVPNPool
 description AnyConnect IT Network team pool
 network-object 172.16.1.0 255.255.255.0

# Create group policy
 group-policy ITNetworkVPNGroupPolicy internal
 group-policy ITNetworkVPNGroupPolicy attributes
 wins-server value 10.1.1.1 10.1.1.2
 dns-server value 10.1.1.1 10.1.1.2
 vpn-idle-timeout 30
 vpn-tunnel-protocol IPSec svc
 split-tunnel-policy tunnelall
 msie-proxy method no-modify
 address-pools value ITNetworkVPNPool
 vpn-filter value ITNetworkACLInbound  <-- Use this command to filter only this group of users with a particular local ACL on the firewall. 

# Create tunnel-group
 tunnel-group ITNetworkVPN_TunnelGroup type remote-access
 tunnel-group ITNetworkVPN_TunnelGroup general-attributes
 address-pool ITNetworkVPNPool
 authentication-server-group AAA-Radius
 authorization-server-group AAA-Radius
 accounting-server-group AAA-Radius 
 default-group-policy ITNetworkVPNGroupPolicy 
 password-management
 tunnel-group ITNetworkVPN_TunnelGroup webvpn-attributes
 group-alias ITNetworkVPN enable
 tunnel-group ITNetworkVPN_TunnelGroup ipsec-attributes
 ikev1 pre-shared-key 2yjvi69%6#9v03jdk
 isakmp keepalive disable

Dynamic Access Policies – Client Deep Inspection

When devices running AnyConnect attempt to connect to the ASA, they gather specific information about the inbound device. We can use that information to determinate if we want that device VPN’ing into the network. We can check computer domain, patch level, OS type and version, anything in the registry, etc. We can also check and trigger antivirus and firewall actions.

To accomplish this on the firewall side, we use a feature called Dynamic Access Policies. These allow the firewall to evaluate a connecting client and treat it differently based on the info provided by AnyConnect. If clients do not match any policies, they fall into the default “DftlAccessPolicy” and this terminates their connection immediately.

Dynamic Access Policies are only accessible via the ASDM interface at: Configuration --> Remote Access VPN --> Network (Client) Access --> Dynamic Access Policies

Policies are evaluated in a top-down (higher priority first) fashion. “Deny” steps have an action of “terminate” and “Permit” steps have an action of “continue”. Each step evaluates the information sent to AnyConnect from the client, parses it, and sees if the client meets the requirements for the step.

Cisco AnyConnect

Cisco AnyConnect is Cisco’s new VPN solution. It supports VPN, client evaluation, remote execution of code, triggered A/V updates/programming, and lots more. When users open the tool, they must type in a dns name, like vpn.myDomain.com to initiate connection the first time. After a successful connection, the hostname is remembered.

References

DAP configuration guide: http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/108000-dap-deploy-guide.html

ASA and Windows Radius configuration guide: http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/117641-config-asa-00.html

Good luck configuring your own!
Kyler

Cisco 3850: Wireless Controller/Distributed Config

I've recently had the chance to set up a few WLCs (Wireless Lan Controller) for clients. SiteA is a stack of five 3850 switches. Site B has an MDF of one 3850 and an IDF of one 3850, so I had to set up one MC (Mobility Controller) and one MA (Mobility Agent). They have an interesting wireless design as well - a single WLAN/SSID with vlan assignment by a windows radius server. Let's start with SiteA:

SiteA

5x 3850 with IPBase licensing (IP-base or IP Services licensing is required to be an MC)
8x 2702i WAPs

First of all, this stack will operate as both an MC and an MA. WAPs can be terminated directly to members of this stack, but we have to keep in mind that a stack is only able to support 50 WAPs. We have nowhere near that at this site, but we have to divvy out licenses manually, and we don't want to put them all on one member, in case that member needs to be rebooted, and we don't want to entirely lose wireless capabilities. So I assigned licenses to member1 and member2 of the stack 25 AP termination licenses. The client has to be aware that all APs must be terminated on those switches to build LWAPP tunnels and support the APs.

Turn this stack into a WLC:
wireless mobility controller
wireless management interface Vlan99

! Note: Have to restart after assigning 

wr

reload

Assign licensing
license right-to-use activate apcount 25 slot 1 acceptEULA

license right-to-use activate apcount 25 slot 2 acceptEULA

Because Cisco IOS doesn't support the concept of DHCP reservations, I built 8 individual DHCP pools, one for each WAP. However, DHCP is a little odd on Cisco IOS. If the mac of the WAP is aaaa.bbbb.cccc, you add a 01+(the mac), like this:
ip dhcp pool WAP1
 host 10.10.10.11 255.255.255.0
 client-identifier 01aa.aabb.bbcc.cc
 default-router 10.10.10.11

Create a management interface for yourself and the WAPs to dial into:
interface Vlan10
 description mgmt
 ip address 10.10.10.1 255.255.255.0

Build aaa so we can use it to assign vlans later: 

radius server radiusServer1

 address ipv4 1.1.1.1

 key xxxx

radius server radiusServer2

 address ipv4 1.1.1.2

 key xxxx

!

aaa new-model

aaa group server radius wlanRadius

 server name radiusServer1
 server name radiusServer2
aaa authentication dot1x vlan_assigned group wlanRadius

Enable dot1x to assign vlans and build my first WLAN
dot1x system-auth-control
wlan Vlan_Assigned
 aaa-override
 security dot1x authentication-list vlan_assigned
 broadcast
 no shutdown

Assign ports on switch1 and switch2 as access ports in the management vlan
int range gi 1/0/44 - 1/0/48 , gi 2/0/44 - 2/0/48
 switchport access vlan 10
 switchport mode access

And that's pretty much it. As the WAPs come online, they will pull DHCP from this master switch stack, build an LWAPP tunnel to the core stack, and register with our 3850 WLC/MC.

SiteB 

SiteB is similar in that we have the exact same wlan, but the distribution is a little different. Remember from above, there is an MDF (one AP), and an IDF (5 APs). Now, we could set up each switch as a WLC for their own WAPs, but we'd have to manage them individually, and users would not be able to roam between them. That sounds like a pain. However, there's a better solution. One device still can be a combined MC/MA, and the IDF switch can be only an MA. That means the IDF switch will "check out" licenses from the MDF switch and terminate the LWAPP tunnels on itself, and forward all traffic through yet another tunnel to the MDF switch/MC.

On the MDF switch the configuration for the WLAN, port config, etc. is all the same. There is, however, some extra wireless configuration to build a cluster with the IDF switch.
wireless mobility controller
wireless management interface Vlan10
wireless mobility controller peer-group SiteB
wireless mobility controller peer-group SiteB member ip 20.1.1.2 mode centralized
wireless mobility controller peer-group SiteB member ip 20.1.1.2
wireless mobility group name SiteB
! Note: After assigning the MC role, the device must be restarted

Let's switch to the IDF switch while the MDF/MC device restarts. Now, this device doesn't have very much config at all. It doesn't control DHCP, WLANs, doesn't require any licensing config, and doesn't do radius auth for wireless. All it really needs is to trunk to the MDF switch, assign WAPs to the same access vlan we have on the MDF switch, and have a little bit of config to check out licenses from the MC.
wireless mobility controller ip 20.1.1.1
wireless management interface Vlan10

References

I'd be remiss to not call out the fantastic guides that helped me piece together this configuration and design: http://mrncciew.com/  Several of his specific articles are linked below, and they were invaluable.

http://mrncciew.com/2013/12/14/3850ma-with-5760mc/
http://mrncciew.com/2013/12/06/wlan-config-with-3850-part-2/
http://mrncciew.com/2013/05/21/aaa-override-in-acs5-2/
http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-vlan/117551-troubleshoot-ap-00.html#anc10
https://supportforums.cisco.com/discussion/12022011/2602i-does-not-join-3850-wlc
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3e/wlan/configuration_guide/b_wlan_3e_3850_cg/b_wlan_3e_3850_cg_chapter_011.html#task_DD07B8860F284D85A1CA8E7BFEE3C07D
http://www.cisco.com/c/en/us/support/docs/wireless/5700-series-wireless-lan-controllers/116600-config-eap-radius-00.html#anc7

I'm An Engineer (I Think)

I spend a great deal of time thinking about where my career is headed. Am I making the right decisions, what steps are required to get to the 'next level,' etc. It's symptomatic of my age - the late 20-something disease of 'careers are hard.'

How Did I Even Get Here?

I didn't intend to even DO InfoTech. I initially wanted to be a librarian at the college level, but when I did my research and saw that librarians with 25 years of experience made a salary equivalent to an IT member with less than 5, I realized that I had an opportunity.

I'm not one to do something solely for money. Money doesn't keep you warm at night, it's not something to live for, but I grew up without much of it. I realize that money represents more than a shiny new car. It can mean buying lunch each day, not having to worry about rent or a mortgage, or living month to month and desperately hoping that no one gets sick, or the car doesn't break down. Money matters, shallow as that topic sometimes seems.

But Everyone Knows How Computers Work!

I honestly didn't realize that I had what it takes to "make it" in IT. I assumed that everyone grew up with computers, and took electronics apart to see how they worked.

In my mind, computer competency and unquenchable curiosity is akin to literacy - it's something that I'm sure a few folks miss out on, but most people have it, right?

It turns out that most like modern gadgets, but when it comes to building and fixing them, they prefer not to know. It's more comforting to them to believe that some things in their life are just.. magical.

But I prefer to know. I must know. I think that's all that engineering is - curiosity that can't be turned off. Whether it's mechanical, structural, electrical - it just means that this particular group of people aren't satisfied to know that things work. They have to know how and why.

Hard Problems Vs. Wicked Problems

I enjoy the hell out of network engineering. It's fascinating to study the infrastructure in an environment and tweak it to do all the tricks that are required for complex integrations and automatic failover. There are lots of things to learn in this field, but I feel that most of the tasks here have a solution.

I'm drawn to wicked problems. Wicked problems are not just difficult problems, they are problems that likely don't have a good solution. I feel that computer security is one of those problems.

InfoSec Engineers challenge themselves to think of their environment from every angle. After all, threats come at any organization from many directions, and only one path has to be open to a hacker or disgruntled user to create an incident. And the good guys have to defend every single possible angle of attack, a wickedly unfair dynamic that is regardlessly true.

What's Next?

First, I certified in Security+ (one week of study), Certified Ethical Hacker (3 weeks of study), and now I'm studying for the CISSP (aiming to be done in January). I'm also using my free time to pick up programming languages to start building my fluency - Python, Bash, Perl. Structural languages to build functional tools. 

I'm preparing my tool belt for my next step. Let's get to it. 

kyler

CCIE R/Sv5 Failed - And Not Going Back

My post about starting the CCIEv5 journey is here.

Since I passed the CCIE Route/Switch written exam eight months ago, I've been studying at least two hours six days a week. On the weekends I've tried to set aside more time, sometimes a lot more - around six to eight hours of studying. I also work as a network engineer for my day job for a services provider, so I spend lots and lots of time thinking about and actually applying my networking skills.

The more I work with networks, the more comfortable I've become with the subject, and after passing the written exam and putting in study time, I decided to book the grueling 8.5-hour lab exam for May 15 in San Jose, California.

As soon as I booked the exam I amped up my studying. No more lunches out - I'd rather stay at my desk, eat this dry sandwich and run GNS3 simulations on my personal laptop. Sorry I can't stay out very long, I've got to get back to my studying at home.

I set up complex labs from INE in GNS3, sometimes hooking them up to physical switches to run the switch-only features - ASICs, hardware, and VTP configurations that aren't yet possible in a GNS3 virtual environment. The INE materials are fantastic - the troubleshooting sections are devilishly difficult, and the configuration sections remarkably resembled the lab exam.

Studying at this level is more than a commitment or a part-time job - it's a relationship. One which can be significantly rewarding, but also one of deep stress and anxiety as the date for this difficult exam approaches.

Traveling to San Jose, aka Labs on a Plane

I decided to take my wonderfully supportive wife Lindsey along with me to San Jose, the site of my CCIE exam. I thought that no matter my pass or (probable) failure, Lindsey and I could enjoy a great weekend with friends and exploring around California.

Fourteen months after passing the written exam, Lindsey and I boarded a plane. We flew down Wednesday night late, two days before the test on Friday. I ran through INE labs. All day Thursday I set aside for relaxing and not thinking about studying. I managed to stay away from studying with Lindsey's help for all but an hour, during which I read configurations and sweated. We visited the Cisco site and found the exam center.

I fell into a kind of anxious zen. I knew that the test was just around the corner, but I forced myself to think about the 3,000+ hours I've spent studying this material and breathe.

Test Day (Don't Freak Out)

On Friday morning Lindsey drove me in and dropped me off about 20 minutes early. The traffic was light and the weather was cloudy. I felt excited, anxious, and curious for the upcoming exam. After all, I've been thinking about this exam for 14 months!

The exam was, for the most part, incredibly fun. I'm unable to discuss exam specifics due to Cisco's NDA, but I can say the simulations and questions were, for the most part, exactly what the INE and Cisco Press materials had prepared me for. Routing protocols overlapped; complicated, nuanced questions were asked. I enjoyed the test.

Typical question sets have six objectives per segment. Five of these objectives are highly specific, but tasks that most CCIE-level engineers will be able to answer with careful planning. The sixth is typically a highly nuanced and exacting request about the topic in question. Because of the all-or-nothing style of CCIE exams, each section must be passed in full or not at all, so if you're unable to answer this obscure request, you have not only missed out on all points, but you have wasted very valuable time. Planning is of utmost importance here.

The actual environment was similar to what I imagine a white-collar prison is like. One person is able to use the bathroom at a time. All candidates are treated with suspicion and sometimes hostility if they break a rule. For lunch, the proctor clapped at us to stop our configuration and paraded us out of the computer area and locked the door behind us so we could enjoy 20 minutes of some type of pasta.

I kept on-pace as well as I could, and was able to complete most tasks with careful thought and quick typing. At each section, these nuanced, exacting questions were a challenge, and I was able to complete only some of them.

When the time finished up, I walked out, emotionally, mentally, and physically exhausted. I knew there was a very slim chance that I passed, but I allowed myself some hope. I sat on a bench outside the Cisco campus and called my wife to come pick me up.

Aftermath

I spent the rest of the weekend relaxing with my wife and enjoying our time with friends. For the first time in a very long time, I was present with my wife. I wasn't doing any subnetting or route distribution in my head. I saw a bit more clearly the woman I fell in love with, who I'd been more or less ignoring for the past few months as my studying had kicked into high gear.

In the end, I failed. I passed the first section (Troubleshooting), but failed the Diagnostic and Configuration section of the exam. My configuration sections came back as mostly 0%s - I must have broken a lab rule at some point to get all my work zeroed out. Due to Cisco's confidentiality around the exam, they did not inform me which, if any, rule was broken.

To this point I thought I'd take a few days of relaxing at home and then go back. I'm still confident that I could eventually pass the CCIE - I'm guessing on the third attempt. That attempt would be something like 6 months from now, with constant studying (4-5 hours per day on weekdays, maybe 10-12 on weekends), and about $5,000 MORE dollars. Not to mention the 6 more months of ignoring my wife and my other passions due to this behemoth of a goal.

I Choose Me

In the end, I'd rather have my wife, time, and happiness back. I am still passionate about network engineering, but not to the exclusion of the other parts of my ambition and life! I am passionate about computer security, travel, and enjoying the limited time we all have here.

So goodbye, CCIE number ~#50,000. I have learned an incredible amount, and reaped enormous benefits in my career as I've progressed. I appreciate you for all that you've given me, but you ask too much.

Thanks for the good times, Cisco CCIE. I won't be back.

If you are planning to take the CCIE exam, good luck to you! Next for me is the CompTIA Security+, Certified Ethical Hacker, and then CISSP.
kyler