whatismyip reports the IP address of your computer (or router), not the IP address of your cablemodem's external interface.
Most -- nearly every -- cable provider won't burn a public IP address on the external interface of a cablemodem since it will never need to be accessed from outside the company's network. It will be assigned a private range IP, usually a class A address (10.x.x.x).
And since the cablemodem is only a bridge, you will not be able to find it's address reported by any outside sources, especially any off the network.
The Motorola Surfboard modems do not report the external IP address of the cablemodem on any of it's status pages, either. And I don't recall seeing any cablemodem that will report this address to the end-user. Essentially, the most likely way you might be able to find out the IP address of the external interface of your cablemodem is if a CSR tells you what it is. And that would only be accurate at the time they tell you. (And they're not supposed to tell you what it is, anyway, so it may not be available to them as it once was.)
Please tell me more about this 10.x.y.z. IP address. That address, the first upstream node in my tracerts, is the only address that has no ping dropouts. Is that the modem as seen by the PC? Everything else upstream has a 2% and higher dropout rate.
No, it's just a standard coupler (it's threaded on both ends on the outside).
I'll drop by Time Warner tomorrow and try to borrow a modem - they're only 5 blocks away. If I can eliminate the modem as a cause of the packet loss, I'll be able to prove it's a network problem. Otherwise, I'll have to sit on the phone for an hour again to get Tier 3 to order another tech visit and the guy may or may not show up. Line techs have been here, but they don't do anything about network problems, and the tech with the substitute modem 10 days ago didn't try any pings or tracerts.
Yeah, which means that it won't get solved until other customers run "ping -t" and discover the same problem - which is unlikely. This is not the first or second or third time in which I've had to diagnose a system problem for a utility company, and it's hell to convince them that I've really spotted something.
I once noticed noise on my car's AM radio whenever I drove past a traffic intersection. This went on for about six months, but phone reps didn't know how to write up a customer's report of their own failing equipment I finally spent a couple days networking by phone through the power company, and I finally got an engineer to look into it. A week later he called back and said that it was a failing transformer, and the final outcome could have been an explosion.
You won't see either of the cablemodem's interfaces IP addresses in any traceroute as the cablemodem is just a bridge. The 10.x.x.x IP address you are likely seeing is just another of the many aliases of the CMTS. (Or it could be some other router still within the cable company's network.)
I've again asked the RoadRunner Tier I Nat'l Help Desk what that IP address represents, and after checking with someone else, the rep said that it was the modem. (Not that Tier I actually knows something, but it would explain why pings to it were always returned.)
OK, to make a looooong story short, I've substituted a Terayon modem from Time Warner in place of my Motorola SB5120, and surprise - no timeouts! With more than 200 pings sent to various servers, not one lost packet. With my 5120, I was getting sometimes up to 20% lost packets, usually somewhere between 5% and 10% - which RoadRunner Tech Help said was normal and to be expected.
The speedtest at Speakeasy seems to have crept up a little bit (from 5.2 to 5.6 Mbps), but the speed at DSL Reports seems to have gone *down*. But the speeds reported vaied so randomly that I really don't know if the speeds were affected at all. Now I wonder if there was really something wrong with the Motorola or whether the parameters downloaded by RoadRunner were wrong or just a bit off. I was under the impression that the Motorola Surfboard 5120 was top of the line, and now I'm disappointed to think that I may have gotten a lemon.
The new modem has likely caused you to be put on a different node or lasergroup. So was the problem the modem, or the CMTS? You aren't really in a position to tell.
Based on everything that has passed, I would say that you had multiple, unrelated problem -- at least two different problem. As for cause and effect, well, there have been just too many variables to do more than speculate.
Heh... Yikes. I certainly wouldn't be very happy with a provider that only successfully delivered 90-95% of my packets on the first try.
As for the speed numbers, I wouldn't obsess about them or the differences because as you said, if you have fantastic download speeds according to one speed test, but are consistently seeing 20% packet loss at certain times, it's like having a car that has 400HP engine, but only will pull away from the traffic light 80% of the time.
How long did you have it? How's the weather been since you got it? It may have soaked up one too many power surges and started failing..you never know. Or as another poster correctly suggested it's possible that your new modem being activated perhaps masked the problem via other channels. it's hard to say.
Glad you're in happyville though with the new modem. These intermittent packet loss problems are a pain in the ass to get resolved and I'm glad you got where you wanted to go.
I asked again, and now the rep says (after consultation) that the
10.x.y.Z IP address belongs to "the thing which puts you on the Internet, the thing near the servers, not in the neighborhood". So it remains a mystery why my "lossy" Motorola SB5120 wouldn't drop any packets at all when pinging that 10.x.y.z thing and would drop lots of packets when pinging nodes upstream of it.
*TimDaniels*
While it is true that, in many people's opinions, the Motorola surfboard is top of the line, there can be a lemon found anywhere. It is also possible (I think more likely) that the config file somehow became corrupted and when the new cable modem was installed and provisioned, the file was completely rebuilt and the Terayon got the correct config file.
Speedtests through DSL Reports are always slow for me as compared to speedtests directly to the same server.
Your signal-level issues and your packet loss issues were completely unrelated, and your modem was not a problem at all.
The 10.x.x.x address could not have been your modem because your modem is just a bridge, and the IP address of a bridge will not show in a traceroute. It is, as I said before, one of the addresses of one of the interfaces on the CMTS. It is your gateway. Your network configuration (or your router's configuration if you're using a router) likely shows a different IP address as your gateway, but it would be the same device.
Despite any signal-level issues you might have been having, you weren't having any packet loss to the gateway. In other words, even though your modem had to yell too much to communicate, the messages were all getting through. As noted earlier in this discussion, a signal-level issue could have an end result of packet loss, but there is no direct coloration between signal-level and packet loss.
The problem causing your issues has not been solved. It only no longer affects you. There is still an interface on a CMTS that is not functioning properly out there. You're just no longer connected to it because of your modem swap. Or maybe, by some coincidence, someone fixed the problem already, too. We don't know. We don't know what network engineering was looking at or doing at the same time your modem swap was being done. The assumption that your modem swap was the only thing happening at that point in time is fundamentally faulty. There could have been a lot more going on behind the scenes at the same time.
So when it comes down to the bottom line, all you can do is speculate as to what was happening. Enough variables have been changed to resolve your issue. You only know about some of the variables that have changed. You found a number of problems along the way, but there is no logical reason to make an assumption that any of those problems were related. Trying to mold some explanation that ties these problems together is an exercise in futility.
You're also expecting customer service to give you far more information than they are trained to understand. And it's all irrelevant, too. Does it really matter what that 10.x.x.x address belongs to? The customer service agent's job is to determine if a problem is something on your end that can be resolved over the phone. And if it's not, is it a problem that one of their techs need to be dispatched for, or something unrelated to the service. That's it. They don't need to know what that 10.x.x.x address belongs to. A tech in the field should have some concept of what it is, but only in the sense that it may have something to do with a problem that they need to pass on to someone else to look at. So if you're relying on customer service to give you technical information, you're not understanding their purpose. And now that the issue has been resolved, you're just wasting their time drilling them for irrelevant information.
You had an issue. During troubleshooting, multiple problems were found and fixed. Those multiple problems were not related to each other. Other variables may have changed due to actions that you have no knowledge of. Those actions may have been taken as a result of troubleshooting your issue, or those actions may have been taken for some unrelated issue. The bottom line is that you no longer have an issue.
There is no need for a huge conference to uncover just what combination of events were most relevant in this one particular case. This alignment of the stars will never happen again. Next time there will be some other alignment of the stars that may result in similar issues. Solving those theoretical problems in the future will not be facilitated by knowing what happened this time. That theoretical future problem will best be resolved by methodical troubleshooting, and fixing each problem found during that troubleshooting. How your mystery problem was solved this time is irrelevant to any future issues.
And that's also why it's so infuriating to hear, "I had the same problem, and I solved it by this obscure action." Each issue has different variables. Each issue should be methodically troubleshooted. Applying random "solutions" that worked for someone else who had an issue with similar symptoms is a waste of time. And thus trying to do a full inquisition into the minutia of this problem that no longer exists is just a waste of everyone's time. The problem is resolved, and future problems won't be resolved faster by abandoning methodical troubleshooting of the unique situation.
What nags at me, Ed, is that the pings with the Motorola to the CMTS were without any lost packets at all, but that pings to nodes upstream were losing packets. That doesn't sound like a modem problem to me, but Road- Runner Help Desk is so understaffed due to the holidays, that they require a couple hours in 2 different queues even at *midnight* Pacific Time to reach someone who can provision a modem. I guess I'll have to wait until next week to check this out further.
I concur. Your data now doesn't suggest a modem issue.
But your problem is fixed. The rest is an academic exercise, which in my experience with the lowest common denominator types you usually get to talk to at cable companies makes an academic exercise an extremely fruitless effort.
You're probably right when you say they're seriously understaffed, and you're probably right when you said in a previous post that your problems seem to be fixed, so why would you consider wasting their time trying to determine a cause?
As Warren said, there are too many variables involved, some known and others unknown, to be able to pin down a cause. Just enjoy your new service and let the dust settle on all of those promises you made about leaving for DSL. :)
The problem is solved. Let it be. There's no need for an M&M conference -- especially since the patient lived, but if you want one, it's not going to be brief, nor will it be conclusive.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.