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.

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.

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).

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.