[TriLUG] why is it slow?

[Aaron S. Joyner]

Greg Cox wrote:

>> The typical way to handle this problem is at the name space level.
>
>
> Not the original poster, but...

Actually, the original poster eventually clarified his problem as:

>umm... i think you got me a little lost :p
>
>my server is at 192.168.123.456
>my surfing computer is at 192.168.123.457
>
>the router forwards to port 80 like it should.
>
>when my dad (out in az) connects, 71.71.789.456 he doesnt have a problem in 
>the world
>
>when i connect to my server71.71.789.456, i get like 6 min load times on a 
>300k image.
>
>when i connect to my server internally, 192.168.123.456, i get instant 
>loading of the same pictures, or different ones that have not been cashed.
>  
>
If he were using a split DNS setup or views, inside his local network he 
would resolve the correct internal IP address for the name of his 
server, and wouldn't be passing traffic through the router.  This would 
effectively solve his problem.


> One reason I don't like handling this via DNS is that I don't have a
> static IP, and I like living with one dyndns name on the outside
> interface.  And I don't get to manage views with them.  And to me it's
> kinda cool to have one name that always works, whether I'm home or away.

Using an external name service provider like dyndns actually makes this 
*easier* than the way I'd prefer to do it, which is to host my own 
authoritative DNS.  Let's say your domain is called, oh, I don't know... 
"example.dyndns.org".  You setup an internal name server at 
192.168.1.42, and make it authoritative for the domain 
example.dyndns.org, including an A record for that very domain, which 
points to the IP of the appropriate server.  You also configure it with 
"forwarder" entries to your local ISP's DNS server (or what ever your 
clients used to use before this change).  Then update your client's DNS 
server entries to point to the local DNS server, and voila, you're 
done.  :)  Resolution from the outside world will naturally recurse up 
to dyndns's actual entry, and they'll get your external IP.  Internal 
resolvers will hit your local DNS server, and when asking for 
example.dyndns.org, the server returns it's local authoritative answer.  
When asking for other records in the dyndns.org domain name, the local 
server isn't authoritative, so it forwards those requests along to 
dyndns.org, and they resolve naturally.

>> that this is dramatically easier to do on an honest-to-god router.
>
>
> I think it's not the Linux tools, so much as the network layout.  It
> becomes easier when you segment up the network to where you use the
> gateway box like a router.  Most of the problems I'm hearing are from
> trying to do this magic routing all on one internal network, which is
> going to kill you ded.

Yes, as the rest of your post pointed out, it's entirely possible to go 
through and solve this problem with multiple networks for the servers vs 
the clients.  I briefly thought about suggesting a solution along these 
lines, but redesigning the network isn't really solving the 
interestingly complex problem at hand.  Having said that, this complex 
problem is definitely something that the iptables / iproute2 tools 
should be able to do.  They're capable of rewriting the source, and the 
destination, and building tables to map them back on the reverse 
paths... it's just that some of the trade-offs made in the interest of 
avoiding loops, overly complex rules, etc make this unfortunately not 
possible with the existing tools, as far as I can see.  So I stand by my 
original assertion that it's a short-coming in the tools, that they 
can't handle this particular solution gracefully. 

Aaron S. Joyner


> My setup: cablemodem to liveCD linux router.  Router with 4 internal VLAN
> interfaces (DMZ, wired desktop network, WPA2 trusted wireless, WEP
> untrusted wireless (for the NintendoDS)) to VLAN-aware switch, with a
> bastion server on the DMZ VLAN.
>
> Currently I have a rule on the router:
> -A PREROUTING ! -i vlan2 -p tcp -m tcp --dport 22 -j DNAT --to
> 192.168.2.20
>
> Now, actually, that rule stinks since it means I can't ssh out from my
> lappy to the world, but, I never do that from not-the-DMZ anyway, so, 
> it's
> kinda ok.  I should really do something like (untested!):
>
> -A PREROUTING ! -i vlan2 -m addrtype --dst-type LOCAL -p tcp -m tcp
> --dport 22 -j DNAT --to 192.168.2.20
>
> But the cdrouter I'm using, its iptables version is too old to use 
> addrtype
> and I'm too lazy to roll my own CD.
>
>
> VLAN'ing your home is probably more than most people want to monkey
> with, but it's pretty cool once it's all set.  The Dell 27(08|16|24)
> PowerConnects are cheap gigabits and don't do badly for a core switch
> for home/SOHO.  Interface is terrible, but, you probably won't touch it
> often.