Monday, August 28, 2017

My CCIE Lab Experience - Part I

Today, I attempted the CCIE R&S lab. It was my first attempt, and I failed. I haven't received the infamous CCIE lab result e-mail, and I don't need it. I know I failed tshoot, passed diag, and failed config.

I'd like to tell you I was close - something like "I barely missed tshoot by two points, and I would have passed config but ran I out of time." That would make for a nice fluffy blog post. However, that's not the case. I fell apart during tshoot; I knew I failed within the first 90 minutes. I don't think I failed due to lack of protocol understanding. Rather, I buckled under the pressure and sheer intimidation of the lab topology. My structured troubleshooting methodology went out the window, and within minutes, I was reduced to something akin to a blind monkey pounding on a keyboard.

I'll tell you more about my experience in a moment, but first, I'd like to tell you a story. Four years ago, I decided I wanted to complete an Ironman Triathlon. A friend of mine, Nick, had completed several, and I found this inspiring. However, at the time, I hadn't run more than a mile in over ten years. I called Nick and told him I wanted to do an Ironman. His suggestion? Just run a marathon to start.

With less than four months to train, I signed up for my first marathon. I started by running a mile. My knees hurt badly, but I pushed through. Within a relatively short period of time, I worked my way up to running eight miles at once. Eight miles is obviously a far cry from a marathon, but for me, it was an accomplishment.

One week before the marathon, my wife urged me to run the half marathon instead of the full. She said "You've never even run a half! It would still be a huge accomplishment." However, when I commit to something, I follow through. I put on my running shoes and told my wife I would be back in around two hours. That night, I ran my first half marathon in the neighborhood surrounding my house. I hobbled in the front door nearly three hours later with a triumphant smirk on my face and told my wife "Well, I just ran a half. I guess I have to do the full now."

The following week, I stood at the starting line of the Philadelphia Marathon with several friends, most of whom had previously completed multiple marathons and triathlons. I was woefully unprepared, but it didn't matter. I set my mind to running a marathon; I told my friends, family, and coworkers I was running a marathon. More importantly, I told myself I was running a marathon. So damn it, I was running a marathon.

The first ten miles went surprisingly well. The friends I ran with helped keep the pace. However, shortly after mile ten, I told them to go ahead. I could no longer keep up, so I ran alone yet surrounded by 30,000 other runners. By mile twelve, my lack of training had become painfully apparent. My knee hurt badly, and I had over fourteen miles to go. However, the Philadelphia marathon offers an easy out at the half way point. There is a fork in the road. To the right is the finish line for the half marathon. There, you'll be greeted by thousands of cheering onlookers, snacks, and cold beverages. To the left is Kelly Drive, for those running the full marathon. There, the runners become sparse. The crowd thins. The euphoric buzz of the half is replaced by the silent internal battle that characterizes the full.

I chose left. By mile 15, I could not bend my left leg. My knee was simply unable to withstand the impact any longer. I tried stretching to no avail. Running was no longer an option. However, I committed to completing the marathon. I thought "If I can't run across the finish line, I'll drag myself across." And that's what I did. I limped the remaining 11 miles - a painful straight-leg limp that got progressively worse until every fiber of my being wanted to quit. I didn't quit.

When I arrived at the finish line, I heard the announcer congratulating other runners. "Congratulations, Joe, you did it!" he would say. However, his tone changed when he saw me limping in the distance. "Ohh, Matthew, you could have stopped, but you didn't," he announced over the loudspeaker, as I limped across the finish line. I chuckled, and I continued limping until the gold 30th Anniversary Philadelphia Marathon medal was placed around my neck.

I have since completed two marathons and somewhere around ten half marathons. I'm not fast, and I don't consider myself a serious runner. I just enjoy pushing myself beyond my comfort zone. However, that first medal - the medal I earned by limping across the finish line - means far more to me than any of the others. I was slow. I finished almost dead last. But I damn sure earned that medal. I still haven't attempted an Ironman, but I'll get there eventually. I put that goal on hold while I prepare for my CCIE.

Well, that was a bit of a tangent. This post was meant to be a CCIE lab recap, after all. However, I'm beaten down, exhausted, and reminded of that first marathon. I trained much harder for the lab than I did for that marathon, and I still failed. However, I know I accomplished something. I'm one step closer to a pass, and I have a strategy for my next attempt. Tomorrow, I'm booking another lab date.

Tomorrow, I'm also going to write a "part two" post where I detail the specifics of my lab attempt. Just not now. Now, I'm going to get some sleep - a full night, not just four hours of lab-prep sleep.

Monday, April 17, 2017

Using Tasker to Connect to AnyConnect VPN

When I am home, I access local resources over my WiFi network. When I am away, I VPN into my house so I can access these resources. I decided to find a way to have my Android phone automatically connect to my home VPN whenever I'm not connected to my home WiFi network. Enter Tasker: Tasker can automate pretty much anything on an Android phone.

Here is the specific use case I decided to automate:

If connected to SSID "HomeSSID"
    Then disconnect from AnyConnect VPN
If not connected to SSID "HomeSSID"
    Then connect to AnyConnect VPN named "HomeVPN"

As you can see, this is pretty simple logic. However, it's a bit tricky to a accomplish with Tasker and AnyConnect. Here are the methods I looked into:
  1. Create AnyConnect widget and have Tasker "press" the widget:
    • At the time of this post, Tasker does not have the ability to interact with a widget directly.
    • I did not want to use any an additional app to simulate screen presses. TouchTask may be able to do this, but I haven't tried it.
  2. Call intent to tell AnyConnect to connect to VPN:
    • This is probably the most elegant solution. However, after a bit of trial and error, I wasn't able to figure out how to call the intent directly.
  3. Use AnyConnect browser link to call connect to VPN:
    • This is the option that I used.
    • This requires enabling external control of AnyConnect, and is a potential security risk. An attacker could create a link to connect to a VPN, tunnel all traffic, and use it for a man-in-the-middle attack. For my use case, the benefit outweighs the risk.
After a bit of research, I found that Tasker can call intents. According to Google's Android API guide, "An Intent is a messaging object you can use to request an action from another app component." I spent a while reviewing "adb logcat" output trying to determine exactly what intent is called when the AnyConnect widget is pressed hoping I could then call this intent directly. I also used the Android App "Intent Intercept" to no avail.

However, it turns out some apps have intents that can be called through browser links. AnyConnect is one such app. In order for this to work, the "External Control" setting must be set to "Enabled" in the AnyConnect app settings. Once this setting is changed, the following browser link will launch the AnyConnect profile "HomeVPN." This browser link can then be called through Tasker.
I ended up creating two Tasker tasks with two associated Tasker profiles - one to connect to my VPN when not connected to my home wireless network, and one to disconnect from my VPN when connected to my home wireless network. I use certificate-based AnyConnect authentication which makes connecting a bit easier, since I don't need Tasker to pass credentials to AnyConnect. I also found that a two-second delay before connecting to my VPN was often necessary to give my phone enough time to finish transitioning from WiFi to LTE.

Monday, November 14, 2016

Rethinking Micro-segmentation

Traditional Security Architectures

Traditional security architectures enforce security policy at rigidly defined trust boundaries. At the most basic level, this is the perimeter of the network. A firewall sits between the untrusted public Internet and the trusted private network. If inbound access from the Internet is required, a DMZ is often created to segment Internet exposed resources from the trusted internal network. A network can be further segmented using additional zones on the perimeter firewall, access-lists on distribution switches, and additional layers of security at various points in the network.

In this traditional model, as security increases, so does configuration complexity, management overhead, and margin for human error. In addition, implicit trust between devices on a network segment is inherent to traditional security architectures. If one device is breached, an attacker can use the compromised device to launch an attack against other devices on the same network segment. Therefore, traditional security architectures are often ill equipped to secure east-west traffic in a modern data center.

What is micro-segmentation?

In two words: Trust nothing. The goal is to eliminate implicit trust and apply security policy between all devices within the purview of the micro-segmentation solution. By using this zero-trust model, micro-segmentation solutions aim to prevent attackers from moving laterally through a network after breaching an initial target.

There are a few fundamentally different approaches to micro-segmentation in the data center. Several current micro-segmentation solutions are built into larger data center orchestration and automation platforms. I'll avoid mentioning specific products, because comparisons often end up like those of vi vs. Emacs or which is the best Linux distribution.

That said, the solutions I am most familiar with enforce security policy in one of two ways:
    • Enforce policy in the network device and/or vSwitch
    • Enforce policy in the hypervisor kernel

Despite where the actual enforcement occurs, at a high level the micro-segmentation functionality itself is comparable. An engineer logs into a controller, defines a security policy, and centrally pushes this security policy to a number of devices in order to restrict traffic between endpoints. These endpoints can be baremetal servers, VMs, containers, or other resources supported by the micro-segmentation platform. The fundamental difference is the point of policy enforcement - hypervisor, vSwitch, or network device.

Thursday, October 6, 2016

Big Data Analytics for Your Network

The help desk just called. Users are reporting the wireless is down in your office, and nobody can get on the network. The wireless seems fine to you. You're connected. You ask a few people nearby, and they're connected too. You log into the WLC and don't see any problems. works fine. Maybe you should just turn the controller off and then back on again. That worked last time. No, that's a bad idea. It's the middle of the day and you actually need to troubleshoot it.

After a bit of troubleshooting, you determine the cause of the issue is not the wireless. The DHCP scope is exhausted. Users could connect, but they couldn't obtain an IP address. You shorten the lease time, expand the scope, and call it a day. While you're at it, you wonder if DHCP is the reason connecting has been taking longer than usual, so you fire up Wireshark.

Discover, offer, request, acknowledge. You remember that from a CCNA class half a lifetime ago. Looks good. Well, you think it looks good. It takes about 227 milliseconds from discover to offer. That's normal, right? You realize you're not sure what normal is. You don't know your baseline, and you have no idea how long DHCP should take from discover to offer or request to acknowledge. What about dot1x? Is the RADIUS server slowing things down? You really have no idea. It works. It's lunch time. Nobody is complaining - right now.

Ok, hopefully the way you run your network is nothing like this. However, let's face it: this is an exaggerated version of the reality that many deal with on a day to day basis. There is often little insight into the individual operations that contribute to network performance as a whole. "The wireless is down" could mean any number of things, many of which may be out of the purview of the team managing the wireless network. Troubleshooting is often a reactive process. Even when there is visibility into network operations and baselines are known, it can be difficult to determine if your "normal" is actually optimal.

I recently attended a presentation by Nyansa at Networking Field Day 12. Nyansa is a startup focusing on what they call Cloudsourced Network Analytics. Their goal is to go beyond providing visibility in the form of pretty graphs and actually provide actionable insight about how to improve the end user experience.

Friday, September 9, 2016

Mnemonic: Syslog Severity Levels

Ever have trouble remembering syslog severity levels?

I was organizing some old study notes and came across this mnemonic. It's easy to remember, and I'm sure many network engineers can relate.

Everyone always complains even when nothing is different. 

[E]veryone  [A]lways [C]omplains [E]ven  [W]hen    [N]othing      [I]s            [D]ifferent
[E]mergency [A]lert  [C]ritical  [E]rror [W]arning [N]otification [I]nformational [D]ebugging

Level              Description
0 - emergency      System is unusable
1 - alert          Immediate action needed
2 - critical       Critical condition
3 - error          Error condition
4 - warning        Warning condition
5 - notification   Normal but significant condition
6 - informational  Informational message only
7 - debugging      Appears during debugging only

More information about syslog (system message logging):

Saturday, September 3, 2016

Spanning Tree Protocol Visualization - Initial Convergence

Spanning tree: everyone's favorite protocol! Thousands of pages have already been written about spanning tree, so I've decided to take a different approach.

I find it helpful to visualize protocol elections and traffic flow in order to better understand protocol behavior, so I created a visualization illustrating the initial spanning convergence process. This visualization only addresses the initial root bridge election and STP convergence process, for example, if all switches were to boot at the same time. This does not address converging a new STP topology after a topology change.

The visualization below is basically an embedded slideshow that can be advanced by clicking on the image. There are notes for each slide that briefly explain each step of the convergence process. The numbers on each side of the links between switches represent the port number of each uplink.

Here are the basic steps of the initial STP convergence process:
  1. Elect the root bridge.
  2. Determine the root ports.
  3. Determine the designated ports.
  4. Remaining ports are blocking ports.

Click the image to advance the visualization. 

Tap here if you are on a mobile device.

As you can see, the resulting topology (the logical forwarding topology that is created after STP blocks redundant links) looks something like an upside-down tree.

Here is an example of of what this tree might look like when redundant links are blocked by STP in a larger L2 topology (although hopefully your network looks nothing like this). The links shown in black can be used, because each port is in the forwarding state. The links shown in red cannot be used, because one of the ports is in the blocking state. Reducing the topology to a tree of forwarding links is how spanning tree maintains a loop free L2 topology.

Once again, this is not meant to be a complete description of STP, but rather a visualization and basic description of the initial convergence process.

Feel free to leave questions or comments below.

Tuesday, August 9, 2016

Opengear and the Evolution and Consolidation of Network Devices

Opengear at Tech Field Day Extra 2016

I recently attended Cisco Live 2016 in Las Vegas and was invited to attend Tech Field Day Extra as a delegate. The first presenter was Opengear, a maker of console access servers and remote management gateways. They describe their products as "next generation Smart Solutions for managing and protecting critical IT and communications infrastructure."

While the term "next generation" is frequently overused, I can't argue with Opengear. Opengear extends the functionality of a console access server into a more complete out-of-band management solution. First, the Opengear presentation made me reevaluate what I should look for in an a console access server. What should it do? What shouldn't it do, and what roles should be held by separate devices?