Every Internet-related post is a great opportunity to increase comment count. I’ll pass this time, here are the articles I found interesting with little or no comments from my side. First the generic Internet:

• IPv6 and Transitional Myths – Great mythbuster by Geoff Huston
• Google IPv6 statistics

And then my favorite controversy:

Links to great data center, storage and virtualization articles found in the depths of my bloated Inbox:

Technology short takes by Scott Lowe. A must-read.

Keys to Virtualization Success – this is how you do it right. Great job, Bob!

Ian sent me a really good OSPF-over-DMVPN question after watching my DMVPN webinar:

In the DMVPN webinar you discuss OSPF design and configuration. However, Cisco design guide says you should use a different routing protocol from what you use on your LAN but you seem to suggest it is okay to extend your OSPF network out to the DMVPN edge by continuing to use OSPF albeit in a different area.

The main issue you face when running OSPF over DMVPN is scalability: OSPF does not scale as well as other routing protocols when used over DMVPN.

FullMesh added an excellent comment to my Multi-Chassis Link Aggregation (MLAG) and hot potato switching post. He wrote:

If there are two core routing switches and two access switches which are MLAGged together in both directions, and hosts that are dual-active LAGged to the pair of access switches, then the traffic would stay on whichever side the host places it.

He also opened another can of worms: load balancing in MLAG environment is dictated by the end hosts. It doesn’t pay to have fancy switches that support L3 or L4 load balancing; a stupid host implementing destination-MAC-address-based load balancing can easily ruin your day.

I published this blog post in December 2010. As I was cleaning it up 10 years later, only three out of original 11 links still worked. Whatever…

Some Internet Architectural Guidelines and Philosophy – a must-read for people inventing crazy schemes like load balancing based on unicast flooding or MAC-over-MAC proprietary network virtualization (you know who you are but I doubt you read RFCs or my blog).

GigaOm published two interesting articles by Joe Weinman: in the first one, he describes why pay-per-use residential broadband Internet is probably inevitable, in the second one he predicts changes in user behavior if the service providers decide to implement it. I would also suggest you take time and read his in-depth Market for Melons article.

Obviously, collecting money costs money and the pay-per-use model is no exception (not to mention that most people would pay less), so the service providers prefer usage caps. There are numerous ways to implement usage caps, but implementing usage cap as an acceptable use policy and calling exceeding the cap policy violation is not the way to do it. Some people are truly trying to alienate the users.

Few days ago I had the honor of being the guest speaker at the graduation ceremony of my alma mater. Just in case you’re interested in what I told future Slovenian IT geeks, here’s a short summary.

A while ago I got an interesting challenge from one of my readers: “I would like to attend a few of your webinars, but the problem I have is that I’m interested in most of them. Is there something we can do?” After a few e-mails, we nailed down the concept I had been playing with for quite a while: yearly subscription package. It gives you three unlimited access to all live webinars and year-long access to all the materials and all the recordings I ever made for a fixed price. You can find a detailed description, list of all recordings and list of all available materials on my web site.

After I made the “duct tape of networking” joke, I quickly became a GRE lover (according to @Neelixx – another Twitter account lost in the mists of time). Jokes aside, let’s see where it makes sense to use GRE.

I was listening to the HP Virtual Connect (VC) PPP podcast recently and got the impression that HP VC is a weirdly convoluted product. I started wondering what exactly they were thinking when they were designing it ... and had the epiphany when Ken Henault took a step back and explained the history leading to the current complexity (listen to the Packet Pushers podcast to get the whole story)