Category: Workshop

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

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.

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.

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.

Like every recently designed fabric configuration/management platform, NEC ProgrammableFlow controller supports numerous configuration interfaces, including CLI, GUI, web-based configuration, REST API and OpenStack plugin. For more details, watch this part of the ProgrammableFlow Technical Deep Dive webinar.

Once you get rid of spanning tree and associated kludges (not too hard in OpenFlow-based networks), BUM flooding becomes your biggest enemy. NEC’s engineers implemented some interesting features in the ProgrammableFlow switches and controllers: rate-limiting of unknown unicast frames, flooding control, and ARP snooping (if only they’d go for ARP proxy).

Another day, another interesting Expert Express engagement, another stretched layer-2 design solving the usual requirement: “We need inter-DC VM mobility.”

The usual question: “And why would you want to vMotion a VM between data centers?” with a refreshing answer: “Oh, no, that would not work for us.”

A while ago I got an interesting question:

Let's say that due to circumstances outside of your control, you must have stretched data center subnets... What is the best method to get these subnets into OSPF? Should they share a common area at each data center or should each data center utilize a separate area for the same subnet?

Assuming someone hasn’t sprinkled the application willy-nilly across the two data centers, it’s best if the data center edge routers advertise subnets used by the applications as type-2 external routes, ensuring one data center is always the primary entry point for a specific subnet. Getting the same results with BGP routing in Internet is a much tougher challenge.

The ProgrammableFlow Principles of Operations section of the ProgrammableFlow Technical Deep Dive webinar generated tens of questions from the audience – it took us almost 20 minutes to answer all of them (note: you might watch the answers after watching the section that triggered the questions).

The second part of ProgrammableFlow Technical Deep Dive webinar describes ProgrammableFlow principles – physical networks (control, data, HA cluster, management), edge and core switches, topology discovery and end-to-end routing and path setup procedure.