Based on the readers’ comments on my “Bridging and Routing: is there a difference?” post (thanks you!), here are a few more differences between bridging and routing:

Cost. Layer-2 switches are almost always cheaper than layer-3 (usually combined layer-2/3) switches. There are numerous reasons for the cost difference, including:

Peter John Hill made an interesting observation in a comment to one of my blog posts; he wrote “TRILL really is routing at layer 2.”

He’s partially right – TRILL uses a routing protocol (IS-IS) and the TRILL protocol used to forward Ethernet frames (TRILL data frames) definitely has all the attributes of a layer-3 protocol:

• TRILL data frames have layer-3 addresses (RBridge nickname);
• They have a hop count;
• Layer-2 next-hop is always the MAC address of the next-hop RBridge;
• As the TRILL data frames are propagated between RBridges, the outer MAC header changes.

There’s an extremely good reason Brad Hedlund mentioned server virtualization in his career advice: it has fundamentally changed the Data Center networking.

Years ago, we’ve treated servers as oversized IP hosts. From the networking perspective, they were no different from other IP hosts. Some of them had weird clustering requirements, some of them had multiple uplinks that had to be managed somehow, but those were just minor details. Server virtualization is a completely different beast.

Last Saturday I wrote “I’ll write only a few posts per week and try to keep the reading light and not too technical” ... obviously another broken promise. I can only hope you’ve at least enjoyed my bridging-and-routing rants.

In his comment to one of my TRILL posts, Petr Lapukhov has asked the fundamental question: “how is bridging different from routing?”. It’s impossible to give a concise answer (let alone something as succinct as 42) as the various kludges and workarounds (including bridges and their IBM variants) have totally muddied the waters. However, let’s be pragmatic and compare Ethernet bridging with IP (or CLNS) routing. Throughout this article, bridging refers to transparent bridging as defined by the IEEE 802.1 series of standards.

Design scope. IP was designed to support global packet switching network infrastructure. Ethernet bridging was designed to emulate a single shared cable. Various design decisions made in IP or Ethernet bridging were always skewed by these perspectives: scalability versus transparency.

During the last weeks I tried hard to sort out my thoughts on routing and bridging; specifically, what’s the difference between them and why you should use routing and not bridging in any large-scale network (regardless of whether it happens to be cramped into a single building called Data Center).

My vague understanding of layer 2 (Data Link layer) of the OSI model was simple: it was supposed to provide frame transport between neighbors (a neighbor is someone who is on the same physical medium as you are); layer 3 (Network layer) was supposed to provide forwarding between distant end nodes. Somehow the bridges did not fit this nice picture.

As I was struggling with this ethereally geeky version of a much older angels-on-a-pin problem, Greg Ferro of EtherealMind.com (what a coincidence, isn’t it) shared a link to a GoogleTalk given by Radia Perlman, the author of the Spanning Tree Protocol and co-author of TRILL. And guess what – in her opening minutes she said “Bridges don’t make sense. If you do packet forwarding, you should do it on layer 3”. That’s so good to hear; I’m not crazy after all.

When I started using Blogger, it had no “share-me” buttons, so I had to use Feedburner’s FeedFlares to implement the sharing line at the bottom of the post. FeedFlares use JavaScript and each “share-me” line was an extra HTTP request, sometimes resulting in very long loading times of the blog’s home page.

In the meantime, Blogger has implemented sharing buttons and I developed some small bits of JavaScript code for individual articles. As of today, FeedFlares are gone and the first page should load significantly faster than before.

On a tangential note, if you like my articles, please share them. The more you tweet or blog about them, the easier it will be for other networking engineers to find them. Thank you!

This week’s webinars were the last ones before the summer break. I definitely need one, the last weeks were crazy, but I’ve also learned a lot about DMVPN (the need to revisit “old truths” and figure out odd details is what makes preparing for the webinars real fun).

I’ve also noticed that some of have already started you summer vacations. Last week’s blog traffic was way below the usual levels (Cisco Live and Independence Day were only two of the reasons) and this week is still below the average. Obviously it’s time to shift to summer schedule – I’ll write only a few posts per week and try to keep the reading light and not too technical ... the kind of summer campfire stories you’d hear from the geekiest granduncle you could imagine.

Enjoy the summer (while it lasts), have a great time and try to visit some truly spectacular spots; the Dolomites are never a bad choice.

I got this question from the SearchTelecom Ask-the-Expert project ... and the engineer asking the question was probably looking for something short and concise. This is my attempt to explain the difference in a few paragraphs. Have I missed anything important? Could it be done better?

A while ago one of my readers wanted to perform an extended ping from an EEM applet. For whatever reason the extended ping syntax wasn’t good enough for him, so I told him to use the pattern parameter of the action cli command EEM applet statement.

A simplistic explanation of EIGRP offset-list configuration command you might see every now and then is “it adjusts the RD/FD to influence route selection”. If that would be the case, the adjustment would not be propagated to upstream routers (remember: only the EIGRP vector metric is sent in the routing updates, not RD or FD) resulting in potential routing loops (it’s never a good idea to use one set of metrics and propagate another set of metrics to your neighbors).

In reality, the EIGRP offset lists adjust the delay portion of the EIGRP vector metric (which linearly influences the RD/FD value). You can increase the value of the delay metric for EIGRP updates received or sent through a specific interface (or all interfaces). You can also use an access list in the offset-list command, applying changes only to specific IP prefixes. For more details, please read this technology note on Cisco’s web site.

Last days I was eating, drinking, breathing and dreaming DMVPN as I was preparing lab scenarios for my DMVPN webinar (the participants will get complete router configurations for 12 different scenarios implemented in an 8-router fully redundant DMVPN network).

Some of the advanced scenarios were easy; for example, I’ve found a passing reference to passive RIPv2 with IP SLA in the DMVPN/GETVPN Design & Case Study presentation (lost in the mists of time). I knew exactly what the author had in mind and was able to create a working scenario in minutes. Unfortunately, 2-tier hub site with IPSec offload was a completely different beast.

It looks like the signed DNS root zone might finally get deployed on July 15th and Geoff Huston celebrates the fact with a lengthy article on DNSSEC. Just in case you’re not aware what DNSSEC is all about, he’s providing this nifty summary:

A succinct summary of the problem that DNSSEC is intended to address is that DNSSEC is intended to protect DNS clients from believing forged DNS data.

Read the rest of the article on his blog.

DNSSEC deployment could cause some firewalls to hiccup. You might have to change your ASA configuration; zone-based firewall on IOS supposedly works just fine.

When Cisco started preaching about Borderless Networks a few months ago, we all knew the term Borderless Networks was a new fuzzily-defined paradigm revolving around the facts that:

• People want to use their smartphones (and other mobile devices) to access the corporate data from anywhere at any time.
• Employees have started to use third-party cloud services with unproven security or reliability without coordination with corporate IT or Security.

However, when Cisco Press launched the Securing the Borderless Network book (with the subtitle Security for the Web 2.0 World), I was hoping to get some insight into what Cisco really means with the Borderless Networks paradigm. I was also expecting some hard technical facts and solutions for the problems pestering all of us.

One of the scenarios I’m discussing in the DMVPN webinar is redundant DMVPN network with two ISPs. It’s not a particularly complex setup, unless the ISPs decide to deploy anti-spoofing filters (more precisely: unicast RPF checks) in which case it becomes crucially important which outbound interface you use for your DMVPN tunnel.

Anyhow, I was trying to make the whole thing work in a lab and it was repeatedly failing, so I decided to log uRPF violations. According to the documentation, it’s a piece of cake: