The reason is, you always need to connect back to the same place. This is ok in TCP, in fact for office solutions where you are using teaming or backup routes via this technology it results in less user visible downtime. The solution does not work so well for UDP based protocols.
The proposed solution below would work if source would bind to 0.0.0.0, or all local ip's, but it doesn't do this. It only has support for one external IP, it still connects to the master browser with 1 public ip, and this is the only one that will be found by the server browser. NAT is the OPPOSITE to the desired solution, providing a many (clients) to one (pulbic ip) to many (internet hosts) routing protocol, when you want one (srcds) to many (listen ip:ports) to many (internet hosts). SRCDS is capable through it's connection system to provide a publicly accessible UDP listen port on many NAT devices without special setup, BUT this is still a one to one to many solution, not what you are looking for. If you just want to use LAN bandwidth for lan clients and internet bandwidth for internet clients, then use a port forward to the internet ip/port from the lan ip/port. If you want more bandwidth by ordering extra pipe's then speak to your ISP about the issue, as they can provide you with a solution, by proper upstream routing. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of K1ll3rD > Sent: 10 November 2005 11:38 > To: hlds_linux@list.valvesoftware.com > Subject: Re: [hlds_linux] Re: srcds with multiple ip address > > Multiple Internet providers is supported by the kernel, have > a look at: > > http://lartc.org/howto/lartc.rpdb.multiple-links.html > > > Replying packets will use the same NIC as the packet came in > from for it's gateway. > > I have to test once again binding this to 0.0.0.0 but time > has been the problem lately. I though i did and it gave me > problems, as soon as you start using NAT with IP rule, it get > complicated. > > Thanks > > K > > > ----- Original Message ----- > From: "James Tucker" <[EMAIL PROTECTED]> > To: <hlds_linux@list.valvesoftware.com> > Sent: Thursday, November 10, 2005 4:21 AM > Subject: RE: [hlds_linux] Re: srcds with multiple ip address > > > > Lol. OSPF does not do that. OSPF is an IP routing protocol, that > > routes correctly between gateways by opening the > > (lookahead) shortest route to destination first. THIS DOES > NOT SUPPORT > > TEAMING OR BONDED NIC'S! > > > > The solution is simple - add a port forwarding rule to the > NIC's not > > set to listen by SRCDS. Forward to the IP of the NIC that is. The > > traffic will never leave the kernel after coming in, so you > would get > > your desired effect. This WILL NOT show up with anything but the > > public IP in the steam browser. N.B. > > this is NO DIFFERENT from just using a second NIC as a > routing gateway > > to the servers IP. In other words, if your on a lan, the server is > > connected to the net, and your server has 2 nic's, one lan, one > > internet, then connecting to the server will only use the LAN nic > > anyway, as the final routing portion is done inside the kernel. > > > > There is however absolutely no good reason to do this as > far as I can see. > > The ideal solution is somehting like compaq's teaming > nic's. You can > > also do this undex many modern *nixes provided your upstream switch > > supports it. > > > > Technologies NOT involved in this: BGP, OSPF, RIP, or any other IP > > routing protocol extension. > > > > You cannot solve this problem in IP. IP does not do this. > Unless the > > server can manage multiple IP's you will always end up using the IP > > endpoint set by +ip. You can try port forwards and other similar > > tricks, but this will be unreliable in many setups. This problem is > > the sort that should be solved on the MAC layer, however, I still > > don't see the point. > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Dan > >> Sorenson > >> Sent: 09 November 2005 21:07 > >> To: hlds_linux@list.valvesoftware.com > >> Subject: [hlds_linux] Re: srcds with multiple ip address > >> > >> One thought on this, how will the box choose the proper > route back to > >> the client if the srcds server is bound to multiple IP's? > You'd need > >> something that forces it to answer a packet addressed to > IP 1.2.3.4 > >> from interface ip 1.2.3.4 and use the > >> 1.2.3.1 router as the default gateway. Otherwise, what > would prevent > >> the server from receiving a packet on 1.2.3.4, sending a > reply back > >> on 5.6.7.8, and the client happily ignoring it? Or worse, > sourcing a > >> packet on 1.2.3.4, choosing 5.6.7.1 as the appropriate > gateway, which > >> isn't on the same network, and dropping the packet as > undeliverable? > >> > >> There may be a way to do it, but I'm thinking a router > running OSPF > >> or BGP if you can is the way to go. > >> > >> - Dan > >> > >> * Dan Sorenson DoD #1066 A.H.M.C. #35 > [EMAIL PROTECTED] * > >> * Vikings? There ain't no vikings here. Just us honest > farmers. * > >> * The town was burning, the villagers were dead. They > didn't need * > >> * those sheep anyway. That's our story and we're sticking > to it. * > >> > >> > >> _______________________________________________ > >> To unsubscribe, edit your list preferences, or view the list > >> archives, please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > > > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the > list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
