High packet loss and other DNS issues

[#1]

@scottrc I'd be interested to know if when the VPN was established if traffic was still routing through the 137.hiper04.sheff.dial.plus.net.uk and 141.hiper04.sheff.dial.plus.net.uk path.

[#2]

The free VPN services dont seem to work as well, but the premium ones I get no buffering at all. Not sure if there is a difference in where they would route.

[#3]

---

@andyr700 wrote:
@scottrc I'd be interested to know if when the VPN was established if traffic was still routing through the 137.hiper04.sheff.dial.plus.net.uk and 141.hiper04.sheff.dial.plus.net.uk path.

---

I know this wasn't addressed at me, but I can replicate the same. If I use a VPN packet loss is (apparently) negligible. I imagine this is being masked by the tunnel not acknowledging the (lost) packet and it being re-sent/requested.

Here is my packet loss summary to google.com on my plus net connection:

$ ping -c 50 -q google.com
PING google.com (172.217.23.46): 56 data bytes

--- google.com ping statistics ---
50 packets transmitted, 42 packets received, 16.0% packet loss
round-trip min/avg/max/stddev = 25.310/31.408/65.273/7.942 ms

This is a traceroute to my VPN (which still goes through the problematic hiper04 router(s) as seen by the timeouts. Please ignore my complex internal routing (1-3), 4 is the plus net gateway (172.16.11.29; which does not respond), 5 is the hiper04 router which fails to respond on one occasion (though in other traces, assuming the same routing, at all):

$ traceroute -I vpn.uis.cam.ac.uk
traceroute to vpn.uis.cam.ac.uk (131.111.2.3), 64 hops max, 72 byte packets
1 homedsl.co.uk (192.168.0.1) 1.701 ms 2.376 ms 1.323 ms
2 192.168.0.250 (192.168.0.250) 1.473 ms 1.782 ms 1.523 ms
3 192.168.1.250 (192.168.1.250) 2.894 ms 6.654 ms 19.726 ms
4 * * *
5 * 133.hiper04.sheff.dial.plus.net.uk (195.166.143.133) 24.216 ms 29.942 ms
6 be3-3102.pcn-ir02.plus.net (195.166.143.132) 34.261 ms 27.333 ms 23.127 ms
7 195.99.125.140 (195.99.125.140) 23.777 ms 28.209 ms 23.712 ms
8 195.99.127.81 (195.99.127.81) 23.545 ms 24.405 ms 24.630 ms
9 195.99.125.18 (195.99.125.18) 22.964 ms 36.830 ms 33.288 ms
10 ae4.londtn-sbr1.ja.net (146.97.35.209) 34.378 ms 23.736 ms 24.509 ms
11 ae29.londtw-sbr2.ja.net (146.97.33.9) 26.218 ms 25.807 ms 25.240 ms
12 146.97.38.18 (146.97.38.18) 27.279 ms 25.956 ms 26.081 ms
13 146.97.65.117 (146.97.65.117) 36.081 ms 31.402 ms 36.147 ms
14 university-of-cambridge.cambab-rbr1.eastern.ja.net (146.97.130.2) 46.125 ms 27.683 ms 28.220 ms
15 b-ec.c-mi.net.cam.ac.uk (192.84.5.93) 26.771 ms 40.450 ms 26.493 ms
16 c-mi.d-dw.net.cam.ac.uk (192.84.5.154) 27.008 ms 31.925 ms 26.918 ms
17 d-dw.s-dw.net.cam.ac.uk (193.60.88.2) 43.488 ms 27.471 ms 27.440 ms
18 vpn.uis.cam.ac.uk (131.111.2.3) 36.527 ms 25.846 ms 26.826 ms

Here is the ping summary for the same address for google.com used in the first summary (172.217.23.46) when connected to my VPN:

$ ping -c 50 -q 172.217.23.46
PING 172.217.23.46 (172.217.23.46): 56 data bytes

--- 172.217.23.46 ping statistics ---
50 packets transmitted, 50 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 31.164/42.998/297.481/37.605 ms

So, to answer your question. Yes, it looks like the traffic is still being routed through the intermittently responsive router (or segment) when on the VPN, however the VPN appears to be masking the issue. Without any internal info, I assume this is the same effect I was experiencing when provided a static IP (i.e. my flaky connectivity was being tunnelled to a stable endpoint, and the tunnelling was masking the issue though not actually resolving it).

[#4]

@andyr700

1. They've not openly stated to me they have a problem, but going by the phone calls and ticket correspondence do acknowledge something's not right on their end. I've experienced it for ~3 weeks, but I was on holiday and came back to cries about "slow internets", so the 5 weeks some people suggest they've been having it seems about right.

2. I've been on a couple of ranges with the issue, notably 51 and 143, currently on 51.6.*

3. Those nodes are something of a bermuda triangle for my packets as well.

4. Negative. I was initially told it was a congestion issue at my exchange, which was "resolved", then I was contacted by an engineer to say that probably wouldn't fix my issue (nope), with a note regarding moving me onto a less utlilized VLAN to see if that'd improved matters (nope).

As far as them fixing it, they seem to be going through a process of elimination. As noted they moved me onto a different VLAN, which didn't improve things, so they've chalked that off and are going to try something else when they have more data - at least that was the general gist of my last recieved call. I get the impression it's only recently been escalated to the engineers, who are aware of this thread - they asked me to post updates in it.

[#5]

Massive improvement tonight. Best graph in weeks and I've had no IP change. It's still not great mind you...

[#6]

Occasional packet loss here. Not too bad though, just realised it when videos wouldn't buffer. Packet loss here isn't as bad as your graphs but it is still a tiny amount.

I'm on the 146.198 range and served by the gateway core2-hu0-18-0-0.colindale.ukcore.bt.net (62.172.103.16) 5.402 ms

Should I also not be having a BT ip on speedtests?

[#7]

All I can say at this point is thankfully my plusnet experience is over. I started enduring this fault, like others more than 5 weeks ago, no gaming, no video's, slow pages and so on. Today I begrudgingly made my final payment, I really don't see why I should have though in light of the service I was receiving. The most amusing bit is plusnet's tactic for when you decide to not pay:

The irony! It was restricted before I decided to stop paying because plusnet can't fix the goddamn fault! Nice network upgrade there guys, you really did me proud.......wait, I'll reword that, plusnet will certainly do you!!!!!!

[#8]

@UhtredTheBold Yes it's an improvement for you mate, but if you're a gamer it's still utterly useless! Unless you enjoy the backwards/forwards goose step stutter mid game

[#9]

Coming up to week 4 of terrible fibre optic service and I'm about to pay for another month? 

not even had a reply from my question a week ago, and they quote a reply period of 72 hours (http://imgur.com/G7YKwFV). Some top quality service they are hosting here...

Have been using skype recently for business calls from home but every few seconds I'll lose connection for a word or two. Having to repeatedly say 'pardon, sorry I didn't hear that due to a faulty connection' get's old after the 14th or 15th time.

As I said last week, it is an absolute joke. Not even anything said by a community manager, or even someone on the technical detail comment to say "we're working on it".

[#10]

@drunkmunky I don't think they will acknowledge it as the only way that can is to say they have introduced traffic/network management like Virgin Media do.

I tested my connection on and off all day yesterday and from 8am till 4pm my line was great, no packet loss,decent ping(15ms),no jitter and full throughput, 4pm hit and it started with 10% packet loss,ping 32ms, jitter 12ms and throughput slowdown.This increased to 58% packet loss,98ms ping,jitter 40ms+ and throughput bouncing all over the place, this stopped just after 11pm and went back to being fine.

I have spoken to a few friends and work colleagues around the UK who are Plusnet customers and all are effected by this.

The lack of response from the staff here speaks volumes.

@andyr700

1. Has anyone received a response from PlusNet stating that they are experiencing infrastructure issues and have a plan of action for its resolution? As far as I can tell this thread has been around for ~3 weeks and there are comments that it was going on before then.No i have been told various things by Customer service, which when i question i get told everything is fine and it must be my equipment at fault.
2. My current IP is 51.9.57.165. Is everyone here (other than when you got a static IP and had a drop in upload / download) on a 51.9.57.xxx range? Im on the 146 range
3. Are the services you are trying to access routing through either 137.hiper04.sheff.dial.plus.net.uk or 141.hiper04.sheff.dial.plus.net.uk? I know this is the case for both twitch.tv and Blizzard games. These are the key points in my route experiencing up to 75% packet loss. You can use PingPlotter like the first poster to determine this.137.hiper04.sheff.dial.plus.net.uk is currently hitting 81.4% packet loss for me
4. Has anyone on this thread had the issue resolved? Was there anything in particular done to your account to achieve this? Or did it just go away? Not resolved for me and its 5 weeks and counting.

[#11]

Acorrding to HarryB PN staff on this thread https://community.plus.net/t5/Plusnet-Feedback/Chat-queue-shocking/td-p/1359889

I'm not aware of any widespread issues, but it does seem busier that it has been overall recently.

[#12]

FAO: Plusnet

I have set up a freshly imaged raspberry pi directly connected to my modem and have isolated my home network from this segment. I am willing to provide SSH root access to this box to allow customer premises testing to occur at your convenience without needing to contact me while you test whatever you see fit.

Additionally I am able to provide telephone contact if any additional configuration or testing is needed that you cannot carry out yourselves.

Naturally I am currently experiencing 0% packet loss, but if history is any indicator I (like others here) will be experiencing extremely problematic connectivity again in a few hours.

Please private message me, email me, or call me on the number you have on file and I will provide the connection details to the box (address, port, username, password).

[#13]

---

@davvy76 wrote:

@UhtredTheBold Yes it's an improvement for you mate, but if you're a gamer it's still utterly useless! Unless you enjoy the backwards/forwards goose step stutter mid game

---

ok...

[#14]

@jtjacques thanks for the kind offer, that could be really useful. I've sent you a PM. I'm one of the people working on this but with a problem like this it's hard to replicate so this could be really useful in trying to track down the problem.

Thanks

[#15]

Yesterday was the worst day so far.
As it's in the evening there must be a bottleneck somewhere.