[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Purchasing a wired switch; advice needed [question]



On 20110421_003957, Andrew McGlashan wrote:
> Hi,
> 
> Klistvud wrote:
> >I'm planning to purchase a wired (consumer grade) switch since I've
> >heard they're inherently more robust than (consumer grade) routers,
> >and I'm planning to connect it *directly* to our cable broadband
> >modem. Then, the two families would connect their respective
> >routers (we have some spare wireless routers) to this switch. The
> >various computers and network printers would then be connected, in
> >turn, to these routers.
> >
> >Can a switch juggle two basically separate segments, plus a
> >broadband connection, like that? What capabilities should I be
> >looking for in such a switch?
> >
> >Would it reduce the load on the two routers and do away with their
> >lock-ups?
> >
> >Would it make our two networks more independent, so that one
> >locked-up router wouldn't bring the whole network down? I guess we
> >should separate the shared LAN into two distinct IP subnets?
> 
> Firstly, if you have loads of connections via ANY device to the
> Internet, such as lots of torrents and you do that through NAT (which
> is how it is mostly done), then you'll have large NAT tables.
> Routers will have to keep track of all the traffic that is current
> and it will time out traffic that is old (in it's tables).
> 
> It doesn't matter if it is a switch or a router, at the end of the
> day, you'll end up with the Internet router doing most of the real
> work.  The only way around this, splitting up the connection to two
> nets, is to have multiple IP addresses and have them assigned as
> one-to-one and no NAT in play.  Then each downstream router can
> manage it's own network based on the one [public] IP that is assigned
> to it.  The Internet facing device shouldn't do anything special
> except pass all traffic to the relevant router handling the public
> IP.
> 
> The other thing to consider is using VLANs so that both networks are
> as separated as possible; that will lessen the risk of any person's
> computer from either network being about to attack / infect any
> computer on the other family's network.
> 
> In a nutshell, I don't think your idea to use a switch has any worth
> in this case.  And if you can't get your ISP to provide an extra IP
> (or second distinct cable login to get it's own IP), then you'll have
> these huge NAT table issues with low memory consumer routers possibly
> requiring restarts to clear the tables and start again.

Andrew,

I'm lurking here, looking to better understand a problem that I've never
had to confront: NAT, I understand requires translation tables, one entry
for each active tcp connection. This takes RAM. It also takes enough 
CPU cycles to maintain this table --- set up new connections and find
and delete old connections that are no longer in use. I can see a number
of reasons why the old router would have to quit and need resetting.
I wonder if one of the uplist suggestions which was to set up an old
computer as a router might not work unless the hardware is powerful
enough to keep up with the heavy maintenance activity on the NAT tables.
Extra RMA also implies extra cpu cycles to find and remove old table
entries. It might be that for this service, a somewhat heavy duty
computer is needed. 

Coming from me, the above is little more than idle speculation. I'd be
interested in reading your comments on this speculation. Does it make
any sense?  How might OP go about specifying hardware that doesn't
need resetting in his environment? Would it be likely that some
'industrial strength' routers meet his needs, and others are really
expensive over kill?  Would the appropriate industrial grade router be
a bigger/smaller energy hog than something cobbled together out of an
old computer and junk box network cards? Or compare to new consumer
suitably sized for the job?

Whatever you have time to write will be interesting to me and
might be really useful to OP. 

-- 
Paul E Condon           
pecondon@mesanetworks.net


Reply to: