Hi,

Has anyone noticed any recent issues with Virgin Media (Super Hub in modem mode) connected to a 2860n+ or similar?

* I have an old EE ADSL broadband connection on WAN1 and my Virgin Media connection on WAN2 - no load balancing configured, I just separate clients out on the two connections with IP ranges
* I've changed nothing for months (years going back with a similar setup/other Draytek models) and all has been well.
* I'm running 3.8.9.3_BT
* All connected clients, WAN1 or WAN2 use Google DNS
* IPv6 is switched off, wherever

However, since early this morning, big issues with all machines connecting on the Virgin Media WAN2:

* Generally the connection isn't working outside the LAN at all
* When it is working, pings outside the LAN fail or, when they do (briefly) succeed, are massively slow
* The Super Hub logs show no errors
* Clients connected on WAN1 are, however, fine (hence me being able to post this)

I've rebooted both SuperHub and 2860n+ multiple times - I get an (apparently) stable connection to Virgin Media on WAN2, but the above issues persist - the connection is unusable.

All ready to blame Virgin Media, I tried a connection directly into the back of the Super Hub, bypassing the 2860n+ and...absolutely fine. Full bandwidth, no apparent problems.

I'm all for digging into this - it *seems* likely an issue with my setup/configuration of the 2860n+ but, as above, I've changed nothing.

Here's my general setup:





Any ideas on how to poke into what's going on?
I can't see anything obvious in web syslog on 2860n+.

Thanks.

Something extra on this, that just occurred to me.

If I do a ping from the 2860n+ on WAN1 (old EE ADSL) I get:

Code:

Pinging through WAN1. Pinging 8.8.8.8 with 64 bytes of Data through WAN1: Receive reply from 8.8.8.8, time=40ms Receive reply from 8.8.8.8, time=40ms Receive reply from 8.8.8.8, time=50ms Receive reply from 8.8.8.8, time=20ms Receive reply from 8.8.8.8, time=50ms Packets: Sent = 5, Received = 5, Lost = 0 (0% loss)

If I do the same on WAN2 (Virgin), then I get:

Code:

Pinging through WAN2. Pinging 8.8.8.8 with 64 bytes of Data through WAN2: Request timed out !!! Request timed out !!! Request timed out !!! Request timed out !!! Request timed out !!! Packets: Sent = 5, Received = 0, Lost = 5 (100% loss)

So, I suppose that at least rules out issues client-side for machines that are using Virgin/WAN2.

In addition, pinging from a client connected to WAN2, during the initial period following the 2860n+ connecting to the Superhub, I see the following sort of response times:

Code:

64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=320 ttl=53 time=12660 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=321 ttl=53 time=11663 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=322 ttl=53 time=10679 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=324 ttl=53 time=13434 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=336 ttl=53 time=13751 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=340 ttl=53 time=12646 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=344 ttl=53 time=12626 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=345 ttl=53 time=11631 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=346 ttl=53 time=10660 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=348 ttl=53 time=11623 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=349 ttl=53 time=11606 ms 64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=350 ttl=53 time=10638 ms

...that's while the connection is actually working/ After a while it just stops working.

I'm still none the wiser as to why this is no longer working .

All is fine when connected directly to the Superhub, and nothing has changed in the setup here for a *very* long time.

Well, I've changed the cable between the Superhub and the Vigor 2860n+, followed by yet another Superhub reboot.

I can't help but think that the cable change isn't linked, but....everything *is* working, at least for now...