Slashdot Mirror


Can You Purchase Switch Hardware Without an OS?

dhahn asks: "I have a project where I'm building a large Linux router (about 40 ports or so). At this point, my only hardware solution is to purchase a box with lots of PCI-ish slots and fill them multi-port ethernet cards. I've looked into currently available solutions and haven't found anything that gives me the control I want. Does anyone know of where I could purchase a 'naked switch?' I just want the switch hardware with enough guts to allow me to customize a Linux OS and load it up." If anyone else has been in this situation, what did you do?

7 of 70 comments (clear)

  1. Re:VLAN by Cecil · · Score: 2, Insightful

    That doesn't seem like a great solution. It's possible I don't understand what you're suggesting, my experience with high end switches is limited, but from what I understand, if I've got Port A transferring to Port B at 100Mbps, and port C transferring to port D at 100Mbps, it would all have to go over the the same trunk (twice!) to be switched by the Linux box, no? Even if the trunk was gigabit and the ports only 100mbps, you can still only have at most 8 ports transferring before you've saturated your switch. If the ports are all gigabit, then you've just hamstrung yourself completely, no?

    If you want to correct me, go ahead, I am a networking newbie, but that just doesn't seem efficient to me compared to actually running Linux at the switch's hardware level.

  2. OS-Less-Switch won't help by Anonymous Coward · · Score: 5, Insightful

    Even if you could buy just an "OS-less" switch, I don't think it would do you any good. Most switches have hardware fast-paths for switching packets. You'd have to completely disable the switching logic, and redirect all frames through the host CPU.

    Some of the switch ASICs I'm familiar with [medium range broadcom, vitesse] are in fact slower at sending a packet through the host control interface, than at simply switching it to a port on which a host cpu might be connected. [Reference designs from the above have the host CPU connected to the host interface, and control packets, ssh, telnet, http, depending on the design captured and sent through it]. In that case, you'd need your host CPU to be connected to one of the ports of the switch, and then of course your routing speed is limited to the maximum speed that can be sent through a single port.

    One of the posters above me mentioned buying a managed switch and using VLAN's, thats what I woulda suggested had he not beat me to it.

    Good Luck!

  3. Get a Cisco by grub · · Score: 2, Insightful

    Forget your hackish idea. Get a Cisco 3750-48 style switch and all will be well.

    --
    Trolling is a art,
  4. Is this even a good idea? by ErikTheRed · · Score: 5, Insightful

    The poster leaves a lot of stuff out - like what's the bandwidth per port? Are they routing analog dial-up lines or gigabit ethernet? What protocols are they routing? Do they need ACLs? How many? Other filtering? Proxying? And if the installation is really that big, just lay out the $jack for a layer-3 or higher switch or router or firewall or whatever.

    Not to be a dick, but if the poster has to Ask Slashdot about this sort of configuration, he or she has no business messing with this and should leave the design and configuration to grown ups (unless it's a lab experiment or something).

    --

    Help save the critically endangered Blue Iguana
  5. VLANs work great for this. by jafo · · Score: 2, Insightful

    Get a normal Linux box with 1 or maybe a few ethernet ports (you can bond them together, if you like), and then connect a 48-port switch that supports VLANing. Set up the ports to the Linux box to pass all 40+ VLANs tagged, and then set the ports that are not connected to the Linux box as untagged ports. You now have each of the switch ports effectively as an interface on the Linux machine.

    I've done this for cases where I needed a small machine to run with more ethernet ports than it's actually got. Works great.

    Sean

  6. Router Hardware != Switch Hardware & Suggestio by grondak · · Score: 5, Insightful

    Hardware switches can look straight at layer 2 encapsulation and shuffle packets based on that information. The switch's main CPU never sees the packet. The "naked" version of the switch still has enough main CPU in it to program the switch controller chip(s). More "clothed" switches have the spanning tree protocol, SNMP bits, and any other cool features you might have.

    Routers have to look at layer 3. Back when I was writing code for a major switch/router manufacturer, most switch chips didn't pass the (de-encapsulated) packet up to the main CPU (or back down). The chip only gave notification that a packet arrived (etc) in the form of an incremented register. This meant the chips were unsuitable for routing because the main CPU had no visibility into the packet whatsoever.

    Either of these designs generally require a separate Ethernet NIC for the main CPU, as the switch ports are too busy with external connections. That NIC might be connected to the switch chip on the switch's main board, or it might appear externally as a "management interface port." You'll be programming this NIC, too-- but hopefully, just with ifconfig(1M)

    Suggestion: Look for commercial switch chips that can pass the packet to and from the main CPU. Find a company which has a COTS switch with the combination of your favorite switch chip and a CPU that will run your Linux version (or uCLinux). Make sure the implementation hardware is wired properly to be able to get the packets to and from the main CPU-- your favorite chip might have a separate HW interface for communicating with the main CPU that could be unconnected in the implementation hardware. At this point, you essentially have the naked switch that can route. Learn how to boot Linux on the implementation hardware and build a flash filesystem that the switch's bootloader will read. Then start writing code to add the capability you require (to routed?).

    Suggestion: Once it works, sell the thing. Or open the source up for others. You went through a lot of trouble to get that capability in the system, and it's got to be so cool because it isn't already in a commercial router. You might consider selling it on the open market yourself, or finding someone to sell it to. Or drop it on Sourceforge for others to upgrade.

    Suggestion: Or, you can get your cool feature embodied as an RFC and get the main router vendors to build it in. Or contribute the code to routed(or whatever). You can probably skip the effort of building this one-off switch/router.

    --
    [Error 407: No signature found]
  7. Zorch depends on your needs by davidwr · · Score: 2, Insightful

    A 40-port router or switch that has typical office workstations with typical "office" use doesn't require a HUGE amount of power. Most users will drive minimal traffic during office hours except when accessing network resources, which will probably be bursty and random in nature. Realisticly, an office like this would probably have a 48- or two 24-port switches costing a few hundred dollars each, with a router to manage external traffic.

    Now, throw half a dozen servers on there along with a few machines that are accessing the outside world 24x7, and now you need some beef and the corresponding dollars.

    If it's 40 servers in a server farm, then you are absolutely correct, the user should be prepared to spend big because a cheap router or switch or PC-based solution just won't do the job.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.