Not Good Enough

You just gone out and spent all your money on a fleet of Packeteer iShapers (or PacketShapers and iShared) and want to use them to optimise your network. So, you plan to run cram as much TCP traffic down your WDC tunnel as possible to make the most of your expensive bandwidth. Of course, some traffic is more important than others, so you also plan to prioritise some of your traffic that’s going through the tunnel. It’s a great plan. Unfortunately, it’s a plan that won’t work.

The Packeteer PacketShapers (or the Inline plane in the iShapers) uses WCCP to redirect traffic destined to go through the WDC or WAFS tunnels. It does this before the traffic passes through its inspection and classification engine. That’s fair enough - you don’t want to be needlessly shaping traffic before it reaches the tunnel or you wouldn’t gain any benefits from the WDC cache.

The problem is that once the data has entered the WDC or WAFS tunnel, the PacketShaper (or the Inline plane) thinks it’s just WDC or WAFS traffic. It can’t classify it any further. So you can’t tell whether its the Payroll Department trying to use Oracle to get everyone paid, BITS updating an SMS repository or someone skiving off in Facebook. That means you can’t prioritise one over the other. The whole reason for buying a PacketShaper has just gone out the window. You would actually have been better off using the PacketShaper with a caching device from one of Packeteers competitors (Cisco, Citrix, Riverbed, etc.).

It’s just not good enough!

You could dedicate a whole site to the problems with this product. However, lets start with just one.

The iShaper is basically a melding of the Packeteer PacketShaper and the Packeteer iShared (a product Packteer acquired through their takeover of Tacit Networks). It consists of two planes - the Inline plane which offers the traditional features of the PacketShaper (QoS and not very good reporting) and the Advanced Services plane which runs Windows and offers WAFS and TCP caching (WDC). On paper this device looks a million dollars. The idea is that you can deploy it to a branch office and have it provide the features of a Windows server (Active Directory, DNS, DHCP, printing) together with WAFS, WDC and your traditional PacketShaper QoS. The PacketShaper part (the Inline plane) does a WCCP redirection to the Advanced Services plane of the traffic that needs to go via the WAFS or WDC tunnels. Note that these devices are pretty expensive - depending on your discounts, a mid range server from a tier one vendor is probably cheaper.

One of the problems with this device is that it doesn’t come with any form of built in remote management of the hardware. If you go out and buy a mid range HP Proliant or IBM xServer you’ll have the option of iLO or RSA to provide remote management of power and a remote console. The remote consoles might be slow because they use a Java client and the tracking of the mice might be poor, but at least you can do it. So, if Windows locks up and RDP doesn’t respond, and the server’s in another country, you can try to fix it.

Not so with the iShaper. They have nothing like iLO or RSA (or DRAC in the case of Dells). If RDP doesn’t work you’re stuffed. If the Advanced Services plane stops responding to the network (and that does happen) you’re stuffed.

Because the Inline plane is basically a separate machine it will still respond. You can still
log on and you can use the reset command. However, you can only reset the Inline plane, not the Advanced Services plane. So, you’re still stuffed.

Packeteer now sells an external IP KVM you can use to access the console. Unfortunately, this device only went on sale some considerable time after the release of the iShaper - and it’s not integrated. Nor does it do anything about the power. If Windows were to have a BSOD you would still be stuffed! This does assume that you can get to the KVM. Sometimes a misbehaving iShaper does strange things to the traffic passing through it - like blocking most of it.

My advice, avoid the iShaper. It’s just not good enough!

Some organisations choose to use a Packeteer PacketShaper on their Internet link. This gives them some rudimentary reporting and the ability to shape their Internet traffic*. When doing this it’s important that the box is secured. One of the steps in securing a PacketShaper is to not allow management access over the outside interface (called securing the interface). Some models also have a MGMT interface. So, why not connect the MGMT interface to the local network and then disable all management access to the Inside and Outside ports. That should allow us to manage the device internally while keeping it safe from all the script kiddies.

Unfortunately, no. To quote the page Specify Security Settings in Packeteer’s PacketGuide:

“Enable/disable access to the unit over the inside and/or outside interfaces (for example, ping, Telnet, or web access). The MGMT port (available on certain models) is considered an outside port. Therefore, securing the outside interface will secure the MGMT port as well.”

Now, some might call me stupid (and may do), but for the life of me I cannot think of any reason why the MGMT port should be linked to the Outside interface. I can think of a reason why it shouldn’t - so I can secure the Outside interface and use the MGMT port to manage the device.

What I can’t figure out is why Packeteer decided to do it the way they did.

It’s just not good enough!

* Shaping traffic like streaming video down to less than 1Kbps is popular. It means that IT can hold their hand on their heart and swear to all things holy that they aren’t blocking such traffic - while making such applications unusable.