Kesseki
join:2001-07-21
Brooklyn, NY
| Carlsbad, CA packet loss
Hi,
I'm a TFBNET user in Carlsbad, CA (CRLSCA11; northern San Diego county) with New Edge 768/384 ADSL service. At times over the past two months, I've been seeing sporadic packet loss between New Edge/TFB and the Internet. Many of my outbound traceroutes go through TransEdge, so I believe TFB is buying most of their upstream connectivity from them.
My individual circuit isn't the problem; I'm always able to ping my gateway, with no loss whatsoever. Any pings or traceroutes beyond the gateway will show varying amounts of loss, and during the times that problems are happening, outside connectivity will completely drop for 3-4 minutes, then things will go back to mere packet loss, in 10-20 minute cycles.
Here's an example of the loss:
--- (gateway) ping statistics ---
347 packets transmitted, 347 packets received, 0% packet loss
round-trip min/avg/max = 31.7/36.6/191.6 ms
--- 128.101.101.101 ping statistics ---
340 packets transmitted, 270 packets received, 20% packet loss
round-trip min/avg/max = 98.7/175.3/415.6 ms
This will usually happen for one or two days, and then things will be fine for a week or two.
Is anyone else on New Edge in SoCal seeing anything like this? The most TFB has had to say is "reboot your modem" and , once, "there's some problem with New Edge, they're looking into it." |
|
broadbndgeek
Premium
join:2000-08-03
Graham, WA
| A couple of things could be affecting your service. A misconfiguration and an unupdated routing table in TFBnet's routers. The circut that TFBnet has from NEN is most likely an ATM DS3. Could you post a traceroute to ns1.semaphore.net, please. How many hops do you see a transedge.com DNS entry? If TFBnet is buying layer2/3 from NEN I know that NEN has been doing alot of routing changes, even then the problem would most likely lay within a TFBnet router. I wouldnt go putting the blame on anyone yet, post that traceroute when you get a chance.
--
100% ATM Backbone Travelage!(Transedge/NewEdge Style!). |
|
Kesseki
join:2001-07-21
Brooklyn, NY
| Here's the traceroute. As you can see, it goes onto TransEdge almost immediately.
traceroute to ns1.semaphore.net (209.221.128.1), 30 hops max, 38 byte packets
1 bvi3.hub1.flbk.tfb.com (204.216.235.1) 38.780 ms 32.375 ms 31.853 ms
2 a5-0-503.border2.rap.lax.transedge.com (216.171.145.81) 39.559 ms 40.376 ms 39.740 ms
3 f8-5.border2.rap.lax.transedge.com (216.171.128.65) 41.049 ms 39.625 ms 41.072 ms
4 a5-0-140.border1.rap.sjc.transedge.com (216.171.128.106) 54.306 ms 57.403 ms 53.754 ms
5 f0-0.agg1.rap.sjc.transedge.com (216.171.128.82) 56.150 ms 54.002 ms 56.059 ms
6 unassigned.transedge.com (216.217.2.49) 83.597 ms 69.321 ms 71.192 ms
7 f4-0.border2.rap.pdx.transedge.com (216.217.2.14) 72.291 ms 70.885 ms 72.288 ms
8 p1-1.border1.lsa.pdx.transedge.com (216.217.3.57) 73.916 ms 71.426 ms 76.092 ms
9 p1-5.border1.lsa.sea.transedge.com (216.217.3.141) 76.134 ms 73.603 ms 70.581 ms
10 p2-0.border1.rap.sea.transedge.com (216.217.3.62) 74.037 ms 72.458 ms 72.828 ms
11 f0-0-0.border2.rap.sea.transedge.com (216.171.128.34) 76.067 ms 74.696 ms 74.945 ms
12 g2-0-six-sea1.semaphore.net (198.32.180.16) 72.901 ms 75.441 ms 75.812 ms
13 v500.cr4.sea1.semaphore.net (209.221.160.104) 93.485 ms 79.664 ms 78.784 ms
14 ns1.semaphore.net (209.221.128.1) 76.133 ms 76.424 ms 76.095 ms
Thanks for your help! |
|
broadbndgeek
Premium
join:2000-08-03
Graham, WA
| No Problem. By the looks of it you have a TransEdge account. The routing looks fine. You might have TFBnet check your port on their router, see if it has taken any errors, and see if they see the downtime on the port you are seeing on your end. I would definitely give TFBnet a call and ask them to do those things mentioned above in this post.
The second hop in the traceroute is TFBnet's agg circuit from NEN. Also as you can see, TFBnet is using NEN for Layer 2 and Layer 3 operations.
--
100% ATM Backbone Travelage!(Transedge/NewEdge Style!). |
|
netjedi
join:2002-08-01
Gillette, WY | reply to Kesseki
Just a note that an upstream provider is not the only reason for packet loss. If the ISP provider does not properly balance their feeds, shape packets aggressively, etc., it can have this affect. |
|
