Multiple gateways in DHCP causing problems.

[mxnerd]

I'm setting up multiple gateways in DHCP and hoping that if one gateway is down, the other will pick it up. However, the client computers getting the DHCP IP and gateways address seems have problem dealing with multiple gateways.

It seems the client computer/browser is picking up gateways in a round-robin style and getting intermittent connection to the internet.

What should be the proper way to set ip up?

gateway 1: IPCop
gateway 2: linksys

IPCop is the first in the list.

 

[Nuwave]

Is this a home setup or a business setup?

 

[mxnerd]

Business - small

 

[drebo]

My recommendation would be to buy a dual-WAN router and set it up that way.

 

[mxnerd]

But customer has only one DSL account.

Internet - DSL Modem (71.x.x.x) - Trendnet wifi AP (192.168.0.1) in bridge mode

where
IPCop LAN - 10.0.0.2 WAN - 192.168.0.2 GW 192.168.0.1
Linksys LAN - 10.0.0.3 WAN - 192.168.0.3 GW 192.168.0.1

10.0.0.x is the LAN network.

I'm not trying to get 2 ISP and create redudant internet. I'm trying to use IPCop as main gateway so I have some more control over user's internet usage experience, but with a backup gateway if the IPCop is down.

But it seems the traffic will choose IPCop at one moment, and then choose linksys next moment.

 

[spidey07]

You can't have two default gateways (well without getting too deep into it, you can't). That's like saying you have two defaults and exhibit what you're seeing, round robin kind of behavior.

What you're looking for is VRRP where each router would "share" the same IP address and only one would be active at a time and fail to another one.

 

[mxnerd]

Originally posted by: spidey07
You can't have two default gateways (well without getting too deep into it, you can't). That's like saying you have two defaults and exhibit what you're seeing, round robin kind of behavior..

So what's the purpose of letting user or DHCP set several gateway anyway on one interface? So that only works if only one of the gateways is alive and all others are dead?

What you're looking for is VRRP where each router would "share" the same IP address and only one would be active at a time and fail to another one.

So in this case I should use software based pfSense or hardware dual-wan, which has failover capability?

 

[spidey07]

There's an RFC on dead gateway detection. Most all stacks don't follow it or at the very least don't follow it properly because that's what VRRP is for. Something with more intelligence (I don't know pfSense) could help.

 

[n0cmonkey]

I think pfSense uses OpenBSD's CARP (a non-patent encumbered VRRP-like protocol), and would be just fine.

 

[spidey07]

Originally posted by: n0cmonkey
I think pfSense uses OpenBSD's CARP (a non-patent encumbered VRRP-like protocol), and would be just fine.

Since when is VRRP not a purely open standard? Haven't kept up much on it but if there are patent disputes, that's wrong.

I know that the xNix have their own method, specific to whatever flavor, and cisco has the original HSRP but VRRP was supposed to solve the interoperability.

 

[n0cmonkey]

Originally posted by: spidey07

Originally posted by: n0cmonkey
I think pfSense uses OpenBSD's CARP (a non-patent encumbered VRRP-like protocol), and would be just fine.

Since when is VRRP not a purely open standard? Haven't kept up much on it but if there are patent disputes, that's wrong.

I know that the xNix have their own method, specific to whatever flavor, and cisco has the original HSRP but VRRP was supposed to solve the interoperability.

The IETF community proposed work in this direction in the late 90's, however in 1997 Cisco informed them that they believed some of Cisco's patents covered the proposed IETF VRRP (Virtual Router Redundancy Protocol); on March 20, 1998 they went further and specifically named their HSRP "Hot Standby Router Protocol" patent. Reputedly, they were upset that IETF had not simply adopted the flawed HSRP protocol as the standard solution for this problem. Despite this legal pressure, the IETF community forged ahead and published VRRP as a standard even though there was a patent in the space. Why? There was much deliberation at all levels of the IETF, and unfortunately for all of us the politicians within eventually decided to allow patented technology in standards -- as long as the patented technology is licensed under RAND (Reasonable And Non Discriminatory) terms.

From here.

Hence the need for the Common Address Redundancy Protocol by OpenBSD. The other BSDs have adopted it (atleast partially) along with the Packet Filter firewall. Between CARP, OpenBGPD, OpenOSPF, relayd, pf, and a host of other advantages I can see not needing the big C on a lot of networks.

(HP seems to be the switch brand of choice for OBSD networkers in the know)

 

[spidey07]

Originally posted by: n0cmonkey

From here.

Hence the need for the Common Address Redundancy Protocol by OpenBSD. The other BSDs have adopted it (atleast partially) along with the Packet Filter firewall. Between CARP, OpenBGPD, OpenOSPF, relayd, pf, and a host of other advantages I can see not needing the big C on a lot of networks.

(HP seems to be the switch brand of choice for OBSD networkers in the know)

*SIGH*
And people wonder why we're so against pre-draft-non-standard 802.11n stuff. This is why. The entire reason for the IETF and IEEE is that things all play nice with eachother no matter what. Otherwise you wind up with this kind of crap.

 

[mxnerd]

Thanks for all the info.

Apparently multiple gateways not only don't work for multiple interfaces, it also won't work on a single interface if not configured properly. Lesson learned.