WAN

Overheard - WAN clustering

“It’s going to involve different parts of your organization to really construct a true WAN cluster. You are going to have to involve your data storage team, your software team, your network engineering team and really look holistically at everything.” Jeff Boles, WAN clustering emerges to provide transparent failover between physical sites

Today’s WhatIs.com Word of the Day is WAN clustering.

Overheard - When won’t IKE work?

IKE negotiation sends and receives messages using UDP, listening on port 500. This can be a problem if you have a firewall in front of your VPN router or are trying to establish an IPsec client connection through a firewall. Michael J. Martin, IPsec VPN router configuration: The ISAKMP policy

I wish I had read this earlier — Michael says “Remember that IKE is a protocol that supports ISAKMP — ISAKMP makes the rules, and IKE plays the game.”

If you’re thinking about implementing a VPN, be sure to read Lisa Phifer’s excellent breakdown on IPSec VPN clients.  Our newest sister site also has some good resources — SearchEnterpriseWAN.com.

Overheard - Do we really need Wide Area File Services?

Lewis Carroll would’ve had a field day satirizing the re-emergence of WAFS (Wide Area File Services), a storage industry acronym with as many meanings as there are vendors offering products. Chase this particular white rabbit down its hole, and Alice the IT manager could embark on a journey at least as bizarre as her namesake’s trip to Wonderland. Jon Toigo, Strategic Info Management: Wide Area File Services

I’ve been reading about WAN optimization this morning and am shaking my head at how vendors seem to be alienating would-be customers by drowning them in proprietary lingo. Dennis Drogset (Network World) did a great job breaking down the issues so I could understand them. 

The issues have been that while WAN optimization products deliver real value on a link-by-link basis, they obscure end-to-end visibility so that strategic planners are left to guess at the real “before” and “after.” They are also typically housed as an appliance with, up until very recently, little interest in integration with the rest of the management community. Finally, as “cheese-stand-alone” solutions, they become costly when scaled to large enterprise environments with hundreds and sometimes thousands of remote locations.

Ok. I get it now.  WAN optimization vendors are scrambling because nobody in their right mind today wants to buy into an expensive cheese-stands-alone solution.

Overheard - How WAN accelerators work

In a typical setup, a WAN accelerator is placed at each end of a WAN link. The appliance sits on the LAN side, on the clear-text side of a VPN device and behind the firewall or Internet router, and intercepts all traffic. The traffic is compressed, sent across the WAN, decompressed by the remote accelerator and then forwarded to the destination. Mike DeMaria, Breaking the WAN Bottleneck

Peter Sevcik also does a really good job explaining how WAN accelerators work and the teaches us the difference between “transparent addressing” (term used by Cisco) and “correct addressing” (term used by Riverbed).

There are two approaches used as seen by the routers between the accelerators. Transparent addressing shows the original client-server source and destination addresses and hides the addresses of the accelerators. Correct addressing shows the addresses of the accelerators and hides the addresses of client-server. Both approaches work. Both approaches have their pros and cons…

In a transparent addressing architecture, the monitoring tools will continue to show network usage by the original client-server addresses and port numbers. But you will not directly see the total traffic carried between the accelerators. Remember that they are masked.

With a correct addressing architecture, traffic monitoring tools will show traffic as having come from/to the acceleration appliances. In this case the client-server traffic volume is masked. However, in both cases the traffic volumes that are reported by routers or probes between the accelerators will be dramatically changed from the original true traffic as seen on the LANs.

In both cases the best solution is to move the network monitoring probes to the LAN-side of the appliance or to gather usage information directly from the appliance itself. Ongoing real-time before-and-after picture of what the accelerators is doing (like how much compression is being achieved) can only be supplied by the accelerators. So we recommend shifting traffic monitoring to the appliance. That way you get same accurate data from either approach.