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: [email protected] > 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
