Andrew Crouthamel had a great idea – he decided to produce free CCNA-level videos and started a Kickstart campaign to get the funding. The initial response was overwhelming, so he included stretch goals: Wireshark training (WCNA – already reached) and CCNP.

He probably underestimated the costs of the project, but that doesn’t really matter. I’m positive he’ll deliver, so let’s help him get started – if only 10% of my readers donate a single morning Frapuccino to his project, he’ll have more than enough funding to get the whole CCNP curriculum done.

IETF recently published RFC 6877 (464XLAT) describing a dual-translation mechanism that allows an IPv6 host (or CPE) in an IPv6-only access network to pretend it still has IPv4 connectivity. Why would one need a kludge ingenious solution like this? In a word: Skype.

For more details, watch the video explaining the need for 464XLAT and two typical use cases: Android handset and a CPE device (example: SOHO router with 3G uplink).

Arnold sent me an interesting challenge: he’s using two MPLS/VPN providers, with most sites being connected to both providers. He’d like to load balance the inter-site traffic across all PE-CE links – an easy task if you’re using RIP, OSPF or EIGRP as the PE-CE routing protocol, but he happens to be using BGP.

Most application stacks built today rely on decades-old security paradigm: individual components of the stack (web servers, app servers, database servers, authentication servers ...) are placed in different security zones implemented with separate physical devices, VLANs or some other virtual networking mechanism of your choice.

The security zones are then connected with one or more firewalls (when I was young we used routers with packet filters), resulting in a crunchy edge with squishy core architecture.

Operating systems are boring (for most people); it’s the applications that make everyone excited. SDN is no different. Controllers are boring – someone has to reinvent all the wheels that the networking vendors have been inventing for the last 30 years before you can develop the sexy stuff ... but not many people outside of ivory towers would start developing the (supposedly) sexy SDN apps until being sure the underlying platform will not disappear into thin air.

Another great documentary from Scott Adams. Source: dilbert.com

In the ideal world, you’d get a new web page within 100 milliseconds of clicking an active web page component (link, button ...). Reality is way harsher – sometimes it takes seconds till you can enjoy a web page served from a well-behaved web server (let’s pretend there are no server performance issues).

In the first part of my TCP, HTTP and SPDY webinar I explained how the transport mechanisms (TCP and HTTP) impact the end-to-end web application performance and what you could do to reduce the web page loading time.

I did a major overhaul of my RIPE 65 SDN presentation prior to MENOG 12 meeting, including a more comprehensive overview of SDN-related technologies sorted by the networking device plane they operate on.

Two years ago I wrote the another Fermatish post: I described how NHRP behavior changed in DMVPN networks using NAT and claimed that it might be a huge problem, without ever explaining what the problem is.

Fabrice quickly identified the problem, but it seems the description was not explicit enough as I’m still getting queries about that post, so here’s a step-by-step description of what’s going on.

Are you old enough to remember the days when operating systems had no file system? Fortunately I never had to deal with storing files on one of those (I was using punch cards), but miraculously you can still find the JCL DLBL/EXTENT documentation online.

On the other hand, you probably remember the days when a SCSI LUN actually referred to a physical disk connected to a computer, not an extensible virtual entity created through point-and-click exercise on a storage array.

You might wonder what the ancient history has to do with virtual networking. Don’t worry we’re getting there in a second ;)

We learned how to deal with ARP and IP spoofing in IPv4 networks. Every decent switch has DHCP snooping, ARP protection, and IP source guard (or whatever the features are called), but validating source IPv6 addresses in security-conscious environments or public multi-access networks remains a major headache.

It would be pretty easy to solve the problem with a central controller, but IETF decided to go another way and developed yet another framework: Source Address Validation Improvements (SAVI). For more information, watch the following video from IPv6 Security webinar in which Eric Vyncke describes the intricacies of SAVI in great details.

Yesterday I wrote that it’s pretty easy to develop a VLAN provisioning application (integrating it with vCenter or System Center earns you bonus points, but even that’s not too hard), so based on the frequent “I hate using CLI to provision VLANs” rants you might wonder where all the startups developing those applications are. Simple answer: there’s no reasonably-sized market. How would I know that? We’ve been there.

I love(d) listening to the Packet Pushers podcast and came to expect the following rant in every SDN-focused episode: “I’m sick and tired of using CLI to manually provision VLANs”. Sure, we’re all in the same boat, but did you ever do something to get rid of that problem?

One of the first slides I created for the Virtual Firewalls webinar explained various categories of traffic filters, from stateless (and fast) packet filters to application-level firewalls.

As always, the real life is not black-and-white; I found a whole spectrum of products in the wild.

The Controller-Based Packet Forwarding in OpenFlow Networks post generated the obvious question: “does that mean we need some kind of Control-Plane Protection (CoPP) in OpenFlow controller?” Of course it does, but things aren’t as simple as that.