The 85ms on the third test of line 2, and the whole of line 3, plus the timed out entry on line 4 suggest to me that the two Zen routers are getting some short-term queues of heavy traffic so not handling the pings well.

Not even passing them through occasionally?

In reply to a post by Ignitionnet:

In reply to a post by PaulKirby:

I am wondering if they are having routing issues and being routed to a further Internet Exchange.

Maybe one of the Manchester Internet Exchanges or the one in Leeds might of been better for them instead of a London one.

Paul

Nah. Across the BT Wholesale network, I presume, to Telehouse North then straight across LINX London according to their trace

1 <1 ms <1 ms <1 ms 192.168.50.1
2 20 ms 20 ms 85 ms vt1.cor1.lond2.ptn.zen.net.uk [51.148.72.23] << Telehouse North
3 31 ms 37 ms 30 ms ae-17.agg3.lond2.ptn.zen.net.uk [51.148.73.32]
4 20 ms * 20 ms 195.66.225.91 << LINX LON1 / Juniper LAN
5 20 ms 20 ms 20 ms 151.101.64.81

Might be taking a rather circuitous route across the BT Wholesale network, mind.

My point was they are closer to Manchester or Leeds then they are to London.

Also not too sure if Zen hides a lot of the hops (or only display hops that respond) but I am liking the 5 hops to the BBC Site

Paul

In reply to a post by RobertoS:

The 85ms on the third test of line 2, and the whole of line 3, plus the timed out entry on line 4 suggest to me that the two Zen routers are getting some short-term queues of heavy traffic so not handling the pings well.

Not even passing them through occasionally?

The lack of packet loss to the end destination alongside zero evident jitter, all 3 pings coming back with the same round trip, suggests to me that there aren't issues there. Ping response from a router takes a completely different path to the one forwarding them uses and should be ignored as a general rule. The only time it's relevant is when all subsequent hops show the same condition of loss / high latency.

I know/knew what you are saying but hold to what I said too.

You are correct in that the anomalous behaviour is not relevant to data throughput, but it does point to those two routers having more important things to do at those times than respond to pings.

That�s the point of the test as opposed to a straight ping test.

As you say, a consistent rise at and following a given step shows a congestion/pinch point that could affect real traffic, so in general you are right. But in this case we have a delayed response spanning three hops, all involving the two Zen routers in London, then clearing. I believe that in this particular case those delays were relevant.

Traceroute goes along the control plane not the forwarding plane. It may be treated with a low priority if there are other more pressing tasks such as pretty much anything, it may be rate limited, it may be blocked entirely. Not sure what the point is of the test if the anomalous behaviour isn't relevant to throughput but should be noted.

I find it more likely if the home install is clean that this is an issue on the BT Wholesale network with the customer's connection taking a very circuitous route to Zen's LNS.

Anyway here's Zen's agg3.lond2.ptn.zen.net.uk:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 51.148.73.32, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Here's cor1.lond2.ptn.zen.net.uk

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 51.148.73.31, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Both pinged from the LINX LAN, both seem healthy. I fully imagine latency increases when they are converging their routing tables but, as you said, this isn't relevant to throughput.

LOL
Despite your blinding with science type post, I think it suggests we are in fact now in agreement.

For instance, I started from the assumption that the timeout at 4 20 ms * 20 ms 195.66.225.91 << LINX LON1 / Juniper LAN was due to something prior to that, specifically to do with zen. I wouldn't expect that LINX routers are going to timeout on a ping. It's far more likely it was dropped in one direction or the other in the "zen network".

I also noted that the displayed transfer within LON2 is zen to zen.

Hop 3 is relatively normal, I agree that. The third entry of 85ms on hop 2 could be that router, or something earlier. You suggest it was earlier.

However I find this repeated opinion, "an issue on the BT Wholesale network with the customer's connection taking a very circuitous route to Zen's LNS" rather vague. Are you blaming BT Wholesale itself, or zen's rented WBMC MSIL capacity/option? Have we in fact established this is routing via BTW anyway, not zen's own backhaul?

Not so much in agreement. I'm not remotely bothered by the 85ms latency and aren't going to claim it was caused by anything prior to it as there's no evidence of that, especially within the poster's BQM.

Wasn't blinding with science, or trying to at least, just stating how things work.

I am confident that the FTTP is over the BT Wholesale network because, as far as I know, Zen don't have any FTTP CableLinks at this time outside of perhaps some trials.

I am not blaming any subset of the route between the customer and Zen's network because there's no data to support either claim above the other.

Anyway with that back to the day job

EDIT: https://www.thinkbroadband.com/broadband/monitoring/...

No spikes around time of traceroute anywhere near 85ms. Packets are getting forwarded okay by the looks with maybe a touch of peak time strain.

Edited by deleted (Tue 14-May-19 14:03:09)

Looking at their BQM

Looks like something went on around 1:45 to 2pm today and there was a drop in latency at around 2:10pm

Of course no idea what the change was, maybe different router or a routing tweak from Zen or wholesale team

Prior to this change the overnight looks as clean as I'd expect with the yellow block between 9pm and 11pm looking like actual usage of the connection.

Think I've seen their speed test while doing the daily rounds, and something no one has suggested but might explain speed problems...

So to original poster double check the speeds that the Ethernet interfaces are connecting at, since speed test is nailed to what you would get for a port running at 100 Mbps.

Worth mentioning that an RJ45 cable or port with one pin missing can downgrade the link from 1G to 100M. So can using a "crossover" cable instead of a straight-through one.