Selected ISP Support > DSL Extreme > Packet loss in SA, TX

reply to gsnider

Re: Packet loss in SA, TX

Hi Gsnider,

The line readings are great. I don't see any errors on the line. I am going to go ahead and create a support ticket on this issue as I have seen similar symptoms for other customers today (although non of them were in texas).

it looks like at&t is ramping up the line levels. I'm up to 10dbm downstream and 10.5 upstream and it seems to be improving

AT&T is scheduled to come out and check the line in the morning but I don't think it's the line. I'm running a ping to my 1st hop right now while downloading a file at 300kB/sec and I haven't lost any icmp packets. It looks like there's a problem either between at&t and grandecom or somewhere internal to grandecom. My ping is steady at 180ms but drops down to 45 or so for 1 or 2 pings which leads me to believe there are download packets being dropped at hop 2 or after which is freeing up layer 1 bandwidth for my continuous ping to go a little faster for a moment. Downloading an ubuntu iso at 300k/sec and here are my results from a non fragmented max mtu ping:

ping -n 1000 216.198.50.1 -f -l 1452

Ping statistics for 216.198.50.1:
    Packets: Sent = 236, Received = 236, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 40ms, Maximum = 236ms, Average = 177ms

Reply from 216.198.50.1: bytes=1452 time=192ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=179ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=188ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=198ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=183ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=183ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=188ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=188ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=236ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=138ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=144ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=156ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=164ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=186ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=193ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=41ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=66ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=83ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=182ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=218ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=188ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=188ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=178ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=190ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=184ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=184ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=186ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=190ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=181ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=182ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=181ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=180ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=182ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=175ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=184ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=184ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=185ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=181ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=181ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=181ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=181ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=172ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=183ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=183ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=176ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=185ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=185ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=186ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=186ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=186ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=186ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=186ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=190ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=180ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=181ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=180ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=180ms TTL=64
Reply from 216.198.50.1: bytes=1452 time=182ms TTL=64

Well of course AT&T never showed. I ran some ping tests to 216.198.50.1 and 216.198.63.1 from time warner and from the dslreports line quality tool. Here are the results:

216.198.63.1:
»/linequality/nil/2534335

Ping statistics for 216.198.63.1:
    Packets: Sent = 1000, Received = 1000, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 29ms, Maximum = 391ms, Average = 32ms

Ping statistics for 216.198.50.1:
    Packets: Sent = 1000, Received = 978, Lost = 22 (2% loss),
Approximate round trip times in milli-seconds:
    Minimum = 28ms, Maximum = 379ms, Average = 30ms

I have asked our network operations team to take a look. Since the latency is between you and the gateway, it typically indicates a problem on the DSL line itself or on the physical line. Have you tried replacing the phone cable and Ethernet cable that the modem are connected to. Are you connected directly to the DSL modem from the computer when running the test?

Thanks

I've tried 2 different modems, checked all the wiring in the house, used 2 different phone lines, 2 phone drops, 2 ethernet cables (when using the external modem). As you can see above, the packets are not being dropped at the 1st hop, it's between the 1st and 2nd hop(which indicates a network problem, not a dsl problem), even when being tested by 2 external networks as I showed in my last post.

Edit:
Just to clarify, the ping test in my last post was from my time warner cable connection, so the pings to the 2 ips were coming from external to grandecom's network. The post above that I show the pings to my default gateway from the dsl line with no packet loss even while downloading a large file.

My DSLExtreme ticket has been updated with latest info

It has been 9 days and still no progress has been made on this DSL service. This is quite clearly a layer 3 issue on the IKANO/DSLEXTREME network, yet AT&T has been called out 3 times. It is my understanding that AT&T provides a DSL and an ATM circuit. These are layers 1 and 2. I will restate my problem.

I have 100% connectivity to my first layer 3 hop, 216.198.50.1.

I get anywhere from 2-10% packet loss to my 2nd layer 3 hop, 216.198.63.1

The packet loss between these 2 hops can be verified by running continuous pings to these 2 hops from ANY external IP network.

I would appreciate it if you assigned a network engineer to this problem and not a Tier 2 DSL technician. This is unacceptable. I have done all of the necessary troubleshooting for you and I am still getting the run around.

Ping statistics for 216.198.50.1:
    Packets: Sent = 500, Received = 500, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 11ms, Maximum = 175ms, Average = 47ms

Ping statistics for 216.198.63.1:
    Packets: Sent = 500, Received = 464, Lost = 36 (7% loss),
Approximate round trip times in milli-seconds:
    Minimum = 11ms, Maximum = 1226ms, Average = 53ms

OrgName:    IKANO Communications Inc.
OrgID:      IKAN
Address:    265 East 100 South
Address:    Suite 240
City:       Salt Lake City
StateProv:  UT
PostalCode: 84111
Country:    US

NetRange:   216.198.0.0 - 216.198.63.255
CIDR:       216.198.0.0/18
OriginAS:   AS6137
NetName:    IKANO-1
NetHandle:  NET-216-198-0-0-1
Parent:     NET-216-0-0-0-0
NetType:    Direct Allocation
NameServer: NS1.SISNA.COM
NameServer: NS2.SISNA.COM
Comment:    ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate:    1999-02-03
Updated:    2008-01-16

OrgTechHandle: IPADM146-ARIN
OrgTechName:   IPADMIN
OrgTechPhone:  +1-801-924-0900
OrgTechEmail:  ipadmin@ikano.com