953 Words. Plan about 4 minute(s) to read this.
A blog reader posted this comment:
Ethan, if you get a chance while blogging, we’d love to hear how all of your study has helped you out at work. Are you seeing things that you have missed in the past when configuring and troubleshooting stuff at work? Are you more value added at work, or is the CCIE stuff too esoteric for the average network engineer?
Preparing for the CCIE has helped me at work, yes. You could say that I’m seeing things that I missed in the past. More specifically, I know possible solutions to problems that I wouldn’t have been aware of before. Here’s a bunch of examples of how CCIE prep has directly impacted my work-a-day world.
- We head-end in our data centers a number of large frame-relay clouds that connect to our larger customers. Our frame customers number in the thousands, and every once in a while, one of them will start transmitting data to us from a bogus source IP. We run a secure environment – if one of our app servers doesn’t know about an IP trying to connect to it, alarms go off. Everytime an alarm goes off, people get excited and want networking staff to track down the source of the rogue IP. Today, this rogue IP issue came up again. While not the only possible answer, a good potential solution to this problem is Unicast Reverse Path Forwarding. That idea popped into my head, almost unbidden, as I was thinking about how to squish rogue IP addresses automatically.
- Yesterday, a colleague called me over to her desk, because she was having trouble turning up switchports in a private VLAN scenario. I didn’t build the private VLAN environment, as that project was owned by a different engineer. But with my CCIE preparation, I was quickly able to look at the IOS config, understand the issue she was dealing with, and help her get the provisioning done that she needed to.
- We’ve been having trouble with poor voice quality for calls coming out of one of our data centers. While I’m more of a routing/switching/load balancer/tcpdump kind of guy, I was able to help the voice engineer find a number of small QoS issues on both switches and routers, and provide him with meaningful feedback while we mulled over next steps.
- And while we’re talking about QoS, I am currently leading a project to rollout MQC-based QoS shaping and prioritization for our frame and IMA clouds. I was able to understand the issue, apply the correct QoS solution to the problem, train others on how the solution works, and document the solution in such a way that all impacted parties could understand it.
- I am typically involved with the BGP work in our company. I’ve gotten SO much better at understanding what’s really going on and how best to set up BGP for some of our extranet connections and Internet connections (even though our BGP is simple).
- GLBP came up in a conversation, and I was able to knowledgeably steer us away from it, as an ineffective solution to the problem it was aimed at.
- We had a problem with some poor guy accidentally assigning the gateway of a particular subnet to be the IP of his new server, essentially knocking that subnet off the air because he duplicated the gateway IP. I put together a solution using switchport ACLs after eliminating DHCP snooping and dynamic ARP inspection as a bad fit for our particular situation. I wouldn’t have even know about possible mitigation strategies without CCIE prep.
There are other things I can see on our network that I’d like to do, but can’t implement, at least not easily. I’d like to move our core to rapid spanning-tree, for example. Also, we run lots of EIGRP – I’d like to start talking to some of our non-Cisco devices with OSPF, and redistribute into EIGRP. I’d like to begin an IPv6 plan, knowing that IPv6 is still years away. I still want to get ready for it, and start testing so that the network is ready before a need for IPv6 is all of a sudden there.
Some stuff I’ve been learning is too esoteric, or at least too esoteric in the context of the network I work with every day. We have essentially no need for multicast, for example. Multicast, in and of itself, isn’t esoteric, but in the context of my network, it’s nothing I have to care about as we have no multicast apps. A lot of the security functions aren’t too necessary in my world, as we have other devices to handle those functions. We’re not going to run TCP Intercept on a router anytime soon, for instance. 802.1x is overkill in our world, although it’s nice to know about. Most of the CCIE-level BGP is overkill – I’m probably never going to write a regex-based AS path filter. I’m probably never going to need to unicast RIP updates. I’m never going to fill-in-the-blank with your worst nightmare OSPF network layered over an unimaginably horrible frame-relay configuration. Etc. There’s a ton of little tweaks and commands that we’re supposed to know as CCIE candidates that for most of our worlds, we’ll never need to use, not ever.
Overall, CCIE preparation has helped me function at the level I want to function at. Even though I don’t have the digits yet, I already have more respect from my coworkers. I definitely get pulled into more design discussions than I used to, as a lot of my colleagues are interested in whatever input I might have to offer. There’s no doubt that for me, CCIE preparation has made a big difference in my work.
about | subscribe | @ecbanks