Multi WAN with same gateway IP intereferes with balancing
-
Having two interfaces with the same gateway is not supported. IF they are both PPPoE it may work by chance on occasion but only if you set custom (different!) monitor IP addresses for both gateway entries.
Hi.
I'm running latest stable 2.1.5-RELEASE (amd64)
built on Mon Aug 25 07:44:45 EDT 2014
FreeBSD 8.3-RELEASE-p16
with two PPPoE with same (dynamicly assigned) gateway. I have put different monitor ip addresses for both gateway entries and both ping. Still if one is connected, the second one will cycle between getting and ip and then dropping in a about 5 sec cycle.
I've even tried setting up static routes for specific /32 monitor ip's for specific interfaces, with no success.When you say may work by chance, are there other parameters that affect this?
After seeing the bug fix below, is there a possibility that this bug fixed in 2.2 exists in 2.15?
https://redmine.pfsense.org/issues/4040Regards
-
I see I am not the only one having this issue when duplicate gaeway is assigned by ISP. I am on latest formal release of PFSense 2.2.2
Anyone know how to implement the -iface option in routing, the one talked about in that bugfix link posted?
Roofus
-
After upgrading to 2.3, the issue now seems to be resolved
Same gateway, two interfaces, No more drops, and traffic load balancing works tooGreat
-
Hi.
I'm running latest stable 2.1.5-RELEASE (amd64)
built on Mon Aug 25 07:44:45 EDT 2014
FreeBSD 8.3-RELEASE-p16
with two PPPoE with same (dynamicly assigned) gateway. I have put different monitor ip addresses for both gateway entries and both ping. Still if one is connected, the second one will cycle between getting and ip and then dropping in a about 5 sec cycle.It seems that this bug has returned in 2.3.2 with a vengeance.
In a 2.3 ALPHA Built 28 Dec 2015 snapshot, it worked like a charm.
in 2.3.2. the problem is described as is , in your quote.Attached log, during the problem
Aug 11 14:15:48 ppp [opt1] IPADDR 87.202.87.162 Aug 11 14:15:48 ppp [opt1] 87.202.87.162 is OK Aug 11 14:15:48 ppp [opt1] IPCP: SendConfigReq #15 Aug 11 14:15:48 ppp [opt1] IPADDR 87.202.87.162 Aug 11 14:15:48 ppp [opt1] IPCP: rec'd Configure Ack #15 (Req-Sent) Aug 11 14:15:48 ppp [opt1] IPADDR 87.202.87.162 Aug 11 14:15:48 ppp [opt1] IPCP: state change Req-Sent --> Ack-Rcvd Aug 11 14:15:48 ppp [opt1] IPCP: rec'd Configure Request #202 (Ack-Rcvd) Aug 11 14:15:48 ppp [opt1] IPADDR 80.106.108.46 Aug 11 14:15:48 ppp [opt1] 80.106.108.46 is OK Aug 11 14:15:48 ppp [opt1] IPCP: SendConfigAck #202 Aug 11 14:15:48 ppp [opt1] IPADDR 80.106.108.46 Aug 11 14:15:48 ppp [opt1] IPCP: state change Ack-Rcvd --> Opened Aug 11 14:15:48 ppp [opt1] IPCP: LayerUp Aug 11 14:15:48 ppp [opt1] 87.202.87.162 -> 80.106.108.46 Aug 11 14:15:48 ppp [opt1] IFACE: Up event Aug 11 14:15:48 ppp [opt1] IFACE: Rename interface ng3 to pppoe1 Aug 11 14:15:48 ppp [opt1] IPV6CP: rec'd Configure Request #4 (Ack-Rcvd) Aug 11 14:15:48 ppp [opt1] IPV6CP: SendConfigAck #4 Aug 11 14:15:48 ppp [opt1] IPV6CP: state change Ack-Rcvd --> Opened Aug 11 14:15:48 ppp [opt1] IPV6CP: LayerUp Aug 11 14:15:48 ppp [opt1] 020c:29ff:fe4b:ed0f -> 0090:1a00:01a3:1a05 Aug 11 14:15:49 ppp [opt1_link0] LCP: rec'd Terminate Request #172 (Opened) Aug 11 14:15:49 ppp [opt1_link0] LCP: state change Opened --> Stopping Aug 11 14:15:49 ppp [opt1_link0] Link: Leave bundle "opt1" Aug 11 14:15:49 ppp [opt1] Bundle: Status update: up 0 links, total bandwidth 9600 bps Aug 11 14:15:49 ppp [opt1] IPCP: Close event Aug 11 14:15:49 ppp [opt1] IPCP: state change Opened --> Closing Aug 11 14:15:49 ppp [opt1] IPCP: SendTerminateReq #16 Aug 11 14:15:49 ppp [opt1] IPCP: LayerDown Aug 11 14:15:49 ppp [opt1] IPV6CP: Close event Aug 11 14:15:49 ppp [opt1] IPV6CP: state change Opened --> Closing Aug 11 14:15:49 ppp [opt1] IPV6CP: SendTerminateReq #8 Aug 11 14:15:49 ppp [opt1] IPV6CP: LayerDown Aug 11 14:15:50 ppp [opt1] IFACE: Down event Aug 11 14:15:50 ppp [opt1] IFACE: Rename interface pppoe1 to pppoe1 Aug 11 14:15:50 ppp [opt1] IPCP: Down event Aug 11 14:15:50 ppp [opt1] IPCP: LayerFinish Aug 11 14:15:50 ppp [opt1] IPCP: state change Closing --> Initial Aug 11 14:15:50 ppp [opt1] IPV6CP: Down event Aug 11 14:15:50 ppp [opt1] IPV6CP: LayerFinish Aug 11 14:15:50 ppp [opt1] Bundle: No NCPs left. Closing links... Aug 11 14:15:50 ppp [opt1] IPV6CP: state change Closing --> Initial Aug 11 14:15:50 ppp [opt1_link0] LCP: SendTerminateAck #8 Aug 11 14:15:50 ppp [opt1_link0] LCP: LayerDown Aug 11 14:15:50 ppp [opt1_link0] PPPoE: connection closed Aug 11 14:15:50 ppp [opt1_link0] Link: DOWN event Aug 11 14:15:50 ppp [opt1_link0] LCP: Down event Aug 11 14:15:50 ppp [opt1_link0] LCP: state change Stopping --> Starting Aug 11 14:15:50 ppp [opt1_link0] Link: reconnection attempt 1 in 3 seconds -
@kpa:
What part of the "Having two interfaces with the same gateway is not supported" you don't understand?
LOL!!!
You do realize that the part you have quoted is from December 2014, and this ("Having two interfaces with the same gateway" i mean) is a working feature of pfSense now.
I also guess you haven't read "In a 2.3 ALPHA Built 28 Dec 2015 snapshot, it worked like a charm."Ok?
Are you ready to apologize for being rude in the first place? -
Anyone having the same issue?
Thanx -
I had the same issue in the past, and the only solution I found was statically routing my modems in different ip range.
-
Sorry for coming back at this one.
As mentioned above it worked very well at the 2.3 ALPHA Built 28 Dec 2015 snapshot.
In 2.3.2 is broken.What files must i compare between between two versions to try and find a solution?
My regards. -
Just wondering about the state of this issue.
I currently have no means to test, but soon this will be changing. :-\ -
I can safely verify that in 2.4.3-RELEASE-p1 (current stable) works as it should
One interface is left with the dynamicly selected monitor peer and the other
pings a stable ip inside the provider (in my case the cluster ip of the main dns stack)
If the provider changes her policy and blocks ping that would be an issue, but I think I can live with that. :)