Skip navigation
This discussion is archived

Good GIgabit Router

3148 Views 7 Replies Latest reply: Dec 2, 2009 7:03 PM by Douggo RSS
Video Editor1 Calculating status...
Currently Being Moderated
Nov 30, 2009 7:15 AM
I work in a video facility where we transfer huge files from our Xserve to mac, PC and Linuix. We are setting up a gigabit network and we need to purchase a Router that will handle our gig e needs. We have two PC, a linux box and 5 macs that are going to be on the network. They all have gig-e network cards. I am a newbie to all of this, and I was wondering what type of router can handle all this traffic? Anyone have any advice? We do NOT want wireless due to a variety of reasons, and all our computers can handle wired gig-e. I would like the router to handle jumbo packets and it needs to be able to broadcast IP numbers (the Xserve can do DHCP but it really screws up up other networks so if the router can handle it it would make life easier) Thanks.

Xserve, Mac OS X (10.5.5)
  • MrHoffman Level 6 Level 6 (11,695 points)
    Currently Being Moderated
    Nov 30, 2009 7:56 AM (in response to Video Editor1)
    You need to decide if you want cheap and simple, or more complex and more flexible and more expensive.

    The former is an unmanaged Gigabit Ethernet (GbE) switch, and most any reputable vendor offers those for somewhere between US$50 and US$100, depending on the vendor and the numbers of ports. You can spend a little more for uplinks and other features, and for more ports.

    Managed switches tend to be US$250 to, um, more expensive. You'll want managed GbE, which is more expensive than the widespread managed Fast Ethernet switches. And be careful if you do go managed, as many of the vendors include one or two gigabit ports, and the switch then shows up in searches for gigabit switches; most of the ports on these switches are Fast Ethernet and not GbE.

    If you want the switch to handle DHCP, then that's squarely in the managed switch territory, or (if budgets are an issue) an unmanaged switch with the assistance of a commodity firewall router that does DHCP.

    I'd stay away from (cheap) routers, if you're looking for speed. Fast routers are more expensive, and cheap routers are slow. Switches are the usual approach, and a higher-layer managed switch can and often does provide routing.

    And if the Xserve Mac OS X Server DHCP server activity is hosing the network, then the switch or router will likely also screw up the network.
  • Camelot Level 8 Level 8 (45,670 points)
    Currently Being Moderated
    Nov 30, 2009 11:23 AM (in response to Video Editor1)
    Do you want a router or a switch?

    There's a big difference between the two, especially in cost.

    Switches are used to connect systems on a LAN and can, indeed, be had for mere tens or hundreds of dollars (depending on features and port count). Routers link disparate networks (e.g. link your LAN to you ISP's network) and gigabit routers would run into thousands of dollars (or tens of thousands).

    ... and it needs to be able to broadcast IP numbers

    What do you mean by 'broadcast IP numbers'. Broadcasts are part of the ethernet standard, and any device - switch, router, host system, etc. - can handle broadcasts.

    the Xserve can do DHCP but it really screws up up other networks

    How do you mean 'screw up'?
    Mac OS X (10.5.6)
  • MrHoffman Level 6 Level 6 (11,695 points)
    Currently Being Moderated
    Dec 2, 2009 11:55 AM (in response to Video Editor1)
    It may be cheapest and simplest to replace the private "subnetted LAN" scheme here with GbE hardware throughout your network; you're not correctly subnetted here, unfortunately.

    If you want to run a parallel LAN, then you're going to have to deal with IP routing and with link load-balancing and such, as IP by itself typically doesn't (without a mid- or upper-end managed switch or router involved) look at quality of service or at at link load; IP looks for and then at the destination host IP, looks for a direct path to the host, and tosses the packet out to that host or (if the target is not an IP destination address known to the local box) to the IP gateway (default) router. It's a very simple scheme, as network routing schemes and protocols go.

    If you want to run the parallel LAN, then this isn't specifically an issue with DHCP or other such pieces here, this is centrally around how a host gets its address, and where it sends its IP packets.

    Now the "fun" here is in the IP hosts that bridge the LAN and the LAN; both NICs will be viewed as potentially-valid paths for traffic. Short of involving a mid- or upper-end switch or router in the processing here, you're left to manually establish a default route (static route) from one host to another with these LANs; sending all IP traffic down one or the other NICs.

    What usually happens in larger IP networks is what's called subnetting (and which is where you're headed here), where you have a group of nodes that all toss their traffic to a subnet-specific gateway (designated router), and that router then sends the traffic to your firewall or to another subnet-specific gateway. You don't need a gigabit-speed router at your firewall, but you may need a higher-bandwidth switch or router between your own subnets.

    This all gets into IP network design and implementation; there's rather more involved here than the DHCP stuff.

    As for switching (as differentiated from IP and IP subnet routing), recognize that a typical switch goes port-to-port for non-broadcast and non-multicast traffic, meaning you can have (just) gigabit Ethernet links, and the boxes connected (only) to the gigabit Ethernet link will get the speed. The switch will inherently keep (most of) the chatter off the other ports on the local switch, and off the other switches that are interconnected.
  • Camelot Level 8 Level 8 (45,670 points)
    Currently Being Moderated
    Dec 2, 2009 11:56 AM (in response to Video Editor1)
    We have two small switches that do not broadcast DHCP numbers

    OK, sounds like you're confusing your terms. I can guarantee you that your switches do 'broadcast DHCP numbers' because broadcasts are how the client requests a DHCP address and fundamental to how the DHCP protocol works.

    What you want is a device that issues DHCP numbers - in other words a DHCP server. Completely different thing. Not all routers are DHCP servers.

    We need a very small router for these machines so they can be on a seperate LAN gig-e network that we can transfer our huge video files on

    Sounds like you need a switch more than a router.

    ... I set up our Xserve to broadcast a DCHP number ( so I could set up the gig e network and when I did this, it broadcast the IP number to our network

    Then your network design is at fault.

    You shouldn't try to run multiple DHCP servers on the same LAN. Since DHCP uses broadcast for discovery/address assignment you will run into problems with machines getting a DHCP address from the server you don't expect.

    There are ways of running multiple DHCP servers on a LAN but it takes work and should generally be avoided if possible.

    What I need is some advice on a type of inexpensive router that will be able to do this

    Given what you've said it's absolutely clear that you do not need a router. You don't need anything more than a switch. You might even be able to use your existing switch if it supports VLANs.
    Given the small number of machines, it's not even clear that you need DHCP either - you could just configure all these machines manually, using statically-assigned 172.16.x.x addresses.

    If you do want to use DHCP, the XServe can certainly do this without leaking into the 192.168.x.x network - it's just a matter of configuration.

    Assuming you want to use DHCP, your XServe has two ethernet ports. One should be connected to the 192.168.x.x network and you should configure the second one in the 172.16.x.x network.
    Using Server Admin you can enable DHCP to hand out 172.16.x.x addresses on the 172.16.x.x interface (this will prevent the XServe from leaking 172.16.x.x addresses into you 192.168.x.x network.

    Now all you need to do is connect the second port on the XServe (172.16.x.x) to a switch that's separate from your existing switches (or to a separate VLAN on your existing switch if you switch supports VLANs), then connect each other device to this same switch (or VLAN). Given that you have 9 machines that need to be in this 172.16.x.x network, any 16-port gigabit switch will do the job.
    Mac OS X (10.5.6)
  • Douggo Level 4 Level 4 (2,730 points)
    Currently Being Moderated
    Dec 2, 2009 7:03 PM (in response to Video Editor1)
    A sin that I've been guilty of on many occasion - glossing over details..

    What I would like is a router that can assign static IP addresses on a network so all the machines that have a gig-e connector can access this network, which will _not have internet_ but will be high speed.

    What you're trying to set up is a closed private LAN, if none of the machines - _including the XServe_ - are going to have Internet access. At the most, you need only a switch or a set of switches that link the group of computers together.

    Routers need not be involved.

    DHCP doesn't need to come into play either, as long as you can keep track of manually assigned IP addresses within the private LAN.

    Or, as Camelot suggested, you can use the DHCP server built into OS X Server on the XServe to hand out DHCP addresses to clients on the private LAN. Either way, your choice. And if there is no access needed to the Internet or to the other branch of your network in the 192.168.xx.xx range, you're free to use whatever IP address and subnet range you want: convention says to use one of the reserved ranges like 192./24, 172./24 or 10./24

    Mac Pro (2X 3Ghz dual core); MacBook 2GHz C2D; G4 MDD Dual 867, Mac OS X (10.6.2), 20" Cinema Display; 30GB iPod Photo; iPhone; Airport Exteme


More Like This

  • Retrieving data ...

Bookmarked By (0)


  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.