Friday Feb 23

Posts Tagged ‘switches’

5 Tips To Save A Bundle On Switches
Last Updated on Tuesday, 5 November 2013 11:07
Written by jj
Saturday, November 9th, 2013

This article by Jennifer Minella originally appeared in Network Computing.

Don’t fall into the vendor trap of buying more than you need. Follow these rules to avoid overspending on your network gear.

We joke about those $200 hammers the government buys, but did you know your organization could be falling victim to the same overspending on network devices? Vendors tend to oversell their customers on the latest-and-greatest technology, often disregarding the customers’ needs and taking advantage of their budgets.

Here are some tips for how to shop for the right switch, and advice to stop overspending on your networking gear. From my experience, following these five simple rules can save you about 60%.  (more…)

Tags: , , ,   |  Posted under Industry Insider, Network Niblets  |  Comments  Comments Off on 5 Tips To Save A Bundle On Switches
Feature Request #1: Stable Code
Last Updated on Monday, 21 July 2008 11:36
Written by JJ
Monday, June 30th, 2008

         I have a note to all network hardware vendors…

Dear network vendor,

As someone that is forced to configure and implement security on your hardware, I would greatly appreciate stable code and properly functioning features. Unfortunately, I cannot always choose the hardware my customers are using in their infrastructure. However, if you would like for me to recommend they continue purchasing and using it, then the product must demonstrate to me that it is: capable, reliable, predictable and well-documented. If your product is not meeting these requirements, I’m forced to recommend other solutions to your (current) customer.

Stable Code. If I have to spend 2-6 hours per implementation working through your product’s bugs, and then must either spend time on a support call or spend time getting packet captures to prove to you it’s not working, I am not a happy camper because you’re slowing down my progress. Your customer is not happy because they’re paying for that time and I’m not cheap.

Features. Don’t publish in technical documentation that your product, or code can do something, only for me to find out later that it cannot. On-site in the middle of an implementation is not the time to architect Plan B. Let me know before, either through technical docs, white papers, best practices or release notes. I do read those. If you want to bend the truth, do it the marketing fluff, not my technical documents.

Documentation. If your product does do what you say it does, then please do document and explain the concepts and procedures. Examples are good, but explanations are mandatory. A correct CLI reference is always lovely as well. If there are got’chas or tricks, please also document those. Again, white papers or release notes are fine. Having to track down the one security engineer from your company that holds the magic key is not practical, nor scalable. Plus, he may be on vacation during my install, which would make me irate.

Support. If your product is not functioning or performing as expected, do NOT expect your customers to have a current maintenance contract to address a known issue or bug (or an un-known issue or bug for that matter). If they found a bug for you, you should probably give them a maintenance contract for a year… or two. If you don’t let us call support, I will find one of your pre-sales engineers and we will use him or her for post-sales support, which is not what you want them to do. But that’s your problem, not mine.

I believe that sums up the major issues. Specifically, I am interested in security, RADIUS, SSH, SNMP, DHCP and 802.1X functions. Before you add another bell or tweak another whistle, please make what you have works… consistently. That should be first, so it’s my Feature Request #1.



# # #

Tags: , , ,   |  Posted under Industry Insider  |  Comments  1 Comment
Why Chassis is Chic
Last Updated on Tuesday, 12 August 2008 03:39
Written by JJ
Tuesday, February 5th, 2008

After a recent post, I received an email from a respected friend of mine about my reference to the advantages of a chassis (or modular) switch platform. He didn’t feel any special love towards chassis based switches, and he’s a pretty smart guy and been around the IT block a few times. It got me thinking, so I though I’d share my Top 10 reasons why Chassis is Chic.

Everyone calls them different things, so in case you’re not familiar with the terminology I’m throwing around- I refer to fixed form factor switches (usually 1U, 24-48 ports) as stackables and the blade-based or larger modular switches with 4-20ish slots as chassis.

10. Price & TCO. Let’s start at the bottom and work our way up. I can’t in good faith tell you that you can always fit more edge ports in a 4U or 7U chassis switch than you could with 4 or 7 48-port stackables. What I can tell you is the per port cost and TCO is usually much less in a chassis. The per-port up front cost is about 18-22% more on a stackable than on the chassis, plus you lose some performance and may have other space and resource consumption. You can run (for example) 288 ports in a chassis while taking up only 2 outlets in your closet, vs 7 outlets for 7 stackables with a max of about 330 ports (more space and outlets required if you’re using external or redundant power supplies on the stackables for PoE).

9. Fiber Aggregation. Inter-building and intra-campus connections are usually fiber runs, so there’s a growing need to support additions of fibers aggregating in the core. There are a few specialty ‘aggregation’ stackable switches from various vendors, but they’re still fixed form, and often have a max of ~30 ports of those connections (1000-SX, 1000-LX/LH). In a standard 6- or 12-slot chassis, you can support up to 288 fiber uplinks in one switch. If you get one of Cisco’s Big Honkers, you can have over 600 SFP ports in one switch. You’d need about 20 of their stackables to match that.

8. The 10 Gig Craze. Over the past 18 months or so, we’re seeing a huge boom in 10GbE demand. Customers are using 10GbE copper (CX4) for high-speed server links and 10GbE fiber (usually over single mode) for connecting to other buildings, and for interlinks between primary and backup sites. The switch manufacturers are offering stackables with options for a 10GbE uplink or two, usually to connect the stackable back upstream. But they’re not really designed to, nor capable of, offering multiple 10GbE interlinks, either up or down stream. The 10 Gig story ties into our next item, fabric speed.

7. Fabric Speed. Here’s something most people don’t stop to think about. Because the chassis based systems can support a higher port density per switch, the fabric speed is much higher, giving a chassis much more performance potential. In fact, it can vary 700% from a stackable to a chassis in the same product family. Whether you are, or aren’t using all the modules/ports on a chassis, you’re probably getting much better throughput since manufacturers shoot for ‘non-blocking architecture’ in chassis- meaning they support wire speed throughout, so as not to over-subscribe the switch. Of course, if you fill that sucker up with 10GbE links… well that’s another story.

6. Power Consumption. There’s a certain amount of overhead for running a system- if you can share that overhead and distribute it over more ports, then you’re getting more bang for your power buck. If you just need a few ports in a remote closet, then you’re surely doing yourself a favor with a small stackable. However, if you’re talking about stacking (physically and virtually) and interconnecting a bunch of lil’uns to make a big’un, then just start with the big’un.

5. Management & Maintenance. I know what you’re going to say… and yes… I know you can stack almost any brand of switches to create a virtual switch stack, manageable by a single IP. But, there’s still an increase in management (and maintenance) overhead. Someone has to connect all those things and keep any updates and changes well documented. Personally, for whatever reason, I just don’t get that warm and fuzzy feeling from virtual stacks. When a stackable goes down, you have to disconnect it, de-rack it all, replace and reverse. With chassis, we generally provision a spare module for critical connections (uplinks, servers) already prepared with the proper VLANs and port attributes. So, if a module goes, the connections can be relocated to the provisioned spare in a matter of minutes, giving you minimal down time.

4. Expansion Flexibility. It happens to everyone. You just needed 34 10/100 ports there last year…. then six months later you needed at least 20 PoE ports, for VoIP phones and a couple of APs. Another nine months rolled by before you added another building, bringing your fiber port requirements to 5. Yesterday you acquired a company and the additional drops for the adopted employees brings your edge port count to 120… again, with more PoE needed for the additional phones. See where I’m going with this? You could have started with a 48-port 10/100 stackable, added on a 24-port PoE switch, thrown on a link aggregation switch and then stacked up a few more to give you 120 edge ports… orrrrrrrr… you could have started with a chassis and just added modules as needed.

3. Integrated Redundancy. I touched on a piece of this in number 5- Management, but there’s more to it. Chassis are designed to give you more flexibility and are therefore, a more suitable platform for incorporating a certain amount of integrated redundancy. Talk to your current switch rep and see if they have a chassis with options for dual fabric modules, redundant management or system modules- I bet they do. Now, ask them if you can get that in any of the stackables. Aside from a hot-swapable power supply and maybe a field-replaceable fan tray, I don’t think you’re going to find much in the way of native redundancy in your stackable.

2. Advanced R&D. A stackable is a fixed-form switch. You may have options for a couple of uplinks, and maybe even 10GbE, but that’s about it. It’s a WYHIWYG – what you Have is what you get- not much more thought and development is going into that switch. For a chassis on the other hand, manufacturers are usually pouring the majority of their switch R&D resources into thinking up new and amazing modules to make your mouth water and your wallet burst open with joy. Just wait- I bet these next couple of years will bring a rainbow of crazy and innovative switch modules… I can’t wait.

      and the Number 1 reason Chassis is Chic

1. They’re Hot! C’mon – just look at a little stackable next to a nice, 7U chassis with blinky lights brimming and multiple modules churning away at all the passing packets. Really- can you beat that? I sure don’t think so.

# # #

Tags: , , , ,   |  Posted under Network Niblets  |  Comments  Comments Off on Why Chassis is Chic
Juniper Switches: Refrigerator Art?
Last Updated on Saturday, 28 January 2012 07:09
Written by JJ
Thursday, January 31st, 2008

I’ve been reading, listening and collecting my thoughts on Juniper’s latest addition to their happy hardware family and I’ve reached a few conclusions. I’d have to give it all a B+… for Blown, way out of proportion (that’s the + part). (more…)

Tags: , , , , ,   |  Posted under Industry Insider, NAC & 802.1X, Network Niblets  |  Comments  Comments Off on Juniper Switches: Refrigerator Art?

More Content

Find more of my content at
- Low Tech Hacking book
- Dark Reading
- Network Computing
- SearchSecurity
- TechTarget

Get Social



Enter your email address:

Delivered by FeedBurner