Network troubleshooting conundrum - next steps?
Discussion
Bit of a carry over from the 4G thread, but I have a network situation that is currently doing my head in so thought I would ask on here for suggestions 
My objective is this:
The USG covers routing and DHCP on the network.
The two internet connections are in failover mode on the USG with the ADSL2+ acting as the failover (assuming I can get a stable and fast 4G connection I'll probably ditch this later).
I tested a couple of 1mth sims in the Huawei (stood on its own) from 3 and EE to see what speeds I could get and was happy...so arranged everything per the diagram.
With the 3 sim in the Huawei it all works as expected. I can connect to my network wired or wirelessly from any device and connectivity to the internet is there. I can also connect directly to the Huawei if needed and do the same (not something I intend to do for anything other than troubleshooting).
On EE I'm having trouble though. Which is a massive bummer as the speeds are significantly faster on it.
With the EE sim in the Huawei, the USG obtains an IP address from the Huawei. And the mgmt web page shows the connection on the network is good, as should be the connection between router and network. So all looks good. But there is no internet connectivity from the Unifi network side.
If I connect directly to the Huawei I do get internet connectivity. The devices connected this way get IP addresses the same way as the USG and in the same range etc. So the EE sim is working fine in the router (I think - I do have one glitch on my Windows machine - it will connect to the internet through the wired LAN port but not the Huawei's wifi. I'm assuming at the moment this is something to do with my Windows machine as another laptop I have, a Mac, will connect with both wifi and wired connections direct to the Huawei and get internet connectivity).
As a test, with a degree of faffing about I removed the USG from the mix (removed it from the controller) and connected the Huawei directly to the Unifi network and had it act as the router and DHCP server (controlling the same range as the USG did). This worked for most of the devices on the network, but some it would just not allow to connect to the network at all. Which is obviously not ideal (most devices it was seeing as wired connections...though there were only something like 60 on there max at any one time).
In each of the different configs I've factory reset each of the main devices (USG and Huawei - the ADSL router is actually working stably at the moment. Which is ironic as it was issues with my ADSL link that prompted the 4G exploration!) and configured them fresh after trying them without doing that first.
The ideal objective is to get the network per the diagram with an EE sim (which gives 70-80Mbps download and 10Mbps).
From the messing about I've done thus far I'm basically at the point where nothing is the problem And am failing to see the wood for the trees I think:
The easiest solution would be to ditch EE and just run the 3 sim. But that's defeatist It also doesn't give as marked a speed boost over ADSL as the EE one.
It looks like it might be a routing problem between the 10.0.1.x and 192.168.8.x interfaces on the USG. But why only for the EE sim? Or the IP address of the USG is being blocked from accessing the 4G network by the router? (Firewalls etc are all off on both devices).
Does anyone have any ideas?
My objective is this:
The USG covers routing and DHCP on the network.
The two internet connections are in failover mode on the USG with the ADSL2+ acting as the failover (assuming I can get a stable and fast 4G connection I'll probably ditch this later).
I tested a couple of 1mth sims in the Huawei (stood on its own) from 3 and EE to see what speeds I could get and was happy...so arranged everything per the diagram.
With the 3 sim in the Huawei it all works as expected. I can connect to my network wired or wirelessly from any device and connectivity to the internet is there. I can also connect directly to the Huawei if needed and do the same (not something I intend to do for anything other than troubleshooting).
On EE I'm having trouble though. Which is a massive bummer as the speeds are significantly faster on it.
With the EE sim in the Huawei, the USG obtains an IP address from the Huawei. And the mgmt web page shows the connection on the network is good, as should be the connection between router and network. So all looks good. But there is no internet connectivity from the Unifi network side.
If I connect directly to the Huawei I do get internet connectivity. The devices connected this way get IP addresses the same way as the USG and in the same range etc. So the EE sim is working fine in the router (I think - I do have one glitch on my Windows machine - it will connect to the internet through the wired LAN port but not the Huawei's wifi. I'm assuming at the moment this is something to do with my Windows machine as another laptop I have, a Mac, will connect with both wifi and wired connections direct to the Huawei and get internet connectivity).
As a test, with a degree of faffing about I removed the USG from the mix (removed it from the controller) and connected the Huawei directly to the Unifi network and had it act as the router and DHCP server (controlling the same range as the USG did). This worked for most of the devices on the network, but some it would just not allow to connect to the network at all. Which is obviously not ideal (most devices it was seeing as wired connections...though there were only something like 60 on there max at any one time).
In each of the different configs I've factory reset each of the main devices (USG and Huawei - the ADSL router is actually working stably at the moment. Which is ironic as it was issues with my ADSL link that prompted the 4G exploration!) and configured them fresh after trying them without doing that first.
The ideal objective is to get the network per the diagram with an EE sim (which gives 70-80Mbps download and 10Mbps).
From the messing about I've done thus far I'm basically at the point where nothing is the problem
And am failing to see the wood for the trees I think:- The overall design can be proved to be fine (with a 3 sim in, everything works. Albeit at 25% of the download and 70% of the upload speeds)
- The EE sim will allow internet connectivity in the router, and to multiple devices simultaneously. So in theory the EE sim is fine (I've been on to EE twice today - who were great)
- The USG appears to be doing its job OK. Fails over properly (and quickly)
The easiest solution would be to ditch EE and just run the 3 sim. But that's defeatist
It also doesn't give as marked a speed boost over ADSL as the EE one.It looks like it might be a routing problem between the 10.0.1.x and 192.168.8.x interfaces on the USG. But why only for the EE sim? Or the IP address of the USG is being blocked from accessing the 4G network by the router? (Firewalls etc are all off on both devices).
Does anyone have any ideas?
Edited by Murph7355 on Sunday 24th January 01:19
xeny said:
Have you done traceroutes with the USG present and not present while using the EE SIM? That might at least tell you how far you're getting, and confirm if it is EE's infrastructure not liking the config or something else going on.
No - but was thinking along these lines last night. Just need to figure out how. Will post back when I find out.Thanks
Thanks guys.
Some half interesting tracert stuff:
This is on 3 at the moment. The "user experience" is good in this mode (20-30Mbps download, 5-7 upload at the moment).
C:\WINDOWS\system32> tracert 8.8.8.8
Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 2 ms 2 ms 2 ms Gateway [10.0.1.1]
2 2 ms 2 ms 2 ms 192.168.8.1 <<so it's traversing the gateway interfaces quickly>>
3 * * * Request timed out.
4 86 ms 56 ms 56 ms 172.21.37.69 <<not sure what this is as whatsmyip says I'm in the 94.41.208.xxx range as my public IP>>
5 * * * Request timed out.
6 60 ms * 75 ms 172.21.89.98
7 64 ms 58 ms 57 ms 172.21.89.81
8 * * * Request timed out.
9 63 ms 57 ms 58 ms 172.21.106.150
10 56 ms 58 ms 58 ms 185.153.237.155
11 67 ms 57 ms 58 ms 216.239.48.217
12 60 ms 58 ms 57 ms 172.253.71.191
13 65 ms 63 ms 60 ms dns.google [8.8.8.8] <<so that succeeds, albeit taking nearly half a second? NB I'm experiencing no discernible lag that I've noticed>>
I then tried the following which timed out. Which I thought odd as I can access PH OK
C:\WINDOWS\system32> tracert www.pistonheads.com
Tracing route to www.pistonheads.com [13.224.227.32]
over a maximum of 30 hops:
1 2 ms 1 ms 1 ms BoydellsGateway [10.0.1.1]
2 2 ms 1 ms 2 ms 192.168.8.1
3 * * * Request timed out.
4 72 ms 69 ms 62 ms 172.21.37.65
5 * * * Request timed out.
6 * * * Request timed out.
7 57 ms 60 ms 55 ms 172.21.89.81
8 * * * Request timed out.
9 61 ms 79 ms 57 ms 172.21.106.154
10 59 ms 58 ms 57 ms 185.153.238.162
11 62 ms 58 ms 65 ms 185.153.238.163
12 61 ms 63 ms 54 ms 52.94.34.31
13 59 ms 60 ms 53 ms 54.239.101.67
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 56 ms 57 ms 58 ms 150.222.65.99
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Will play with a few more routes and then switch to EE.
I'm assuming the 172.21.xxx.xxx are likely to be 3 servers of some sort as the ISP?
Some half interesting tracert stuff:
This is on 3 at the moment. The "user experience" is good in this mode (20-30Mbps download, 5-7 upload at the moment).
C:\WINDOWS\system32> tracert 8.8.8.8
Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 2 ms 2 ms 2 ms Gateway [10.0.1.1]
2 2 ms 2 ms 2 ms 192.168.8.1 <<so it's traversing the gateway interfaces quickly>>
3 * * * Request timed out.
4 86 ms 56 ms 56 ms 172.21.37.69 <<not sure what this is as whatsmyip says I'm in the 94.41.208.xxx range as my public IP>>
5 * * * Request timed out.
6 60 ms * 75 ms 172.21.89.98
7 64 ms 58 ms 57 ms 172.21.89.81
8 * * * Request timed out.
9 63 ms 57 ms 58 ms 172.21.106.150
10 56 ms 58 ms 58 ms 185.153.237.155
11 67 ms 57 ms 58 ms 216.239.48.217
12 60 ms 58 ms 57 ms 172.253.71.191
13 65 ms 63 ms 60 ms dns.google [8.8.8.8] <<so that succeeds, albeit taking nearly half a second? NB I'm experiencing no discernible lag that I've noticed>>
I then tried the following which timed out. Which I thought odd as I can access PH OK
C:\WINDOWS\system32> tracert www.pistonheads.com
Tracing route to www.pistonheads.com [13.224.227.32]
over a maximum of 30 hops:
1 2 ms 1 ms 1 ms BoydellsGateway [10.0.1.1]
2 2 ms 1 ms 2 ms 192.168.8.1
3 * * * Request timed out.
4 72 ms 69 ms 62 ms 172.21.37.65
5 * * * Request timed out.
6 * * * Request timed out.
7 57 ms 60 ms 55 ms 172.21.89.81
8 * * * Request timed out.
9 61 ms 79 ms 57 ms 172.21.106.154
10 59 ms 58 ms 57 ms 185.153.238.162
11 62 ms 58 ms 65 ms 185.153.238.163
12 61 ms 63 ms 54 ms 52.94.34.31
13 59 ms 60 ms 53 ms 54.239.101.67
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 56 ms 57 ms 58 ms 150.222.65.99
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Will play with a few more routes and then switch to EE.
I'm assuming the 172.21.xxx.xxx are likely to be 3 servers of some sort as the ISP?
Am only a hop away from the USG. So the 10.0.1.1 is me hitting the USG. Then the 192.168.8.1 is the data hitting the router from the USG. (Will look up how to do the same from the USG, but suspect it will be similar only a smidge quicker).
From a bit of searching the 172... addresses are IANA addresses. And the 185... address in the first trace is 3's addressable range.
So I think this is noting the data gets to the gateway, is passed to the router and then goes out to the internet to start its pathfinding (and in the first trace completes that journey).
Will do the same thing with an EE sim in. If it's them blocking it I guess I'll see something hitting them and then failing every time. If it's the router I suspect it will never escape from 192.168.8.1.
Will also do the same connecting directly to the router.
From a bit of searching the 172... addresses are IANA addresses. And the 185... address in the first trace is 3's addressable range.
So I think this is noting the data gets to the gateway, is passed to the router and then goes out to the internet to start its pathfinding (and in the first trace completes that journey).
Will do the same thing with an EE sim in. If it's them blocking it I guess I'll see something hitting them and then failing every time. If it's the router I suspect it will never escape from 192.168.8.1.
Will also do the same connecting directly to the router.
b
hstewie said:
hstewie said: I'd do from the USG it just to rule out any weirdness in how the USG is handling things that sit behind it.
Agree.Am also going to run a few direct from the router.
(OH is having to work a bit today so will wait on those before buggering about with things - much as I'm confident the failover on the USG works
).thebraketester said:
It it work running past the Unifi helpdesk?
Possibly - was also going to pass it by the place I bought the USG from (and have popped a post up on the Huawei site - though they probably already knew I would ).Will run a few traceroutes to see if it shows anything up and then broaden the support net. (My OH keeps telling me just to leave the 3 sim in
).Put the EE sim in.
First go gave me traceroutes through the failover connection (JL Broadband)...the USG doing its job there.
Disconnecting the JL Broadband connection just resulted in the traceroutes timing out. Didn't even give the 4G routers address as a hop.
Tried it from the USG directly with the same results.
Connected my OH's laptop up directly to the 4G router and that gave the following:
traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 homerouter.cpe (192.168.8.1) 2.565 ms !N 1.426 ms !N *
(It's a Mac, so not sure if it can give anything more verbose, but that's all the trace gave. Internet connectivity works fine though.)
So tried my laptop (Win10). The tracert command on that is timing out despite internet connectivity. Interestingly searching whats my ip on Google returns 2a01:4c8:1061:1feb:98e:469c:27a:53ad (!). It also does on my OH's Mac.
Is this an IPv6 IP address? The 3 sim gave an IPv4 IP address, so am wondering if this is something to do with the problem.
The router seems to be OK handling it as when I connect directly I get internet access. But something seems to be going amiss when the USG is connected - which is a bit odd as I would have thought it would talk to the router via the IPv4 address it's given, letting the router go from its IPv4 range to IPv6?
More Googling required.
First go gave me traceroutes through the failover connection (JL Broadband)...the USG doing its job there.
Disconnecting the JL Broadband connection just resulted in the traceroutes timing out. Didn't even give the 4G routers address as a hop.
Tried it from the USG directly with the same results.
Connected my OH's laptop up directly to the 4G router and that gave the following:
traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 homerouter.cpe (192.168.8.1) 2.565 ms !N 1.426 ms !N *
(It's a Mac, so not sure if it can give anything more verbose, but that's all the trace gave. Internet connectivity works fine though.)
So tried my laptop (Win10). The tracert command on that is timing out despite internet connectivity. Interestingly searching whats my ip on Google returns 2a01:4c8:1061:1feb:98e:469c:27a:53ad (!). It also does on my OH's Mac.
Is this an IPv6 IP address? The 3 sim gave an IPv4 IP address, so am wondering if this is something to do with the problem.
The router seems to be OK handling it as when I connect directly I get internet access. But something seems to be going amiss when the USG is connected - which is a bit odd as I would have thought it would talk to the router via the IPv4 address it's given, letting the router go from its IPv4 range to IPv6?
More Googling required.
outnumbered said:
That is an IPv6 address, but it's more likely you're getting dual stack (IPv4 and IPv6) rather than IPv6 only. IPv6 connectivity is typically preferred if it's present, which is why you see that at whatsmyip.
It wasn't initially getting an IPv4 address but the guys at EE gave me an alternate APN to try and it gave one. Unfortunately the situation remains the same as, I suspect, the IPv6 one is being preferred as you note.The 3 sim I have does not give any IPv6 address at all.
Nor does the JL Broadband ADSL.
So I'm pretty sure this is where the trouble is
I'm not at all familiar with IPv6 addressing or routing, so am starting from a low bar on that front. I'm wondering if there's something I can change on my LAN side network to make it understand IPv6? Though would have thought the Huawei router would handle that translation??
bhstewie said:
hstewie said: Can you get a ten quid SIM from some other network?
Feels like something fky by the carrier.
My 3 sim works fine as above...would like to get the EE one working ideally as it has 4x better download (moot if I can't get the bugger to work I know!) and costs about the same with the discounts I get.Feels like something f
ky by the carrier.There is also the "don't want to be defeated by a white plastic box syndrome"
Bikerjon said:
What model 4G router is it? Some have a WAN 2 connection that you can hook up a DSL modem to and then have the 4G router do the failover? I realise this removes the USG from the equation, but it also makes a simpler setup while still allowing failover.
It's a Huawei B818.I did take the USG out of the equation. The problem I then had is that not all devices were registering correctly with the B818 as a router. I'm not exactly sure why, but that was causing bigger issues at home than the slower internet connection. So I switched it back.
I suspect it may have been something to do with all devices on the network already having IP addresses/lease times and a new DHCP server coming in to handle things.
I may give this another go this weekend (during the week is not the best time to potentially take everything down
). Not wedded to the USG, but it seemed like a decent solution to what I needed to do.All input appreciated.
theboss said:
I run a similar setup through a USG with a pair of consumer routers on each WAN port in turn routing to a fixed wireless provider on one and Voda LTE on the other. The USG acquires DHCP leases on both WAN interfaces so there is double NAT taking place on the wireless link and triple (taking CGNAT into account) on LTE.
I haven’t had any major problems but found this configuration more stable than when I either terminated the Wireless PPPoE connection on the USG or set the LTE router to bridge/pass through mode.
Are you sure the EE SIM is intended to support tethering / multiple devices?
So it sounds like your set up is the same as mine.I haven’t had any major problems but found this configuration more stable than when I either terminated the Wireless PPPoE connection on the USG or set the LTE router to bridge/pass through mode.
Are you sure the EE SIM is intended to support tethering / multiple devices?
Does your Voda sim give you an IPv6 address as it's main addres?
The EE sim can be used for tethering/multiple devices (the only constraint is a1Tb/mth fair usage "limit"). It actually works if I take the USG out of the equation and plug the 4G router straight into the network. When I tried that config, however, a number of devices wouldn't connect to the network at all (which I have a feeling was down to some sort of DHCP conflicts).
I probably need to check that config again this weekend (the connections are in heavy use during the week which limits the buggering about I can do) to make sure I wasn't imagining it. And then possibly see if I can make the general network DHCP/routing piece work for me on the Huawei and ditch the USG.
theboss said:
...
How have you configured the USG WAN interface connecting to the Huawei? I would disable IPv6 entirely and try configuring a static IP if you've been trying with DHCP assigned, or vice versa.
It should be possible to get this to work and there's value in having the USG doing the dual WAN routing if you're invested in the wider Unifi stack.
Originally via DHCP. How have you configured the USG WAN interface connecting to the Huawei? I would disable IPv6 entirely and try configuring a static IP if you've been trying with DHCP assigned, or vice versa.
It should be possible to get this to work and there's value in having the USG doing the dual WAN routing if you're invested in the wider Unifi stack.
Thought the same as you so gave it a static in the right reserved range. No dice still. Also bound the IP to the gateways WAN MAC. No dice.
I am invested in the Unifi stac (PoE switch, APs etc)...which is part of the reason I'm keen to get this to work.
The supplier of the USG are looking into it too - unfortunately we're all on the "it should work" path at the moment.
The USG did throw a wobbler not long after first install (without the EE WAN interface on it) whereby it disconnected, then endlessly cycled through restarting and disconnected. No idea what caused it. I've asked the vendor if they think it may have a fault.
The USG evidently isn't happy with the IP traffic coming from the router with the EE sim in. Hopefully it won't come down to ditching EE or the USG, but that's feeling like the option that might present itself.
theboss said:
Sorry only just went through the traceroute and what you said about not showing the LTE router hop on the EE SIM is very telling.
it sounds to me like the USG is downing the LTE path. When you enable a second WAN it ascertains path availability using pings to the host you configure for latency monitoring, by default this is ping.ubnt.com (or similar) but you can set it to your choosing.
With the EE SIM in the router, can you SSH into the USG and run the following commands:
show load-balance status
show load-balance watchdog
This is what I get when both of mine are up - you are looking for an UNREACHABLE which indicates that the USG has administratively disabled the link and thus removed it from its routing table.
eth0
status: Running
pings: 999
fails: 5
run fails: 0/3
route drops: 1
ping gateway: 1.0.0.1 - REACHABLE
last route drop : Mon Jan 25 15:26:12 2021
last route recover: Mon Jan 25 15:29:07 2021
eth2
status: Running
pings: 10268
fails: 23
run fails: 0/3
route drops: 0
ping gateway: 1.0.0.1 - REACHABLE
With the 3 sim in:it sounds to me like the USG is downing the LTE path. When you enable a second WAN it ascertains path availability using pings to the host you configure for latency monitoring, by default this is ping.ubnt.com (or similar) but you can set it to your choosing.
With the EE SIM in the router, can you SSH into the USG and run the following commands:
show load-balance status
show load-balance watchdog
This is what I get when both of mine are up - you are looking for an UNREACHABLE which indicates that the USG has administratively disabled the link and thus removed it from its routing table.
eth0
status: Running
pings: 999
fails: 5
run fails: 0/3
route drops: 1
ping gateway: 1.0.0.1 - REACHABLE
last route drop : Mon Jan 25 15:26:12 2021
last route recover: Mon Jan 25 15:29:07 2021
eth2
status: Running
pings: 10268
fails: 23
run fails: 0/3
route drops: 0
ping gateway: 1.0.0.1 - REACHABLE
eth0
status: Running
pings: 2703
fails: 14
run fails: 0/3
route drops: 17
ping gateway: ping.ubnt.com - REACHABLE
last route drop : Mon Jan 25 14:19:18 2021
last route recover: Mon Jan 25 14:19:42 2021
eth2
status: Running
failover-only mode
pings: 7051
fails: 3
run fails: 0/3
route drops: 4
ping gateway: ping.ubnt.com - REACHABLE
last route drop : Mon Jan 25 02:09:59 2021
last route recover: Mon Jan 25 02:10:40 2021
With the EE sim in:
eth0
status: Waiting on recovery (0/3)
pings: 2718
fails: 17
run fails: 5/3
route drops: 18
ping gateway: ping.ubnt.com - DOWN
last route drop : Mon Jan 25 21:57:27 2021
last route recover: Mon Jan 25 14:19:42 2021
eth2
status: Running
failover-only mode
pings: 7243
fails: 4
run fails: 0/3
route drops: 4
ping gateway: ping.ubnt.com - REACHABLE
last route drop : Mon Jan 25 02:09:59 2021
last route recover: Mon Jan 25 02:10:40 2021
and
interface : eth0
carrier : up
status : inactive
gateway : 192.168.8.1
route table : 201
weight : 0%
flows
WAN Out : 142000
WAN In : 49
Local Out : 378
interface : eth2
carrier : up
status : active
gateway : 192.168.1.1
route table : 202
weight : 100%
flows
WAN Out : 33949
WAN In : 0
Local Out : 118
theboss said:
Looks like pings to ubiquiti’s host are failing intermittently over EE which is causing the route availability to flap up and down
I have had exactly the same with my WISP (not voda)
I would confirm this by plugging a laptop into the EE modem and setting a continual ping against ping.ubnt.com, observing the response which we predict will fail frequently.
You’d then want to know if this is down to actual packet loss on a particular route to Ubiquiti’s server or whether EE are just dropping ICMP for anything. So try some others e.g. 8.8.8.8 for google DNS
You are looking to find a host you can reliably ping on this connection as that’s what the USG needs to do in order to monitor each link.
Ahhhh. So the link could well actually be working, but because the USG works this out by using ping responses, if the ping responses fail then it drops the link and cuts to failover?I have had exactly the same with my WISP (not voda)
I would confirm this by plugging a laptop into the EE modem and setting a continual ping against ping.ubnt.com, observing the response which we predict will fail frequently.
You’d then want to know if this is down to actual packet loss on a particular route to Ubiquiti’s server or whether EE are just dropping ICMP for anything. So try some others e.g. 8.8.8.8 for google DNS
You are looking to find a host you can reliably ping on this connection as that’s what the USG needs to do in order to monitor each link.
Presumably if the failover link isn't there it still doesn't bother routing the traffic?
theboss said:
Yes, the link can be online and passing traffic, but if the USG's route monitor fails because pings are getting dropped above a certain threshold then the link will be deemed unusable by USG and dropped from outbound routing.
That's why you aren't seeing 192.168.8.1 appear as your next hop on the traceroute, and its that reflected in the info you posted - eth0 (WAN1) is shown to be inactive from a routing perspective because a certain number of pings to ping.ubnt.com had been dropped.
You can change the settings on the USG i.e. designate a different host to ping, as well as the interval and pass/fail thresholds. This stuff isn't exposed in the GUI though meaning you have to do so via SSH and then place the settings into a config json stored on the controller and delivered to the USG every time it gets provisioned, otherwise you revert to the GUI settings on restart.
I don't know exactly what it does when WAN2 is unplugged, but I have a feeling this route monitoring behaviour is always active when you have a WAN2 / second internet connection defined.
Try removing the Internet connection for your VDSL in the Unifi GUI altogether which should revert to the config to a fixed interface without the load-balancing and route monitoring aspects. Then try pinging some hosts which you could monitor, from the USG itself in a SSH session. You want to establish a continuous ping which rarely fails.
I found the default ping.ubnt.com wasn't very good and I was having the same problem you are, and found advice from others online suggesting than monitoring an IP rather than a FQDN worked better, by taking name resolution out of the equation. I have alternated between several of the public DNS providers which reply to pings - you can see in the config I posted above I was using 1.0.0.1 as my route monitor, which is Cloudflare's secondary anycast IP.
Try this config to change the IP monitored and also relax the thresholds slightly. Reboot the USG to reinstate the original config.
configure
set load-balance group wan_failover interface eth0 route-test type ping target 1.0.0.1 [or whatever IP you choose]
set load-balance group wan_failover interface eth0 route-test initial-delay 10
set load-balance group wan_failover interface eth0 route-test interval 10
set load-balance group wan_failover interface eth0 route-test count success 2
set load-balance group wan_failover interface eth0 route-test count failure 4
save;commit;exit
Struck out again unfortunately:That's why you aren't seeing 192.168.8.1 appear as your next hop on the traceroute, and its that reflected in the info you posted - eth0 (WAN1) is shown to be inactive from a routing perspective because a certain number of pings to ping.ubnt.com had been dropped.
You can change the settings on the USG i.e. designate a different host to ping, as well as the interval and pass/fail thresholds. This stuff isn't exposed in the GUI though meaning you have to do so via SSH and then place the settings into a config json stored on the controller and delivered to the USG every time it gets provisioned, otherwise you revert to the GUI settings on restart.
I don't know exactly what it does when WAN2 is unplugged, but I have a feeling this route monitoring behaviour is always active when you have a WAN2 / second internet connection defined.
Try removing the Internet connection for your VDSL in the Unifi GUI altogether which should revert to the config to a fixed interface without the load-balancing and route monitoring aspects. Then try pinging some hosts which you could monitor, from the USG itself in a SSH session. You want to establish a continuous ping which rarely fails.
I found the default ping.ubnt.com wasn't very good and I was having the same problem you are, and found advice from others online suggesting than monitoring an IP rather than a FQDN worked better, by taking name resolution out of the equation. I have alternated between several of the public DNS providers which reply to pings - you can see in the config I posted above I was using 1.0.0.1 as my route monitor, which is Cloudflare's secondary anycast IP.
Try this config to change the IP monitored and also relax the thresholds slightly. Reboot the USG to reinstate the original config.
configure
set load-balance group wan_failover interface eth0 route-test type ping target 1.0.0.1 [or whatever IP you choose]
set load-balance group wan_failover interface eth0 route-test initial-delay 10
set load-balance group wan_failover interface eth0 route-test interval 10
set load-balance group wan_failover interface eth0 route-test count success 2
set load-balance group wan_failover interface eth0 route-test count failure 4
save;commit;exit
eth0
status: Running
pings: 7
fails: 7
run fails: 7/10
route drops: 0
ping gateway: 1.0.0.1 - REACHABLE
I'm not entirely convinced "reachable" actually means reachable....it just counted up through the tried until it hit the tenth and downed the connection.
eth0
status: Waiting on recovery (0/2)
pings: 10
fails: 10
run fails: 10/10
route drops: 1
ping gateway: 1.0.0.1 - DOWN
last route drop : Tue Jan 26 22:23:31 2021
At which point the failover took over
eth2
status: Running
failover-only mode
pings: 0
fails: 0
run fails: 0/3
route drops: 1
ping gateway: ping.ubnt.com - REACHABLE
last route drop : Tue Jan 26 22:23:21 2021
last route recover: Tue Jan 26 22:24:02 2021
I thought this might have it licked
(The config also seems to be persisting...which is annoying as I think I've managed to add an interface somehow
).The vendor's support guys are confused on this one too. They have a line in to Ubiquiti so will see what they can find.
Looking to see how I managed to get a pppoe interface on the thing, I ran an interfaces status command and got this:
Interface IP Address S/L Description
---------- --- -----------
eth0 192.168.8.2/24 u/u WAN
2a01:4c8:1070:5b77:f0c4:2f9e:55e3:4/128
eth1 10.0.1.1/24 u/u LAN
eth2 192.168.1.12/24 u/u WAN2
lo 127.0.0.1/8 u/u
::1/128
Which I *think* is showing that the eth0 interface (4G router connection) is getting an IPv6 address from EE (the first bits of the address are the same as the public IP address EE gives the router).
I believe the /128 part might be the prefix size, and seem to recall reading somewhere that EE only uses /64...
Interface IP Address S/L Description
---------- --- -----------
eth0 192.168.8.2/24 u/u WAN
2a01:4c8:1070:5b77:f0c4:2f9e:55e3:4/128
eth1 10.0.1.1/24 u/u LAN
eth2 192.168.1.12/24 u/u WAN2
lo 127.0.0.1/8 u/u
::1/128
Which I *think* is showing that the eth0 interface (4G router connection) is getting an IPv6 address from EE (the first bits of the address are the same as the public IP address EE gives the router).
I believe the /128 part might be the prefix size, and seem to recall reading somewhere that EE only uses /64...
theboss said:
Looks to me like EE isn’t passing ping reliably - can you plug a device into the LTE modem directly bypassing the USG, and see if you can ping these same IPs from there?
That config won’t persist if you reboot the USG - it will re-provision your config as configured in the controller.
It also looks like you have set test count failure to 10 which means 10 consecutive pings need to fail before it deems the host unreachable and drops the link.
(I set it to 10 to give chance to see what was occurring That config won’t persist if you reboot the USG - it will re-provision your config as configured in the controller.
It also looks like you have set test count failure to 10 which means 10 consecutive pings need to fail before it deems the host unreachable and drops the link.
Also, the USG has been rebooted a few times, reprovisioning in the controller and this config is persisting).I tried the ping earlier whilst directly attached to the router and it worked (avg response 30ms).
The IPv6 address is the result of me setting IPv6 to DHCPv6 in one of my previous looks. Set it to disabled and it shows nothing now (as expected...and also with no change to the situation).
(Thanks again for the input btw).
camel_landy said:
IIRC - EE use IPV6 for the end points on their LTE network.
M
They do - and the APN I was using didn't even offer an IPv4 address (whatsmyipaddress shows it "not detected").M
They gave me another APN to use which does allocate an IPv4 address, but the IPv6 one still looks to be the primary.
The vendor support guys (who have been great thus far. As have EE's technical team) asked me to drop them the "show configuration" output...it's a pretty big file but scanning through it I noticed this:
ipv6-name WANv6_IN {
default-action drop
description "packets from internet to intranet"
rule 3001 {
action accept
description "allow established/related sessions"
state {
established enable
invalid disable
new disable
related enable
}
As far as I'm aware I have the USG firewall off. But the above looks like a rule of some sort that drops IPv6 packets which if it were happening would explain my situation! I haven't read the above in context of the rest of the file yet, but will get to that today (assuming the vendor/Ubiquiti don't come back first).
theboss said:
I think you're burdening yourself with the added complexity of IPv6 unnecessarily. They may well assign an IPv6 address to the LTE interface on your router, and use some transitioning technology on their side, but you needn't concern yourself with it. They aren't mandating that customers run IPv6 on their own network. Essentially your USG should be an IPv4 only DHCP client on the LAN side of the LTE router. Disable IPv6 on the USG WAN1 interface and if possible, disable IPV6 on the LAN interface of the Huawei as well. Save that particular challenge for another day
So are you saying you can connect an IPv4 client to the Huawei and ping away to your heart's content without problems?
It's highly likely I'm barking up a wrong tree (a whole feckin forest of them I suspect) So are you saying you can connect an IPv4 client to the Huawei and ping away to your heart's content without problems?
IPv6 on the USG WAN interface is now disabled again. Same issue (I only enabled it previously to check it and forgot it was still set).
If I connect my PC directly to the Huawei, I get internet connectivity and can ping away.
If I connect the Huawei direct to my switch, bypassing the USG (and removing it from the equation totally), then devices on the network can also connect to the network - the last time I tried this I did have some devices that couldn't connect to anything, which I put down to some DHCP oddities (but may not have been).
Unfortunately I don't see any way of disabling IPv6 on the router's LAN interface. The USG was picking up a valid IPv4 address from the 4G router via DHCP (I've also had it connected via a static IP too).
Neither of the other WAN connections I have (3 sim on the 4G router and the PlusNet based ADSL) show an IPv6 address (both show "not detected" in whatsmyip).
LordGrover said:
Have you renewed the DHCP leases on the clients when you make a change?
In the config I'm running the only real "client" in that respect (ie client of the 4G router) is the gateway. All other devices on the network get their details from the USG.Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff