|
On Tue, Sep 19, 2000 at 09:13:16AM -0700, Michael McConnell wrote:
> Ok, I'm faced with a difficult task. I've never seen a piece of hardware
> that can provide a solution like, nor do I believe I could afford a piece
> of hardware solution to do this, so where do I turn, Linux (-:
>
> We have many employee's that travel a great deal, they visit many remote
> locations in Asian, and Eastern Europe. I've found the the number of hops
> from Asia and Eastern Europe is quite rediculusly high. In order to save
> costs we'd like to start using Video Conferencing from these locations.
> Now this is unforchunately very difficult as the number of hops back to
> North America is so high. The best solution seems to be to create a
> Forwarding Router. The idea is that, I'd place a *forwarding router* at a
> fast colo in asia (PSI Net for example). PSI net has services in Asia
> connected to many asian networks, with a private network back to North
> america (3 hops).
>
> So if I placed a box in Asia with PSI net that were to accept connections
> as though it were the end point, but instead it would forward all packets
> via PSI Net's private network back to North America, there by cutting the
> number of hops in half, and greatly incressing the connection rate back
> to north america.
>
> The ways I've figure out how to implement this are:
>
> Accept Connection on Eth0 Modify Client IP and Destination IP of the
> packets, Send packets with Modified CIP and DIP's to North America ( CIP
> = FORWARDING GATEWAY, DIP = NORTH AMERICA CONNECTION) The end in North
> America would then reply back, the Forwarding Gateway would then modify
> the CIP and DIP to = the real client and boom
>
> I've also considered using GRE tunneling, though this solution means 2x
> the hardware (box in asia, box in north america) And alot of video
> conferencing data is UDP in nature, so this would probably slow things
> down a bit.
>
> I believe that I'd probably have to use the 2.4 Kernel series for the
> advanced package management seen with IPTables. But I'm not quite sure
> were to start.. (p.s. because it's video conference, it can NOT be PORT
> specific, it has to be Packet forwarding, not socket)
>
> Any ideas would be greatly appreciated.
Hi,
From what I understand of your email you essentially want to be able
to drop a box somewhere and use that as a hop for your traffic,
presumably because the box is a shortcut of sorts. You would
appear to have two options.
1. Construct a user-space proxy server.
This has the advantage that all the intelligence is held in the proxy
server. Clients just connect to the proxy as if it were any other
server, the proxy sets up a connection to the "real" server and off you
go. As the proxy server has access to all information in the packets it
may choose to associate real servers with clients on, for instance, a
per-username basis. I'm not sure if this is desirable.
UDP makes this a little more interesting but by all means possible.
2. Treat this as purely a routing problem.
Establish a tunnel from the client to the dropped-somewhere-box. Clients
send traffic to your box via the tunnel, the box forward traffic to the
real server and off you go. The difficulty would be in ensuring that
return traffic from the real server goes by the drop-in box, presumably
by another tunnel.
Thinking of this in terms of a routing problem raises some interesting
questions. Essentially you are starting to setup your own network. This
assumes that you have a better idea of the fastest way to get somewhere
than the provider you are hooking into. An interesting assumption
indeed.
I would suggest one option would be to find a provider that can offer
better access. Lets face it you're still planning on sending traffic over
the networks that are causing you the problem. Just a thought.
--
Horms
|
