Category: load balancing

Every time I talk about small (per-application) virtual appliances, someone inevitably cries “And who will manage thousands of appliances?” Guess what – I’ve heard similar cries from the mainframe engineers when we started introducing Windows and Unix servers. In the meantime, some sysadmins manage more than 10.000 servers, and we’re still discussing the “benefits” of humongous monolithic firewalls.

A while ago I had a discussion with someone who wanted to be able to move whole application stacks between different private cloud solutions (VMware, Hyper-V, OpenStack, Cloud Stack) and a variety of public clouds.

Not surprisingly, there are plenty of startups working on the problem – if you’re interested in what they’re doing, I’d strongly recommend you add CloudCast.net to your list of favorite podcasts – but the only correct way to solve the problem is to design the applications in a cloud-friendly way.

Another day, another stateful debate, this time centered on the number of flows per hypervisor. Previously I guestimated 2.500 connections-per-second-per-(user-facing)gigabit and 37.500 concurrent sessions per user-facing gigabit, but wanted to align my numbers with reality before reaching any conclusions.

My web sites are way too small, so I asked a few of my friends to help me get more realistic figures.

Fast advances in networking technologies (and the pixie dust sprinkled on them) blinded us – we lost our gut feeling and rule-of-thumb. Guess what, contrary to what we love to believe, networking isn’t unique. Physicists faced the same challenge for a long time; one of them was so good that they named the whole problem category after him.

Every time someone tries to tell you what your problem is, and how their wonderful new gizmo will solve it, it’s time for another Fermi estimate.

During the Networking Tech Field Day 6 Spirent showed us Avalanche NEXT – another great testing tool that generates up to 10Gbps of perfectly valid application-level traffic that you can push through your network devices to test their performance, stability or impact of feature mix on maximum throughput.

Not surprisingly, as soon as they told us that you could use Avalanche NEXT to replay captured traffic we started getting creative ideas.

Brad Hedlund wrote another great article, this one explaining the fundamentals of network virtualization. As you'll see, VMware (and everyone else) aims way higher than replacing VLANs with overlay networks. Highly recommended!

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.

Imagine you have a typical 2-tier data center network (because 3-tier is so last millennium): layer-2 top-of-rack switches redundantly connected to a pair of core switches running MLAG (to get around spanning tree limitations) and IP forwarding between VLANs.

Next thing you know, a rep from your favorite vendor comes along and says: “did you know you could connect all ToR switches into a virtual fabric and manage them as a single entity?” Is that a good idea?

Another great question I got from David Le Goff:

So far, SDN is relying or stressing mainly the L2-L3 network programmability (switches and routers). Why are most of the people not mentioning L4-L7 network services such as firewalls or ADCs. Why would those elements not have to be SDNed with an OpenFlow support for instance?

To understand the focus on L2/L3 switching, let’s go back a year and a half to the laws-of-physics-changing big bang event.

Whenever I’m explaining MPLS/VPN technology, I recommend using the same route targets (RT) and route distinguishers (RD) in all VRFs belonging to the same simple VPN. The Single RD per VPN recommendation doesn’t work well for multi-homed sites, so one might wonder whether it would be better to use a different RD in every VRF. The RD-per-VRF design also works, but results in significantly increased memory usage on PE-routers.

Understanding equal-cost multipathing in Brocade’s VCS Fabric is a bit tricky, not because it would be a complex topic, but because it’s a bit counter-intuitive (while still being perfectly logical once you understand it). Michael Schipp tried to explain how it works, Joel Knight went even deeper, and I’ll try to draw a parallel with the routed networks because most of us understand them better than the brave new fabric worlds.

A while ago I was writing about the behavior of Microsoft’s Network Load Balancing, the problems it’s causing and how Microsoft tried to hack around them using multicast MAC addresses as the hardware address of sender in ARP replies (which is illegal). A few days ago one of my readers asked me whether I know which RFC prohibits the use of multicast MAC address in ARP replies.

A quick consultation with friendly Google search engine returned this web page, which contained the answer: section 3.3.2 of RFC 1812 (Requirements for IP Version 4 Routers):

A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address.

Problem solved – now I know the real reason we have to configure static ARP entries on Cisco routers and switches.

Buying a new networking appliance (be it VPN concentrator, firewall or load balancer … aka Application Delivery Controller) is a royal pain. You never know how much performance you’ll need in two or three years (and your favorite bean counter will not allow you to scrap it in less than 4-5 years). You do know you’ll never get the performance promised in vendor’s data sheets … but you don’t always know which combination of features will kill the box.

Now, imagine someone offers you a performance guarantee – you’ll always get what you paid for. That’s what LineRate Systems, a startup just exiting stealth mode is promising.

Last week Juergen Brendel published an interesting blog post describing how you can use vCider to implement high-availability clusters with multi cloud strategy, triggering the following response from one of my readers: “I hadn't heard of vCider before but seeing stuff like this always makes me doubt my sanity – is there really a situation where the only solution is multi-site L2?”

Fernando made a very valid comment to my Monkey Design Still Doesn’t Work Well post: if we would add a few more links between edge and core (fabric) switches to that network, we might get optimal bandwidth utilization in the core. As it turns out, that’s not the case.