Search:  

 
 
   All FAQsSite FAQDSL FAQCable TechAbout DSLDistanceCLECSDSL Hurdles»»






how-to block ads



Search for: in all FAQs
FAQ RevisionsEditors: PapaSmurf See Profile, RedXII1234 See Profile
Last modified on 2008-03-12 16:57:12
view: single page · printable

7. Troubleshooting

·Is there a preferred test for posting problem info on the forum(ping plot,etc)?
·Is there a web site for Cox HSI support?
·Are my ping times and packet loss a problem?
·Is there an official Cox speedtest site?
·Why would I see ARP traffic outside my subnet
·Will I loose my Cox HSI service during a power outage?
Unfortunately, there is no such thing as a gospel. Far too many variables to count on any single measurement. While a ping test MAY give an indication of a problem, it can also be misleading.

All that said, it really helps to have someone express what service (e-mail, news, web surfing speed)is affected and how. Saying something like, "My e-mail is slow," doesn't give us a lot to work with. It would be best expressed if you said something like, "My e-mail keeps timing out," or "I can't get to my personal web space, it keeps giving me error x." That's sufficient substance to know where to start trouble shooting, and it's a universal language most tech support professionals understand.

On speed tests, that's an imperfect science as well. Since the packet(s) being measured leave the Cox network(at some point), traverse the Internet and then return, your results are likely to be scewed if you only test once. In my humblest of opinions, the best measure comes from running the test at the same site at different times over a number of days(making sure you clear your cache after each test). This establishes a trend of peaks and valleys, and can give you a better indication of your particular connection's performance. Yet, even this method has it's down side. Once you leave the Cox network you'll likely pick up those Internet dust bunnies (external latency, slow or congested servers, etc.) that can return slower speed results that what you're actually getting through the Cox network. Again, multiple tests over a period of days can minimize the impact of this.

Back to the gospel thing, there are some really good tools here at this site. On occasion, we have been able to help customers just by interpretting the results they've posted here. There are just some obvious things that jump right out. However, what we've found is that a blend of tests work best. In most cases we revert to following up on ping tests and the findings of tools here with our own internal diagnostic tools. That way, we have as much data as possible and can better determine what things to look at and solutions to try.

feedback form

by PapaSmurf See Profile

Yes. The URL is http://support.cox.net.

feedback form

by PapaSmurf See Profile edited by RedXII1234 See Profile
last modified: 2002-03-25 20:25:22

First, remember that a "ping" is an Internet Control Message Protocol (ICMP) packet. It's a pretty simple as protocols go. ICMP is defined in RFC 792 and provides a way for IP stacks to send simple messages containing information or errors. Given this, it often gets the lowest priority of any protocol on the routing totem-pole, and may actually be rejected by routers if there is a lot of traffic on the network at a given time. To all that, ICMP has been used for scanning, Denial of Service (DoS) attacks, and tunneling thus some providers/markets turned off replies to ping.

Next, pinging the network and trying to correlate packet loss as the cause of your specific problem falls a bit short of the mark. Latency could be a result of the ICMP packets being held while higher priority traffic gets passed. Some devices will even discard ICMPs and give a false positive reading on packet loss. Furthermore, networks are loaded with electronic devices that will experience hiccups (for lack of a better word). That you saw a ping spike or two in a twenty four hour period is probably not an indicator of a problem.

To all that, pinging to a specific interface can give you inconclusive results. You should try to ping through the interface to a known device on the other side. Also, it's not uncommon to see that a ping coming from the ingress side of an interface yields a different result than one coming from the egress side. For example, someone in Middle Georgia, pinging to an interface on the Atlanta network(pinging from egress point)might see packet loss, where someone from Phoenix pinging (ingress)that same interface would see none.

So, what do you do? Well, don't discount packet loss or latency completely. This may indeed be an indicator of a problem with a router or interface. Do post the results of trace routes and ping plots, just remember to further quantify the problem by telling a little bit about what drove you to start trace routing in the first place (i.e. - slow download speeds (under 1 MB), frequent disconnects, modem losing sync, etc.)

Secondly, check all the obvious things -- your cable connections, RWIN settings (see the Tweaks forum here), look at the modem diagnostics if you have access to it, make sure you have all the latest patches for your browser, e-mail, and news client, etc. Check »support.cox.net for details on technical problems and service configuration.

If you're an online gamer, check the gaming forum here. Lots of pros to help you ensure your game and PC configurations are correct, and that you get the most out of the experience.

Also remember that the more info you can provide about your problem in the post, the easier it will be for other participants and tech support to assist in getting your problem resolved.

feedback form

by PapaSmurf See Profile
last modified: 2002-06-18 19:38:41

Cox does not have an official speedtest site. Some systems may have a home grown solution in place, but nothing exists for the global audience.

feedback form

by PapaSmurf See Profile
last modified: 2002-10-03 20:22:55

“ARP” stands for Address Resolution Protocol. It’s a protocol that allows the OS to associate an ip address (layer 3) with an ethernet MAC address (layer 2). For instance, let’s say we have two computers, A and B. A has the ip address 10.0.0.1 and the ethernet MAC address 00:00:00:00:00:01. B has the ip address 10.0.0.2 and the ethernet MAC 00:00:00:00:00:02. Both machines are on the same ethernet segment.
The first time A wants to send an IP packet to B, it initiates a conversation like this:
1) A -> FF:FF:FF:FF:FF:FF, ARP who has 10.0.0.2? This is a broadcast ethernet frame. It goes to every computer connected to the segment.
2) B -> A, ARP I have 10.0.0.2. This reply is directed specifically to A.

Now A knows that B is on the same segment as itself and the ip address 10.0.0.2 is associated with the ethernet MAC 00:00:00:00:00:02. Any traffic bound for 10.0.0.2 is then addressed to 00:00:00:00:00:02. It caches this ARP entry so it doesn’t have to rebroadcast every time it sends a packet to B.
The same principle applies to a CMTS. All the computers connected to cable modems registered on the CMTS are on a virtual ethernet. When the CMTS receives an ip packet, it sends out a broadcast ARP request to every computer attached to the interface for that subnet to find out what CPE MAC is associated with the IP. Most (all?) markets are now using ip bundling, which means that subnets span multiple interfaces. Because of this, each bundled interface has more customers on it, and thus they see a good deal more ARP traffic than they did back in the @Home days.
An ethernet ARP packet is only 60 bytes long, so the extra traffic does not affect the customer’s service in any way.
So to sum it all up:
1) It’s normal for customers to see lots of ARP requests
2) It’s normal for customers to see ARP requests for ip addresses on subnets other than the one their computer is currently on
3) The ARP traffic is harmless.
(SPECIAL THANKS: To the Cox abuse department for this input)

UPDATE:
ARP traffic is INCLUDED in your data totals for your connection usage and does count against the amount specified in the Cox usage limitation policy. It is estimated that approximately 1GB per month in traffic to your connection is ARP packets.

feedback form

by PapaSmurf See Profile edited by bmn See Profile
last modified: 2003-05-10 03:49:19

That depends. At a high level, in order for your HSI service to say "up," if you've lost electricity at you house your cable modem and any essential network devices would have to have their own backup power (e.g. UPS) so that they could continue to operate during the power outage.

The various network devices between the head-end and your cable modem have backup power available to keep them running during comercial power failure. Most distribution systems are actively monitored and will continue to operate on batteries for a number of hours. In this scenario, as battery capacity starts to dwindle below a certain standard, a technician is dispatched to the power suply and a portable generator is connected -- thus, keeping the connection alive. Other systems have backup generators which can maintain operation of the system as long as there is a fuel source.

feedback form

by NoVA_CoxUser See Profile edited by PapaSmurf See Profile
last modified: 2006-09-17 10:40:21



Saturday, 11-Oct 01:14:49 Terms of Use | Privacy Policy | Hosting by www.nac.net - DSL,Hosting & Co-lo | feedback | contact
over 9 years online! © 1999-2008 dslreports.com.