I passed the ARCH exam!

It’s been a while since I’ve posted something here. Multiple reasons of course, but lately I just had to focus on learning so much I didn’t take the time for it anymore. Why? Well since I got my CCNP almost three years ago, it had to be recertified. Together with my CCDA that presented the opportunity to gain a CCDP certification and renewing my CCNP at once by just taking one more exam: ARCH.

So it’s been done. Was it hard? I honestly don’t know. So much has changed this last year for me: how I look at my profession, how I look at learning, at certifications,… I can’t compare it anymore to past experiences. So many things I learned outside of the certification path that are so important to have insights as an engineer… Examples like TCP Windowing, ASIC behavior, VRF deployment, application behavior in LAN and WAN (Citrix, SCP, FTP, NTP, vMotion, SCCM), load balancing and SSL offloading, …

All I know that this was a lot of (useful) theory and I had to devise a plan to learn it all, which eventually succeeded. So besides the certification I improved my ability to learn with it. And that in turn gives me strength for the next one: CCIEv5.

Yes, there I said it. For over a year I kept doubting it a bit, saying I wanted it but not putting a date on it. That’s over now. In a month I’ll start preparing the written with hopefully the exam in the first quarter of 2015.

I am ready.

An update…

Well, I haven’t been active here for a while now. The problem is that, while I’m still learning a ton of things, it’s a lot of small things that I find hard to put in a blog post. For example: IS-IS basics, working different spanning-tree types in a network, fine tuning Wireshark, exploring EEM, and wondering what CCIEv5 will bring.

Yes, I’m still going for those numbers one day. Speculations for CCIEv5 are removal of some older topics such as frame relay and more focus of newer technologies. Since I’m working with many newer technologies I’m hoping it will work to my advantage when it’s finally announced.

Honestly, I can’t tell when this blog will be updated again. I’m hoping to find time and inspiration soon, but 1) this blog is a nice collection of information already even if inactive, and 2) learning technologies myself is still more important than putting them on a blog of course.

Greetings to all readers!

CCDA certified!

Yes, another certificate! I took the exam last Monday and I passed. Although I have to admit, I didn’t find this exam easy. At all. But it’s have to compare with past exams because I haven’t taken one in the last year and a half.

That’s also the reason why: my previous certificates will expire in a little over a year. I still want that CCIE but I’m becoming uncertain if I will get it by then, and my company expects a certificate every now and then.

Up next: most likely CCDP. It will require just one exam, ARCH, since I passed ROUTE and SWITCH less than three years ago, and it will recertify my CCNP as well.

As for the CCDA content: interesting and I really learned things, but it’s not one I’d recommend for any engineer. The Routing & Switching track is much more of a challenge.

Best luck to all studying out there!

I may have underestimated this.

I’m probably among the people with the most Cisco knowledge in my team and the only one studying for CCIE.

Yet I was outwitted twice this week by colleagues in troubleshooting, one of which in a pure Cisco design issue. And my CCIE Written test exams (Boson) showed me I was able to answer 40% of the questions correctly. I had expected 50% and up since CCNP would cover about half of it.

So here it is: I may have underestimated this CCIE study. Does that mean I’m giving up? No. But it does mean I’m going to do things differently. For CCIE Written, I dropped lab practice almost entirely, focusing only on theory, hoping to pass the Written fast (my personal deadline was before Cisco Live London this year, so Friday January 25th), then starting lab practice to get the hang of it, fine tuning my skills.

But it appears that’s not how reality works. It’s not even how my own mind works. I can’t study anything I don’t understand, so I’m going to have to do practical research before the Written. It showed clearly in my test results where I scored great on MPLS (which I have worked with), and utterly failed QoS (which I’ve learned, but never practised with).

So here’s the new plan:

• No deadlines, just weekly progress.
• Lab redesign/upgrade.
• A few hours of dedicated lab time per week instead of erratic patches of free time where I randomly plug in some cables.
• Research, research, research.

And as far as colleagues outwitting me goes: well done job, guys. I love to have a challenge and you’re surely providing me with one. Experience counts in this job, and I’m going to need years more to get that to a level where I would be satisfied with myself.

This is how it feels…

… right now when I’m trying to study.

Happy New Year everyone, and good luck in life and studies!

Dynamic Trunk Protocol: Wireshark research.

Time to review something that has been very unclear to me from the beginning: Dynamic Trunking Protocol. First off, it’s a Cisco-only protocol, and let’s be honest, it has no real world uses except acting as a security risk. Second: most literature about it is in fact quite unclear, except the CCIE OCG so far, but even then I’m left with question marks.

So let’s go through the theory first, as this is usually the best way to start:

• DTP sends special frames out of every switchport by default, which can be used to negotiate a trunk link, and negotiate the encapsulation (802.1q or Cisco-proprietary ISL).
• The frames can either be ‘auto’, ‘desirable’, or ‘on’. While ‘desirable’ and ‘on’ actively try to negotiate a trunk, ‘auto’ only negotiates one when the other end is set to trunking.
• The ‘switchport nonegotiate’ command prevents DTP frames from being sent.

Now, let’s see how it goes in practice.

Commands without effect
It’s never mentioned explicitly in any literature I’ve encountered so far, so I tested it just to be sure. The commands ‘switchport access vlan number‘ and ‘switchport trunk allowed vlan numbers‘ do not have any effect on DTP at all. Should the port become an access port, then the ‘switchport access’ command is used to define the VLAN, and the trunk allowed list is ignored. Should the port become a trunk, the trunk allowed list is used and the access VLAN is ignored. Same for ‘switchport trunk native vlan number‘, which is only used should the port become a trunk.

Default configuration
The default configuration of a Cisco switch is to send out DTP auto frames. This means no trunk link will be formed unless configured to do so. And here’s the security risk: if you leave a port in it’s default configuration, someone sending a DTP desirable frame can form a trunk and gain access to all VLANs. In case you’re thinking ‘Oh, this is highly theoretical’: it took me less than 30 minutes to find, download and install Yersinia on a Linux VM and send DTP frames to my home lab switch.

Commands with effect, and their changes
So what actually influences DTP? Two commands, it seems: ‘switchport mode’, and ‘switchport nonegotiate’. I’m listing my findings below, after trying all possible combinations on a switch:

• Default configuration: DTP sends two frames every 30 seconds (a timer that can’t be changed): one untagged frame, one ISL encapsulated frame. Both are DTP ‘auto’ mode (status code 0x03). Since ISL has no concept of native VLAN and some (older) switches only support ISL, sending the second ISL frame makes sense for compatibility reasons. DTP also sends a DTP Type, which is a HEX code listing the supported encapsulation methods.
• ‘switchport mode access’: no DTP frames are sent. At all. The ‘switchport nonegotiate’ does not make any difference.
• ‘switchport mode trunk’: DTP frames are sent in mode ‘on’, with a status code of 0x81. Since you have to choose either ISL or 802.1q as an encapsulation method before you can make the port a trunk, DTP sends this parameter too: 0xa5 for 802.1q and 0x42 for ISL. Also, independent of the encapsulation chosen, DTP will again send two frames: one untagged, one ISL encapsulated.
  Note that this port will operate in trunk mode regardless of what the other end decides. The frames are sent to help the other end in negotiation and choosing the right encapsulation. A port with default configuration will convert to a trunk port when receiving these DTP frames.
  Using ‘switchport nonegotiate’ here stops the sending of DTP frames. Should this port connect to a port with default configuration now, it will still be a trunk, but the other and will stay an access port.
• ‘switchport mode dynamic auto’: this is the default configuration and this line will not even show in the running config.
• ‘switchport mode dynamic desirable’: again like the default configuration, the only difference being status code 0x04, and a trunk will actively form when a port running DTP is connected (no matter the other end’s DTP mode).

Another unexpected command which has effect is the ‘vtp domain name‘: I’ve researched that before.

Practical implications
So what’s best in practice to counter any unexpected behavior, and security risks?
In case of an access port, ‘switchport mode access’ is effective enough as it shuts down DTP on a port. ‘switchport nonegotiate’ is a redundant command, so it doesn’t matter whether it’s applied or not. Just defining ‘switchport access vlan number‘ without the matching ‘switchport mode access’ is a security risk.
In case of a trunk port, I would still recommend disabling DTP, so a static configuration with ‘switchport nonegotiate’ becomes mandatory.
And what if DTP somehow is required to run, can the risk be minimized? (This is theory, if someone requires DTP, you… try to stay calm.) Yes: ‘switchport trunk allowed vlan numbers‘ can be configured to only allow access to the default access VLAN, or even set to ‘none’. This command doesn’t become effective until a trunk is negotiated.
Last, the Nexus series doesn’t run DTP at all, which I personally regard as a huge plus.

So that’s my in-dept research. Probably nothing I will really need in real life, but good to know for the security consequences, as well as some more knowledge for the next certification.

So much to read!

I haven’t posted anything in a while, because I haven’t labbed anything lately. Instead, I’m trying to catch up on my reading. I’ve already mentioned on before that I check the CiscoPress eBook Deal of the Day every day, and over the last eight months, I’ve gathered quite a library of legal eBooks. So far, I haven’t finished a single one of these books, but I have read a lot of chapters in different ones. Let’s list it up (I like making lists):

• Implementing Cisco Unified Communications Voice over IP and QoS (Cvoice) Foundation Learning Guide (CCNP Voice CVoice 642-437), 4th Edition
  The first purchase. I got tempted because I’ve got some IP Phones and QoS, especially combined with voice (as it most often is in reality) sounded like a good topic.
• PKI Uncovered – Certificate-Based Security Solutions for Next-Generation Networks
  Initially an impulsive purchase, but I’m happy with it now as I find this topic difficult to understand (as do many, I notice), but it’s very useful to know when dealing with data security.
• Enterprise Network Testing
  I bought this one halfway my CCNP studies. Since I hadn’t any experience at that moment, picking up some common practices would be nice.
• IPv6 for Enterprise Networks
  It’s IPv6, one of my favorite topics. So that’s a perfect excuse to get out my wallet.
• CCNP Security Secure 642-637 OCG
  With topics like DMVPN, SSLVPN and general security information, why wouldn’t this be good? I’ve got a CCNA Security so the exam is an option too.
• CCDA 640-864 Official Certification Guide (OCG)
  I’m actually studying this now, it’s very theoretical but I like the design insights.
• ARCH Foundation Learning Guide 642-874
  This one became Deal of the Day about two weeks after I found the CCDA OCG. I didn’t hesitate, with ROUTE and SWITCH already done for CCNP, with a bit of luck, this may help me get another professional-level certification.
• Troubleshooting IP Routing Protocols (CCIE)
  A CCIE-level book shows up less than once a month, so I got tempted again.

The above eBooks where all Deal of the Day, so at $9.99, that’s $80 for eight books, two of which came with an exam simulator. Can’t beat that.

Apart from eBooks, I’ve got hard copies too: the three CCNP books and the CCNA Security OCG. Also, I had the chance to borrow a ‘NX-OS and Cisco Nexus Switching’ hard copy from work, which I’m reading right now. EIGRP is a hybrid routing protocol again according to this book. Seriously? But apart from that, the book is really interesting, showing what the Nexus is worth with secured BGP sessions, FCoE, vPC, and so on.

Now I’m off to read some more, and hopefully post something new and interesting next time!

Link-state versus distance vector explained.

Another subject in which I frequently see false claims and misunderstandings to people new in the field: link-state routing and distance vector routing. Also frequently the ‘RIP vs EIGRP vs OSPF discussion’.

First, I have to admit that the CCNA course really covers this poorly. It gives definitions and how to configure the protocols, but not the subtle difference. As such, some people even start categorizing EIGRP as link-state protocol. Why? Because EIGRP has triggered updates, just like OSPF. Unline RIP, which sents out updates every 30 seconds by default.

Yet this is not the important part. What is important is how these routes are calculated. RIP and EIGRP take connected subnets, add a metric to it, and send them to the other routers. Those routers, in turn, add metric to this route (hop count in RIP), and sent them on to the next routers. As a subnet is propagated through the network, the metric increases. A router on the other side of the network that receives an advertised subnet multiple times simply has to select the one with the lowest metric.

Link-state works different: the subnets are advertised from router to router without a metric. There is no increasing metric when the subnet is propagated from one router to the next. What does count is that each link is given a metric, and those links are advertised. So each router in a given area receives a bunch of subnets and a bunch of links through Link-State Advertisements (LSAs). Each router then runs Dijkstra’s algorithm to calculate the shortest path themselves.

So in one phrase: distance vector routers send out ‘this subnet is this much metric away for me’, link-state routers send out ‘this subnet is located here, and I have these links’.

Following that logic, it should be clear now that EIGRP is not a link-state protocol. Not even a so-called ‘hybrid’ protocol. It’s just a distance vector protocol with fancy triggered updates.

This also explains some other OSPF behavior: this is why point-to-point links are treated different from broadcast subnets, because the calculation varies slightly. Link-state also uses slightly more CPU compared to distance vector. And this is why filtering can only be done between areas on an ABR, or on an ASBR. Between areas distance vector logic is applied. Inside an area, every router has the same link-state database. This makes it impossible to filter LSAs, but also nearly impossible to create routing loops inside an area as all routers have all knowledge. OSPF is a very resilient protocol. To form a loop, something like a wrong static route or improper distribution between areas should happen.

And finally, it also explains why an OSPF router-id has to be unique, whereas this is not that important in EIGRP: distance vector does not care about other routers, just advertised metric. Link-state needs to uniquely identify each router and it’s links.

New part for the home lab: access server.

My new equipment arrived before the weekend, but I didn’t notice until Christmas because my girlfriend wrapped it up again and put it as a present under the tree. She’s devious at that.

So what is it? Something I wanted for a long time: an access server. It consists of a 2611XM router, a NM-16A module, two octal cables and a console cable. The whole setup allows me to connect out-of-band to 16 other Cisco devices, so I will not have to plug console cables around ever again. How? Well, I could make a blog post about this, but it’s already explained quite perfectly here by David Davis.

I’ve been negotiating a long time for this (since mid-November), and was able to go under a third of the eBay listed prices for the separate components, so I’m very happy. I can now continue my studies.

Speaking of studies: my next study will be CCDA. I’m facing some uncertainties in my life right now and CCDA seems a more realistic short-term goal compared to CCIE. Not that I have abandoned the quest for Internetwork Expert, but the months to come may not give me enough time to properly study such a big project. Either way, CCDA continues the path, and I’ll be using my home lab to further refine my current CCNP skills. Still moving forward.

CCNP certified!

Yes, I passed TSHOOT two days ago! I just waited to post here until I received the confirmation mail.

And now I’d like to say a lot, but there’s the NDA of course. I will say the following to those attempting CCNP: if you’ve mastered SWITCH and ROUTE with practice labs like I did, TSHOOT is a walk in the park. Just make sure you know a lot of ‘show’ commands and try to troubleshoot everything as logical as possible.

I’m very happy now, I can end 2011 with a goal completed. Up next: who knows? I’m still considering CCIE, but given what amount of knowledge I’ll need to learn, I’m not going to have a lot of time for it next year. But I’ll keep on learning something, that’s for sure. Not standing still here.

Thanks to all who supported me!