Hi,
Has anyone ever made a config with UMTS using for upload and a satellite link for download.
rgds
in short: you can’t do this (easily)
assuming your sat link is one-way. assuming your device is a client, not a server, e.g. requests started from there, and it does not server external requests.
or, more elaborated: as you download something, there’s always a request going out, and it’s mostly using tcp.
so the 3way handshake will take place between the src addr and dat address, and the reply will come in the same session.
e.g. if you send your HTTP GET on the 3g, the src address will be the one of the 3g, so all the download will arrive through the 3g.
even if you do some sort of level4+ logic for load balancing, the tcp sessions would be build out as the logic could recognise the command, whether it’s GET or POST, or RETR or STOR (in case of FTP) and you can’t change the addresses of tcp session at this (any) time.
and as if IP packets are routed normally based on the dst address, your default will point to the pop session on the 3g stick, and you probably will have a firewall nat rule to do masquerading.
even if you’d set src-nat action to the ip address of the satellite link, the mobile provider would surely discard the packet as it would be considered as ip spoofing, and urpf or a firewall in the transport path would drop it.
(if you have a public IP on the 3G, and the provider doesn’t use urpf or filtering, it would work. it’s asymmetric routing, but it would work)
there is however one thing you can (theoretically) do:
hook up a tunnel from the 3g side to the sat providers network, and use src-nat to the satellite link’s address.
set a /32 route for the tunnel terminator’s ip in the routing table towards the 3g stick.
set a default route towards the tunnel.
then each request (upload or download) will go to through the tunnel (if it’s established) to the internet,
but as the src address of the packets will be the ip address of your satellite link, all the replies (e.g. download) will
arrive to the satellite link.
this also requires your satellite provider to
- provide this tunnel aggregator service to you
- accept ip packets from the tunnel which are not related to the tunnel
hth,
Hi,
Thanks for your reply.
Actually we have a two-way satellite connection but I want to reduce the latency to 350ms ore so.
Do you have a config example?
If it is importartant to achieve this you could also use an independent aggregation point. It might be around 20-25 EUR / month for say 2000 Gb.
I think is impossible to reduce the latency to 350 ms. Is Einstein… not hardware…
The sat is about 40.000 km above.
When you request www.abcdefgi.com and press ENTER… the request ravel from you “home” to the Sat (40.000), dowm from the SAT to the Sat-NOC (40.000, now 160000 km traveled), do anything in the earth… some ms more, it doesn´t matter), return the data to the NOC, up to sat sat (40000 km more, now 200000 km traveled), and come from the sat to your home (40.000 km more… 240000 km traveled in space)…
Is the light is at 300.000 km/seg… and you are doing at least 240.000.. You have about 600 ms in travel time, and you can´t go faster than light…