Business cable modem packet loss
 

We have started to suffer bursts of packet loss on our business cable modem service (50 Mb, fixed IP) that occur spasmodically but normally only during busy periods. This peaks at 25-30% loss and causes users to get broken web pages, timeouts etc.

We switched over most of our traffic to our backup line (a Zen FTTC) and all the problems disappear - the packet loss on that line is zero or 2-4% max during peak activity.


Whilst configured in this way I captured a Thinkbroadband ping graph and you can see one event this morning, even though most of our traffic was going via Zen. See this graph at this link:
My Broadband Ping

We reported a fault to VM Business but they can see nothing wrong with our modem. I suspect the problem is further out in their network, perhaps even somewhere in their fixed IP routing network.

Does anyone have any suggestion about how to report such a problem effectively so someone will be triggered to look at this to get it fixed?

Re: Business cable modem packet loss
 

Although a business account will get you an engineer quicker than residential an engineer cannot fix congestion on your segment of the network. This is where VM fails on business connections.

Keep ringing up until you get a result, it may take a while or ditch them.

Re: Business cable modem packet loss
 

The above issue fixed itself the next day, so either someone read this thread and fixed it or the problem was fixed as is was causing other issues.

I left the Thinkbroadband trace running though and noticed how busy the connection is. See this image:
http://www.thinkbroadband.com/ping/s...8-07-2016.html
http://www.thinkbroadband.com/ping/s...8-07-2016.html

This is not down to our traffic (as we are not here 24/7) but must be due to traffic in VM network. As we used the fixed 5 IP option I wonder if this could be due to congestion in networks provided to enable that option (which I think involve us effectively having a VPN into router which redirects the fixed IP traffic to our modem).

That variation in ping times does not seem to cause too much of a slow down but is far from ideal. We also have Zen/Openreach FTTC line too and the variation in ping times is normally only around 20 ms (so lots of black on the graph).

Anyone know if VM are close to releasing the 200 Mb/s service with multiple fixed IPs yet, several of their estimated release dates have passed. Hopefully it does not pass through the same parts of VM's network?!

Re: Business cable modem packet loss
 

I have seen similar varying ping times on my 50 Mb/s business service with 5 fixed IP addresses as well. This used to be much clearer, but right now looks like:-

http://www.thinkbroadband.com/ping/s...29-07-2016.png


You are right the older 50 Mb/s uses an L2TP tunnel to deliver the fixed IP service to the Business Suberhub.

The newer services are yet launched with multiple static IP addresses, just dynamic or single static. These services must be close to launch now, as they have progressed beyond trial and are in a small pilot phase right now. I am in that pilot (which is not under NDA) and have the 200 Mb/s provisioned also with 5 fixed IP addresses. There is a similar method used to deliver the fixed IP addresses, but instead of using an L2TP tunnel they use a GRE tunnel. This terminates in a different location in the VM network. This incidentally means you cannot port IP addresses from the older L2TP to the GRE based service so you will get a new block of addresses when the new services are fully launched.

Connected to the same cable, which is split, I have the older 50 Mb/s service running (above graph), and below you can see the same time period on the 200 MB/s service.

I am not in an upgraded area so 200 Mb/s is the maximum currently available here. This is running on 12 downstream channels and 2 up off a Cisco CMTS

http://www.thinkbroadband.com/ping/s...29-07-2016.png

Re: Business cable modem packet loss
 

I'll just amplify on CC's excellent explanation above.

The modem is running on the given Dynamic IP Address as would be necessaary for the DOCSIS environment. Through that link, a GRE Tunnel is established to VM's servers. These are given the Static IP Addresses to which you are subscribed and are thus the proxy servers for your static addresses.

It's clever but a bit of a dog's dinner when you take the associated latency into account. It can't be done differently (whether L2TP or GRE) in the residential DOCSIS environment.

I have both business (Hitron) and residential services. The 16 downstream channels are identical on both modems indicating that my node hasn't yet been allocated a larger service group - or they haven't configured the CMTS to differentiate accordingly. So anything I hammer on the domestic side steals from the business side - not that I see much of that as other than a theoretical problem.

Re: Business cable modem packet loss
 

It should be mentioned that this is basically how almost all BT FTTC services work. You connect via a PPPoE tunnel to a server that delivers IP.

Latency increase can be kept to a minimum by having the terminating services close to the same path the traffic would take anyway.

In the case of VM they can put the servers where their core sites are. The CMTS are each homed to 2 or more core routers in the same POP site, so putting a BRAS in the same site as those core routers will add very minimal latency as all traffic would be going through that site anyway, just the last hop to the CMTS has GRE / L2TP headers added rather than being native IP.

Using this are as an example the CMTS serving it are in Leeds South, VM code lee2, and all of them backhaul through Leeds Seacroft, VM code leed's core routers.

Place a BRAS in Leeds Seacroft and you're good to go to serve all hubsites homed from there. Seacroft had BRAS for the old VM National ADSL service anyway, so could trivially repurpose those.

It's a bit of a headache but is the only way to deliver truly static IP addresses over a cable platform without wasting a bunch of them, and they are a pretty valuable commodity now.