[Snap] Huge Packet Loss issues on SNAP UFB - Waiting for SNAP to respond....

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › [Snap] Huge Packet Loss issues on SNAP UFB - Waiting for SNAP to respond....

spacedog

482 posts

Ultimate Geek

#138995 24-Jan-2014 12:21

Anyone here have experienced packet loss issues on a SNAP UFB connection with a fritzbox?

We have been having significant issues with our connection and after doing some extensive testing I can see that we are getting 10%-20% packet loss on the connection.

I can replicate this issue pretty easily. I have enabled Telnet on the Fritzbox and also enabled ICMP response on the Fritzbox connected to the UFB connection. I also have DD-WRT based routers on my Snap VDSL connection at my home and at our office which has Iconz providing the internet backbone.

So no client computers are involved in this testing and all ping tests are run by telnet into the routers and between the routers. So the routers are:

ICONZ DD-WRT
SNAP VDSL DD-WRT
SNAP UFB FritzBox

Here are the results I see:
ICONZ DD-WRT <-> SNAP UFB FritzBox 6%-20% packet loss when pinging in either direction
SNAP VDSL DD-WRT <-> SNAP UFB FritzBox 6%-20% packet loss when pinging in either direction
SNAP VDSL DD-WRT <-> ICONZ DD-WRT 0% packet loss when pinging in either direction

I have been discussing with Snap since Wednesday, but getting this resolved is moving very slowly. I was told this was being escalated to Tier 2 response, but have not heard back. They said they ran a slope test and it looked fine and also that they sent pings every few seconds and it seemed OK. However, while on the phone with Snap I asked the tech to ping the Fritzbox and they also saw 11% packet loss on ICMP pings.

Clients connected to the fritzbox are having their remote desktop sessions intermittently drop and experiencing problems with web browsing (Gmail web interface timing out, web pages timing out, etc...).

I am really struggling to figure out what the problem is here especially since it is UFB and this is my first time working with a UFB connection in Auckland.

Anyone have any ideas/suggestions about what this might be?

Can you have a dirty/noisy fibre connection? Network congestion? Internal routing or hardware issue somewhere in the Chorus/Snap network?

I have asked Snap if they can provide a new Fritzbox so that we can determine if it is a failing/faulty Fritzbox. However, they said I have to wait for Tier 2 support and I'm still waiting for a reply.

Anyone have thoughts/suggestions/insights would be most appreciated. I'm at my wits end here and our ability to work and do business is being majorly impeded here.

Thanks!

Lorenceo

904 posts

Ultimate Geek

Trusted

#973507 24-Jan-2014 13:21

What happens if you try something other than the Fritzbox router on the UFB connection?

spacedog

482 posts

Ultimate Geek

#973510 24-Jan-2014 13:24

I don't entirely understand how the fritzbox is configured to work with the connection. What can I use instead and how would I configure it?

wongtop

563 posts

Ultimate Geek

#973528 24-Jan-2014 13:49

What speed UFB? Snap were having issues with the 200/50 plan. If you are on this it may be best to downgrade to a lower speed until they sort it out.

Lorenceo

904 posts

Ultimate Geek

Trusted

#973555 24-Jan-2014 14:08

You can connect with any router that supports VLAN tagging and PPPoE on its WAN port.
Tag all WAN packets as VLAN 10, set up your snap username and password in the PPPoE settings and it should connect.

You could also use a computer with a PPPoE dialer to test it, as long as its NIC can do VLAN tagging. But be careful when doing this though as it exposes the computer directly to the internet.

spacedog

482 posts

Ultimate Geek

#973978 25-Jan-2014 10:00

It seems Snap had left smokeping running on the account. When they turned it off the packet loss stopped. Is that normal? Should smokeping be able to disrupt and flood a connection that easily?

We were having our remote desktop sessions drop out every 3-5 minutes. The connection seems more stable now, but I'm still feeling like it is not 100% so I have to continue testing.

timmmay

20574 posts

Uber Geek

Trusted

Lifetime subscriber

#974125 25-Jan-2014 14:45

What's a smokeping?

spacedog

482 posts

Ultimate Geek

#974389 25-Jan-2014 23:08

smokeping is a very common ping and network latency testing tool. Unix based and very widely used.

Equinox IT

Cloud spending continues to surge globally, but most organisations haven’t made the changes necessary to maximise the value and cost-efficiency benefits of their cloud investments. Download the whitepaper From Overspend to Advantage now.

eXDee

4032 posts

Uber Geek

Trusted

#974439 26-Jan-2014 01:06

Smokeping by default i believe sends an ICMP packet every 5 minutes or so. It's not going to bring down a connection unless you've done something very odd with it.

quakeguy

111 posts

Master Geek

Trusted

#975203 27-Jan-2014 16:19

The Fritz!Box rate-limits ICMP requests. It counts all ICMP sources toward the rate-limit; therefore, if someone else is pinging the Fritz, it may appear to drop packets.

I don't like this behaviour either; hopefully AVM will choose to remove it at some point.

So fear not - this isn't actually loss.

EDIT: Sorry, we'd have told you this earlier... but I have *just* figured this out.

“I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success... Such emotions make a man forget food, sleep, friends, love, everything.” - Nikola Tesla

Disclaimer: Views expressed in my posts do not necessarily reflect those views of my employer.

mercutio

1392 posts

Uber Geek

#975298 27-Jan-2014 18:38

quakeguy: The Fritz!Box rate-limits ICMP requests. It counts all ICMP sources toward the rate-limit; therefore, if someone else is pinging the Fritz, it may appear to drop packets.

I don't like this behaviour either; hopefully AVM will choose to remove it at some point.

So fear not - this isn't actually loss.

EDIT: Sorry, we'd have told you this earlier... but I have *just* figured this out.

omg that's disgusting. is it just icmp-echo, or icmp in general?

quakeguy

111 posts

Master Geek

Trusted

#975449 27-Jan-2014 23:12

mercutio:
quakeguy: The Fritz!Box rate-limits ICMP requests. It counts all ICMP sources toward the rate-limit; therefore, if someone else is pinging the Fritz, it may appear to drop packets.

I don't like this behaviour either; hopefully AVM will choose to remove it at some point.

So fear not - this isn't actually loss.

EDIT: Sorry, we'd have told you this earlier... but I have *just* figured this out.

omg that's disgusting. is it just icmp-echo, or icmp in general?

Unsure, yet. MTR to an internet host remains best way of gauging packet loss for now

Disclaimer: Views expressed in my posts do not necessarily reflect those views of my employer.

mercutio

1392 posts

Uber Geek

#975451 27-Jan-2014 23:21

quakeguy:
mercutio:
quakeguy: The Fritz!Box rate-limits ICMP requests. It counts all ICMP sources toward the rate-limit; therefore, if someone else is pinging the Fritz, it may appear to drop packets.

I don't like this behaviour either; hopefully AVM will choose to remove it at some point.

So fear not - this isn't actually loss.

EDIT: Sorry, we'd have told you this earlier... but I have *just* figured this out.

omg that's disgusting. is it just icmp-echo, or icmp in general?

Unsure, yet. MTR to an internet host remains best way of gauging packet loss for now

maybe mtr -u is better (to use udp mode)

spacedog

482 posts

Ultimate Geek

#975567 28-Jan-2014 09:16

that sucks....often rely on ping because that is installed by default on fritzbox and dd-wrt routers...MTR is not so can't do tests from router to router...

that's frickin' horrible on the fritzbox part