Building Network Automation Solutions
6 week online course starting in September 2017

Open FCoE – Software implementation of the camel jetpack

Intel announced its Open FCoE (software implementation of FCoE stack on top of Intel’s 10GB Ethernet adapters) using the cloudy bullshit bingo including simplifying the Data Center, Free New Technology, Cloud Vision and Green Computing (ok, they used Environmental impact) and lots of positive supporting quotes. The only thing missing was an enthusiastic Gartner quote (or maybe they were too expensive?).

Interesting links (2010-01-30)

Links to interesting content have yet again started gathering dust in my Inbox. Time for a cleanup action. Technical content first:

Cisco Pushing More vNetwork into Hardware. Pretty good description of impact of Nexus 1000V and VN-Link on virtualized network security.

Convergence Delays: SVI vs Routed Interface. Another great article by Stretch. I never realized carrier-delay could be that harmful. The moral of the story is also important: test and verify the device behavior, don’t trust PPT slides (once I’ll share with you how I’ve learned that lesson the hard way).

RFC 6092 - Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service. A fantastic document – now we can only hope that every magazine evaluating consumer IPv6-ready CPEs starts using it as a benchmark (and that the IPv6 Ready guys pick it up).

Stop accidental scheduled router reloads

Alexandra Stanovska wrote an excellent comment to my Schedule reload before configuring the router post:

It may come in handy creating some form of script that would display some basic upon logout - show debug, show reload etc.

The new capabilities of CLI event detector introduced in EEM 3.0 allow us to catch CLI commands in a particular parser mode. Writing an EEM applet that catches exec-mode exit or logout and performs a few checks is thus a trivial task.

VMware cluster: up and running in three hours

A few days ago I wanted to test some of the new networking features VMware introduced with the vShield product family. I almost started hacking together a few old servers (knowing I would have wasted countless hours with utmost stupidities like trying to get the DVDs to boot), but then realized that we already have the exact equipment I need: a UCS system with two Fabric Interconnects and a chassis with five blade servers – the lab for our Data Center training classes (the same lab has a few Nexus switches, but that’s another story).

I managed to book lab access for a few days, which was all I needed. Next step: get a VMware cluster installed on it. As I never touched the UCS system before, I asked Dejan Strmljan (one of our UCS gurus) to help me.

vSwitch in Multi-chassis Link Aggregation (MLAG) environment

Yesterday I described how the lack of LACP support in VMware’s vSwitch and vDS can limit the load balancing options offered by the upstream switches. The situation gets totally out-of-hand when you connect an ESX server with two uplinks to two (or more) switches that are part of a Multi-chassis Link Aggregation (MLAG) cluster.

Let’s expand the small network described in the previous post a bit, adding a second ESX server and another switch. Both ESX servers are connected to both switches (resulting in a fully redundant design) and the switches have been configured as a MLAG cluster (using VSS with Catalyst 6500, vPC with Nexus 7000 or Nexus 5000, or IRF with the HP switches). Link aggregation is not used between the physical switches and ESX servers due to lack of LACP support in ESX.

VMware vSwitch does not support LACP

This is very old news to any seasoned system or network administrator dealing with VMware/vSphere: the vSwitch and vNetwork Distributed Switch (vDS) do not support Link Aggregation Control Protocol (LACP). Multiple uplinks from the same physical server cannot be bundled into a Link Aggregation Group (LAG, also known as port channel) unless you configure static port channel on the adjacent switch’s ports.

When you use the default (per-VM) load balancing mechanism offered by vSwitch, the drawbacks caused by lack of LACP support are usually negligible, so most engineers are not even aware of what’s (not) going on behind the scenes.

Intelligent Redundant Framework (IRF) – Stacking as usual

When I was listening to the Intelligent Redundant Framework (IRF) presentation from HP during the Tech Field Day 2010 and read the HP/H3C IRF 2.0 whitepaper afterwards, IRF looked like a technology sent straight from Data Center heavens: you could build a single unified fabric with optimal L2 and L3 forwarding that spans the whole data center (I was somewhat skeptical about their multi-DC vision) and behaves like a single managed entity.

No wonder I started drawing the following highly optimistic diagram when I was updating my Data Center 3.0 webinar, which now includes information on Multi-Chassis Link Aggregation (MLAG) technologies from numerous vendors (as always, attendees of past webinars get free access to updated materials and recordings).

Interesting links (2011-01-23)

Interesting links keep appearing in my Inbox. Thank you, my Twitter friends and all the great bloggers out there! Here’s this week’s collection:

Cores and more Cores… We don’t need them! More is not always better.

Emulating WANs with WANem. I wanted to blog about WANem for at least three years, now I don’t have to; like always, Stretch did an excellent job.

New Year's Resolutions for Geeks Like Me. The ones I like most: Deploy a pure IPv6 subnet somewhere; Put something in public cloud. And there’s “find a mentor” ... more about that in a few months ;)

Enterprise IPv6 – the First Steps

You might have noticed that IPv6 awareness entered mainstream media, which is always a mixed blessing: on one hand your boss might understand why you need extra budget; on the other hand he might start asking weird questions ... for example what your action plan is (might happen after a golf session with buddies claiming their organization has already deployed this new technology wonder).

If you’re still struggling with the questions like “should I care about IPv6”, “where shall I deploy it first” or “how fast should I react”, my Enterprise IPv6 – the First Steps webinar (register here) is just what you need. I’ll try to answer all these questions and cover other important topics like the differences between IPv4 and IPv6, practical deployment recommendations and the potential impact of IPv6 denial strategy.

VPN Network Design – Part 1

After all the DMVPN-related posts I’ve published in the last days, we’re ready for the OSPF-over-DMVPN design challenge, but let’s step back a few more steps and start from where every design project should start: deriving the technical requirements and the WAN network design from the business needs.

Do I need a VPN?

Whenever considering this question, you’re faced with a buy-or-build dilemma. You could buy MPLS/VPN (or VPLS) service from a Service Provider or get your sites hooked up to the Internet and build a VPN across it. In most cases, the decision is cost-driven, but don’t forget to consider the hidden costs: increased configuration and troubleshooting complexity, lack of QoS over the Internet and increased exposure of Internet-connected routers.

Configuring OSPF in Phase 2 DMVPN network

Phase 2 DMVPN network should behave like a LAN (if you’re not familiar with DMVPN watch the Phase 2 DMVPN fundamentals first). OSPF configuration is thus quite simple ... unless you forget to set the DR priority on the hub router(s) and one of the spokes becomes the DR. Watch the step-by-step OSPF-over-DMVPN configuration guidelines.

Points to remember:

DMVPN Phase 2 Fundamentals

Continuing with the DMVPN Fundamentals series, the following video explains the DMVPN Phase 2 fundamentals and detailed spoke-to-spoke packet flow with dynamic NHRP resolution and IPSec session establishment. Before watching it, you might want to read the “Sometimes you need to step back and change your design” article and watch the Phase 1 Fundamentals video.

Let’s summarize:

OSPF configuration in Phase 1 DMVPN network

This is how you configure OSPF in a Phase 1 DMVPN network (read the introductory post and Phase 1 DMVPN fundamentals first):

Remember:

DMVPN Phase 1 Fundamentals

The following video explains the DMVPN Phase 1 fundamentals and spoke router configuration guidelines (here’s why I started this series of posts):

Let's summarize:

Sometimes you need to step back and change your design

A few days ago I received the following e-mail from one of my readers:

I am trying presently to put in place a DMVPN solution running OSPF. I was wondering if you ever saw a solution with dual hub dual cloud design with OSPF working in practice because since I started I have issue with asymmetric routing because of the OSPF functionality.

Actually, I did ... and exactly the same setup is included in the tested router configurations you get with the DMVPN: from Basics to Scalable Networks webinar (register here). While there are many things that can go wrong with DMVPN, I’ve never heard about asymmetric routing problems, so I started to investigate what’s actually going on.

MPLS/VPN over mGRE strikes again

More than five years after the MPLS/VPN-in-mGRE encapsulation was standardized (add a few more years for the work-in-progress and IETF draft stages), it finally debuted in a mainstream-wannabe IOS release running on ISR routers (15.1(2)T), making it usable for the enterprise WAN designers, who are probably its best target audience.

I was writing about the two conflicting MPLS/VPN over mGRE implementations a while ago and got the impression the Service Providers aren’t too excited about this option. No wonder – most of them use full-blown MPLS backbones, so they have no need for GRE tunnels.

EEM event cli command options and the _exit_status variable

Upendra wrote the following comment to my “EEM CLI patterns are not context sensitive” post:

I am totally confused with sync yes|no skip yes|no. What is the mean of sync and skip, when we use these keywords and what is the mean of yes and no.

The online documentation on this topic is pretty extensive, but obviously not explicit enough, so let’s try to reword it.

Building MPLS/VPN service across an Enterprise WAN

One of the toughest challenges you face when deploying MPLS/VPN in an enterprise network is the WAN transport. If you’re lucky enough to use Frame Relay, ATM or any other layer-2 transport technology (including pseudowires and VPLS), your task is simple: configure mpls ip on the WAN interfaces. The going gets tougher when the only option you have is IP-based WAN connectivity, be it Internet-based VPNs or MPLS/VPN from a Service Provider (don’t even start thinking about Carrier’s Carrier architecture; most SPs would have no clue what you’re talking about).

I’ve described some of the options you have in the “How to prepare enterprise WANs for MPLS/VPN integration” article published by SearchEnterpriseWan; if you need in-depth information, including tested router configurations ready to be deployed in your lab, register for the Enterprise MPLS/VPN Deployment webinar.

Interesting links (2011-01-09)

Jedi Mind Tricks: HTTP Request Smuggling – an intriguing HTTP vulnerability and the countermeasure using ... what else ... F5.

Flailing IPv6 – up to 13% of IPv6 connections fail, mostly due to broken tunnels. Stop tunneling!

Cisco UCS criticism and FUD: Answered – another great article by @bradhedlund. Assuming he’s not making it up, some competitors must be really desperate.

Understanding Inter-Area Loop Prevention Caveats in OSPF Protocol – a masterpiece by @plapukhov. I thought I knew almost everything there is to know about OSPF. Boy was I wrong.

The Big Picture

Remember how I was always saying the big picture is important? Here's the wallystic approach:

Dilbert.com

Using BGP in Phase 1 DMVPN network

If you’re building a DMVPN network with large spoke-to-hub ratio, BGP is one of the better options – it has no scalability limitations associated with multicast flooding; the only parameter you have to consider is the number of BGP sessions the hub router can handle (and according to this presentation, ASR can handle 2000+ spokes). To learn more, watch a step-by-step explanation of BGP-over-Phase 1 DMVPN configuration guidelines.

Recordings of my webinars

One of the regular questions I was getting throughout the last few months was “is it possible to buy just the recording of your webinar?” I tried to solve the problem with Eventbrite-based kludges, but finally gave up and implemented a Google Checkout-based solution. The whole process is extremely easy: select the recordings you’d like to buy from the list of recordings and click the Google Checkout button; you’ll get access to Webex recordings, PDF materials and router configurations (only for select webinars – check the list of documents associated with each webinar) a few seconds after Google processes your credit card information.

Campfire: the true story of MPLS

Just before 2010 disappeared, a tweet by my friend Greg @etherealmind Ferro triggered a minor twitstorm. He wrote:

If we had implemented IPv6 ten years ago, would we have MPLS today? I think not.

His tweet contains two major misconceptions:

  • MPLS was designed to implement layer-3 VPN services;
  • We wouldn’t need VPNs if everyone would be using global IPv6 addresses.

I’ll focus on the first one today; the inaccuracy of the second one is obvious to anyone who was asked to implement MPLS VPNs in enterprise networks to ensure end-to-end path separation between departments or users with different security levels (to learn more about benefits of using MPLS/VPN in enterprise networks, register for my Enterprise MPLS/VPN Deployment webinar).

Schedule reload before configuring the router

John McManus published excellent Remote (in Band) Configuration Tips post on etherealmind.com last week, prompting a “Too bad there isn't a fix for forgetting ‘reload in’” tweet by @mfratto. My immediate reaction was “this should be easy to solve with EEM” ... and it is.

Introduction to Virtual Routing and Forwarding (VRF) tables

Did you know that whenever you use Virtual Routing and Forwarding (VRF) tables in your network (be it on routers or on high-end switches), you’re actually benefitting from one of the MPLS/VPN technologies – VRFs were first introduced by Cisco to support the MPLS/VPN technology.

VRFs are pretty common in enterprise networks; the first half of my Enterprise MPLS/VPN Deployment webinar (register here) thus deals with VRFs, Multi-VRF (also known as VRF-Lite) and all sorts of VRF services, including VRF-aware NAT, per-VRF DHCP pools and interesting combinations of VRFs and GRE tunnels. Here’s the part where I explain what VRFs are as compared to VLANs:

Interesting links (2011-01-02)

New Year Resolution #1: I shall clean my Inbox on a weekly basis. Here are the links that started gathering dust during the last week: