Show 08 – Something on the Light Side – Part 2

We cover a number of shorter stories this week and chat around various topics:

  • HP and Enterasys as alternate suppliers for Cisco – what are you thinking about
  • Enterasys and their “iSCSI optimised” data centre switches
  • Riverbed released new code which Ethan got quite excited about. Who knew ?
  • And then Greg explains why he doesn’t like WAN Acceleration
  • Norton DNS Beta, tips on Google DNS
  • Discussion on using VMware appliances for network devices and why its’a bad idea.

Links from the Show

Jeremy Stretch can be found his excellent blog and his Twitter is here

Amy Arnold can be found on Twitter with large helpings on snarky comment.

Subscribe in iTunes

You can subscribe in iTunes by clicking on the logo here.

Media Player and MP3 Download

You can subscribe to the RSS feed

Greg Ferro
Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count. He is a host on the Packet Pushers Podcast, blogger at and on Twitter @etherealmind and Google Plus.
Greg Ferro
Greg Ferro
Greg Ferro
Greg Ferro

Latest posts by Greg Ferro (see all)

  • Stink Fleaman

    C'mon Ethan, how don't you call out Greg on the Riverbeds….. you definitely do not need to be a 'rocket scientist' to setup or admin those boxes……

    • Ethan Banks

      We're going to do a WAN optimization show (or two, or three) at some point, for sure. I agree that you don't have to be a rocket scientist to get a Steelhead going. Out of the box, with some basic configuration to get them on the network either inline or with WCCP, you can have them doing TCP optimizations as well as CIFS, MAPI, and HTTP. Throw in the disk cache, and all of sudden you're defying the laws of physics.

      But when the darn things don't work right, there's a lot of headache involved in sorting out the problem. I can't tell you how many hours I have tied up in troubleshooting funky applications that just don't want to be accelerated, because they don't tolerate (usually at the application layer) something that the Steelheads are doing down at layer 4.

      That said, did I let Greg's strong-willed ways run me over a bit in the show? Probably. He's very aggressive, you know. He scares me a lot, especially with all that gym work he's been doing lately. 😉

      • Stink Fleaman

        Fortunately I haven't had any serious issues with the Steelheads…. anyway keep up the good work on the podcast, blog etc, I appreciate you guys (and girls) talking about networking…..

        • Greg Ferro

          Thankyou. We appreciate your feedback.

  • Adam K-F

    Another great DNS server if you ever need a quick one is the 4.2.2.x range:

    These are Layer 3 controlled DNS servers:

  • Brad-F

    Oldest production, network thing in my network:
    Cisco 1600 w/ external CSU/DSU running IOS11.2

    And we work with people who still run token ring (in small quantities).

  • Kevin H

    Throwing b/w at long haul circuits does not resolve the problem of tcp windowing and latency. We have many high b/w long hauls across the globe, pushing gigs and terabytes of data in one-to-many, many-to-one, and many-to-many type transfers. And you can't adjust the windowing parameters for each hosts – and there's no cache.

    For us, RTT across the pond is at a minimum 120ms and EMEA to AP is higher. Without a WAN/Application optimizer-accelerator it would be impossible to push this much data is short amounts of time. Couple acceleration with class based QoS allows us tweak and balance performance of real-time traffic versus batch type (ftp).

    My shop was one of the first customers of Orbital Data (eventually bought out by Citrix), and now using Juniper. Riverbed is certainly the leader but at a cost differential.

    But Greg is right, when there is a problem with the WAN, the accelerator is ALWAYS to blame.