Using Linux as a Router

[Rick Stevens]

Waldher, Travis R wrote:
>>-----Original Message-----
>>From: Rick Stevens [mailto:rstevens at vitalstream.com] 
>>Sent: Wednesday, September 22, 2004 2:04 PM
>>To: Getting started with Red Hat Linux
>>Subject: Re: Using Linux as a Router
>>
>>Waldher, Travis R wrote:
>>
>>> 
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Rick Stevens [mailto:rstevens at vitalstream.com]
>>>>Sent: Wednesday, September 22, 2004 10:01 AM
>>>>To: Getting started with Red Hat Linux
>>>>Subject: Re: Using Linux as a Router
>>>>
>>>>Waldher, Travis R wrote:
>>>>
>>>>
>>>>>Anyone got a how to sitting around?
>>>>>
>>>>>I'de like to use Redhat for my home firewall/router, but 
>>
>>can't find 
>>
>>>>>any good info on how to forward IP from one NIC to the other.
>>>>>
>>>>>I have a machine on the private side NIC(eth1) of the
>>>>
>>>>router that can
>>>>
>>>>
>>>>>ping the public NIC(eth0) of the router.  But nothing beyond eth0.
>>>>>:confused:
>>>>
>>>>You need to set the "ip_forward" flag in the kernel:
>>>>
>>>>	echo 1 >/proc/sys/net/ipv4/ip_forward
>>>>
>>>>To make that permanent, edit /etc/sysctl.conf and look for 
>>
>>this line:
>>
>>>>	net.ipv4.ip_forward = 0
>>>>
>>>>Change the "0" to "1" and save it.  ip_forward will be set 
>>
>>on the next 
>>
>>>>reboot.
>>>>
>>>>If you're going to do a full-up router, don't forget about your NAT 
>>>>rules in iptables (a.k.a. "Masquerade").  For info on that, see:
>>>>
>>>>	http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/index.html
>>>>
>>>
>>>
>>>Thanks, was looking for ip forward everywhere and never wandered my 
>>>way across it.
>>>
>>>Been having a problem with comcast getting ssslloooowwww 
>>
>>from time to 
>>
>>>time.  Got them to agree that if a ping to a comcast 
>>
>>internal IP addy 
>>
>>>showed periods of slowness compared to others.  They would actually 
>>>come out and fix everything no cost to me, and no more arguing that 
>>>it's my equipment causing the problem. :)
>>
>>Good deal.  Remember that broadband is a weird beastie.  
>>Download speeds are pretty fast as it's a direct feed, but 
>>they poll your cable modem periodically to get the upload 
>>stuff.  This is called TDM (time division multiplexing).  I 
>>can explain it as follows:
>>
>>The ISP polls the entire loop N times a second and they have 
>>to service X users per poll.  If you have 1000 users and they 
>>poll 100 times a second, each user has a 500 microsecond 
>>window to get the attention of the poll and can only move as 
>>much data as will fit in that 500uS window.  At T-1 speeds 
>>(1.54Mbps), that's about 770 bits (96 bytes) and the total 
>>upload speed becomes about 77.6 kilobits per second.  Faster 
>>than dialup and many DSLs, but not by much.  The more users 
>>there are, the smaller the window, the less data anyone can 
>>upload per query and the lower the effective baud rate.
>>
>>Many companies don't really do any capacity planning.  They 
>>keep putting people on one of these poll loops until someone 
>>bitches about the performance.  They then set up a new loop 
>>and move some of the people over to the new loop.  Suddenly 
>>the upload window gets longer and performance goes up.  Voila!
>>
>>The behaviour looks like what happens when one puts too many 
>>computers on a shared network segment--although the cause of 
>>slow access in this situation is caused by collisions as a 
>>true LAN doesn't do polling.
>>
>>Hope that makes it a bit clearer.
> 
> 
> Probably more than I wanted to know. Hehehe... Where's my aspirin. LOL
> 
> My problems are download rates... It runs fine 99% of the time, but
> every so often the speed drops to 600 BYTES (yes bytes) per second, at
> times worse, because I can't ping anything on the other side of the
> modem by IP.  Then magically gets better on it's own after an hour or
> so.  Although, if I power cycle the modem it seems to take less time to
> recover.

A slowdown on the poll can cause slowdowns because you're not able to
send either the FTP or TCP "ACK" packets back to the server.  The server
will wait until it gets one before it shoots you more data.

> I'de believe it was my equipment if it wasn't for the fact nothing on it
> changed.
> 
> Right now, my suspect based on past knowledge is the cable from the pole
> to the modem is bad and causing problems their "tests" aren't finding.
> Had a similar thing happen at my parents house that had a 20+ year old
> cable.

That's possible, of course, but I'd expect it to remain pokey if it's
a hardware fault.

The only true way to sort those out is to watch a tcpdump of the session
when the slowdown occurs and see if you keep sending ACKs.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
----------------------------------------------------------------------