Thank you, Warren, but I do not believe he meant that I have a bad attitude. My reading of his post indicates he is ascribing that attitude to the Comcast folks. But, maybe not ; ))
This problem is as perplexing as I've ever seen, and I've been around networks 5-6 days a week for the past 7 years. At this point, several facts stand out:
- the internet is down every morning
- when I cannot ping the gateway address remotely, the modem shows online in Comcast's equipment and their constant ping shows no or very little packet loss
- when they "poll" the modem with their software, as I'm on the phone with them, the Netgear wakes up and in mid execution my pings start getting replies and internet service resumes (this one really makes me shake my head)
- within the past couple of months, the client's domain has turned up on some ISPs blocked list as possible spammers
I'm now a bit confused as to what information I've included in what posts, but I can elaborate on that last fact if you think it might bear on the problem.
I'm leaning towards going back to the idea of disconnecting their systems from the network, and just connecting a clean PC, and seeing if the problem appears under those conditions.
I think you've stumbled upon an interesting thing with the rogue connection to send e-mail. I wonder if there are other processes running, too.
Frankly, I'm running out of ideas, but if you can't unequivocally show that the problem is with Comcast, switching to DSL may just be a futile move.
IOW the Netgear modem has an IP address from your house and cable company AND has a completely different IP address from LAN - subscriber's computer. Subscriber may ping to 192.168.1.1 to 'see' the modem. You may use 216.123.456.23 to ping same modem from other side. As I now understand your statement, ping works from both sides or fails on both sides - simultaneously. Is that correct?
Again, cable techs only do what they have done previously. Therefore, did they run a wire directly from that Netgear, out the window, and directly to their cable? Typically they don't do it because it was never necessary previously. Therefore it is one of the first things I do. Part of breaking a problem down into parts and then testing those separated parts.
Same concept applies in this paragraph. If grounding is not verified visually, then a new machine in a nearby other building or distant utility load changing early every morning may create current loops in this building. Why must all incoming utilities connect to the same ground? Among different things performed by a ground so that electrical problems in other buildings do not adversely affect your signals. And since inspection takes only minutes, it is usually one of the first things we look at - when technicians are totally confused.
Why is grounding important. Well grounding for safety is understood by electricians. But that grounding also does things that electricians typically need not understand. Electrician is a technician who is carefully trained into how to respond to code. Ask an electrician how to lower impedance in a wire? He would not know. He knows what meets code. But can he explain why that ground would eliminate radio frequency noise from a neighbors new machine? To know that, he would have to learn things beyond what is in code books.
Comcast is better than most cable companies. For example, Comcast trained their installers to make that ground connection. But there are still bad installations out there that can only be found by visual inspection. Improper grounding may, for example, cause rare voltage spikes to saturate an RF amp. Does that make sense to you? Does not matter. Checking grounds are an automatic first inspection when strange things are occurring.
My experience is that cable company does not read meter's analog numbers - the decibel numbers. They simply say an IP address responds
- therefore modem is 100% OK. - a GoNogo test. But in a real world, something can 1) respond when signal is sufficient, 2) not respond when signal is way too low, AND 3) respond when signal is too low. This world is ternary. That third state is only detectable from signal strength numbers - both incoming and outgoing - and read from modem. Assume numbers to be read by Comcast are intermittently insufficient. They must read and be able to tell you what outgoing and especially what incoming signal strength numbers are at any moment. Are they reading signal strength? Well when signal strength is too low, then Comcast would not see it. They would only see numbers when numbers are sufficient. Just one example of why I posted:
If their answer is 'it is good', then you want to know 'how good'. Any answer without numbers reports nothing useful. No numbers is symptomatic of Go-Nogo testing such as ping. Ping would not report the third of three states listed later.
When your signal strength drops periodically (due to noise bursts that a missing ground would have eliminated, or due to periodic frequency shifting, or interference from a neighbors TV, etc), then what will a remotely located cable tech see? Nothing useful because bad numbers cannot be read remotely when modem has temporarily failed. An intermittent failure due to a missing ground, an improperly routed cable wire inside the building, etc.
Moving on, if Netgear completely stops responding to pings on both sides and restore on both sides, well, then who is sending a master reset to the modem? Does he know his test sends a master reset? Yes, techs do try to solve to the best of their abilities. But how many know (for example) why proper grounding is essential - what it accomplishes? Many techs know "When this happens, then we do this." Therefore many techs don't know what a "we do this" actually does. Or whether a DOSCIS signal can cause a modem to perform a master reset.
Every tech does the best he can. But how many are actually familiar with the DOSCIS standard? IOW they do the best they can which is "when this happens, then we do that". Why? Not relevant to many techs which is why, for example, a tech might never understand the long list of reasons why all incoming wires (AC electric, phone, cable) must be grounded to a common point. Also would not know why many electricians also do not know all the reasons for a common ground.
Moving on again. Modem is down on this morning. What happens when the modem is power cycled - meaning even power plug is completely disconnected and reconnected. Does that restore the signal? Does that permit ping to occur from both sides? Does that restore signal strength? IOW does modem start working - respond to pings from both sides when a power-on master reset occurs? OK. Does Comcast reset it from a remote center. Does power-in reset also do same? (again this assumes only two possible conditions: modem is both side locked out and both sides functional.)
What from the subscribers (LAN) side could cause problems? Well I am limiting this to answers that only explain a crashed modem on both LAN and Comcast sides simultaneously. For example, a mismatch in twisted wires for an Ethernet cable could cause problems - but typically not crash the modem.
Electrically, a voltage must be so high to overwhelm galvanic isolation inside that ethernet port - such as static electric discharge from a human. Or noise frequency must be sufficiently high. I am not fully familiar with the Netgear modem (and could not find that necessary status page that I believe Comcast intentionally did not provide). Therefore I am not aware of any simple command that can lock out ports without some complex human interaction.
Only LAN side event I know of that can lock out the entire modem? Excessive voltage spike. BTW, same could happen on cable side of modem because cable wire was not properly grounded.
Doing the same test as should have been done on cable side of modem. All LAN cables, except one, would be disconnected the night before. Is modem locked up that morning? Or temporary cables are routed through doors and hallways. When not using orginal LAN cables, does modem no longer lock?
Or just disconnect everything since he has his Linksys router in there now and that should suffice for the local LAN side to take pings and such.
Way too early for that I would think.
What happens late/early in the morning that could be a factor ? Cold, humidity maybe ?
What time were these suspicious emails going out and what time do the failures occur ? Why would data content bother a modem/router ?
Has any of the infrastructure been swapped out yet besides the modem/router (wiring, ground block, splitter, etc) ? What are all the components currently in the path to the pole ?
Yes, I was planning on doing that tonight, but I didn't make it down. My only reservation about this is that if I turn off the LAN equipment (except for the Linksys) and the modem does not go down, what does that prove? It would seem to support Comcast's assertion that the problem is on the client's side, but, on the other hand, is it defensible that a modem should only work when no traffic is going through it?
With respect, it's not "way too early" for the client who has been dealing with no internet access every morning for 3 weeks. They are running out of patience. And a significant challenge is that much troubleshooting is required, but I cannot work on it every day, and for the most part I'm all they've got.
Perhaps, but the fact remains that this internet connection has been working fine for years.
I can find no definite relationship.
The heart of the question, as far as I'm concerned. Comcast has suggested that the activities of our mail server is causing the problems. And I continue to repeat your question: What bearing does content and traffic in general have on the performance (or lack thereof) of a cable modem????
Have you checked for any snmp packets headed to the modem?
Most modems can also be controlled through an http interface showing to the LAN side.
Can you get to any of the modem logs at 192.168.100.1 ? How about
192.168.1.1 ?
If we could see the modem logs, we could see why it's going down. Or for that matter, confirm that it's the modem that's going down.
Just to review, and make sure we've been talking about all the same things, is this how things are set-up:
Various Computers on the LAN | V The "Server" (which is acting as a router for your LAN, and is assigned your public static IP) | V The Netgear, which includes a cable modem, and has routing capabilities that are turned off. | V The CMTS at the headend, which has the gateway IP address for the static IP used by the server) | V The rest of the world.
Numerous times you've mentioned being unable to ping the gateway. Are you talking about the CMTS at the headend, or some other device. And where are you pinging it from? The client's side of the modem, or where you are in the outside world?
You've also mentioned pinging the modem's IP. A cable modem has a class A private range IP address facing the HFC side that the provider can use to manage the modem. That 10.x.x.x address is only going to be accessible from within the Comcast network. The modem also has an internal http server (to serve pages with logs and status information) that's accessible only from the LAN side. It has a class C private range IP address (192.168.100.1). All other traffic is bridged through the modem.
If the routing capabilities of the modem are turned off, then all you've got left is the switch that's between the modem part of the Netgear, and the Ethernet port. So if the routing capabilities are turned-off, there's no IP address used for this side of the Netgear.
All in all, at this point the modem logs would probably be the most useful tool we could use.
The modem is not set up this way. There are two IP addresses associated with our account: a "gateway" address, which is a Class B ISP address allocated to the cable modem (in this case a Netgear); and a static IP address, a Class B ISP address that is allocated for the customer premise equipment. With RoadRunner/Comcast standard business accounts, the customer gets one public routable "static" address. So, faik, the only ip address the Netgear "knows" is the gateway address.
That's the thing: Although I have not actually seen the modem logs, Comcast support says the modem logs (historical data) is not reflecting the outages. In fact, when I cannot ping the gateway address (and the internet service is not functioning), the Netgear will show to be "on line." They can be in it, which they are, because they reset it - then the internet starts working again.
That was the config until last Tuesday, when I placed a Linksys "behind" the Netgear. So, from the client side -> out, it looks like this:
Various computers on the LAN (how did you do that straight up-and-down line ????) V Network switch V Linksys V Netgear cable modem/router V Comcast headend equipment
When I say "ping the gateway," I'm talking about the gateway IP address Comcast assigns to the Netgear, i.e, 24.xx.xx.30 (the static IP, which now is assigned to the Linksys WAN port, is 24.xx.xx.31). There is another IP address used by Comcast to access the Netgear (I belive it's a 73.xx.xx.xx address), but they do not refer to it.
I am pinging from my office, which is about 20 miles away. A typical series of events goes like this: approx 8:15 a.m., someone from the firm (my client) calls and says the internet is down and can't send/receive email. I immediately try two things from either my laptop or my main work machine, both running Windows XP Pro: log into the Linksys at the client site using a web browser (I have remote GUI mgmt enabled, which I access via static IP address:port I've chosen); and, ping the Netgear using the gateway address. Both attempts fail. Then, we do one two things: either have someone on site to power recycle the Netgear, or (much more commonly) I will call Comcast and tell them the problem has returned.
It's at this point that things always get sideways. Invariably, Comcast pulls up the client info and informs me that their "constant ping test" shows no failure, no packet loss, and the "historical data" shows the Netgear to have been online for days, with perhaps a minute or two "interruption" here and there. I ask them to explain to me why I cannot ping the gateway address, and depending on when I call, to whom I speak, and the specifics of the incident, I will get various replies. The general stance is that they do not know why. It must be a problem on our end. After all, they changed out the Netgear twice, their monitoring reveals no problems, and all the critical measurements are within spec.
During business hours I get the local support team (the former Time Warner RoadRunner group). The two techs I've spoken to the most "explain" the problem in slightly different terms, but the general stance is the same: Since we cannot identify a problem on our end, it MUST be on your end.
And here's the most disheartening part: Even if we eliminate every possibility from the client side, Comcast still will not have a solution.
I did not realize that a modem configured for static IP/bridge mode still retains a Class C private address. I will try that later from within the client's network.
Ah, okay, that's what I was going to ask: Where does that private IP come from?
I asked about this today, but the tech said it wouldn't do any good. According to him it just shows the modem being online.
I'm an extremely persistent person - some would say obsessive. But I'm growing weary with this thing.
Not sure why you can't just look at the logs on the modem. Comcast usually doesn't lock-out the customer from this function of the modem.
If the Netgear has a public IP address, it must be assigned to the router portion of the equipment. And if that's the case, it's not operating as a bridge or a switch, it's actually operating as a router. And if it's operating as a router, the nature of the traffic coming from the LAN can affect how it operates, as the metaphoric envelopes nested in the packets are opened, as oposed to just passing the packet through like in a bridge.
Okay. Now this is starting to make a little more sense.
The *cable modem* in the Netgear has probably been operating perfectly. (Or as close to perfectly as practical.) It's not the problem. The problem is happening in the *router* part of the Netgear. Although this part may be in the same physical box as the cable modem, it's not normally something that is monitored on an HFC cable modem system.
The cable modem part of the equipment is *always* a bridge. It's the router included in the same box that can be configured differently. But if it has a public IP address, it's not operating as a bridge. It's operating as a router.
There are two private range IP addresses associated with most DOCSIS cable modems. The class A is assigned to the side facing the HFC network, and is used by the provider to manage the modem. The class C address, usually 192.168.100.1, faces the Ethernet side. With the right firmware, it could also be used to access the modem to manage it, but rarely - very rarely - is that ever enabled. Typically the firmware will allow you to access status reports and logs which will be served via http.
I tend to believe that now.
It sounds like the problem is in the *router* part of your combination cable modem-router. And it may not be so much a problem with the router not acting as intended, but a problem with what's being sent to it from the LAN. Something is locking-up the router part of the Netgear, not the cable modem part of the Netgear.
I know you aren't going to have any access to manage the cable modem part of the Netgear, but how much access do you have to manage the router portion of the Netgear?
Since you've had three different Netgears, and they all act the same, replacing the hardware again probably won't make a difference. There may be a setting that can be changed that will change the way the router acts, but then the question is why was that setting configured the way it is, and not the way that resolves the problem. What was it designed to do?
So even though there may be a setting that can be changed in the Netgear router, that may not be the correct fix. The correct fix may be to find out what it is that is being sent to the router to cause it to crash.
This differs from the question of what's being sent to the modem to cause it to crash. Nothing should cause a simple bridge to crash. But we're not talking about the simple bridge of the modem crashing. It seems that the modem is working correctly. It's the more complex router, which is operating at a higher level on the OSI model that's crashing, and it's not unheard of for a router to crash in this way. It's not just passing the packets. It's partially opening them.
So what's in those packets that's causing the *router* (not the modem) to crash?
That's my diagnosis. But in this case, the treatment goes beyond my level of training.
Would going to DSL solve the problem? Depends on what kind of equipment they give you. If they give you a combo modem/router, and that router has the same hardware or the same settings, it probably won't solve the problem. But it's also possible that it could remain a problem with different routers, too because switching the modem type, and the network it's attached to is just changing things on the wrong side of where the problem is.
I wonder if Netgear has a modem similar to the one he has but separate from the router ? If so, maybe he could swap the modem-router for just a modem and use his Linksys for the router and see if there's a change.
What's the model number of this Netgear m-r ? I'm guessing it would have to be a CG814CPR or similar.
I'm still having problem with that stmt a while back that says they have to use this specific modem-router and nothing else could possibly be configured (or some such). There's got to be similar but separate hdw that they can configure - like a separate Motorola/Linksys modem with a separate Linksys/Netgear router.
For residential service, Comcast will allow you to use your own modem. It doesn't work that way for business service. I'm sure that's mostly a business, not a technical decision on their part, but there could be some technical reason that I'm just not aware of.
So a different modem (or modem/router) is a step that Comcast has to be willing to take in this case.
Looking at what some Netgear modems report. They don't report signal to noise ratios - therefore Comcast remote centers may have no such data contrary to what others have implied. These modems do report a count of packets transmitted and received along with another important number - data that counter is reset. Therefore if e-mail was causing a problem, then number of packets transmitted would be excessive and obvious.
These are numbers that a tech could provide if he has them. But again, important numbers that might show a problem are still unknown because numbers are not being provided AND what the tech uses to say problem does not exist - both are unknown.
There is no acceptable reason why status information is denied the subscriber.
Meanwhile, Warren H's explaination - what the various IP addresses are - should be obvious from client machines using IPCONFIG and TRACERT commands. If problem is only on the router side, then various computers on client side cannot ping each other. That test result also was not reported.
Also not defined is whether modem is in router mode or bridge mode.
He's using the server as his LAN router. The Netgear router isn't routing in the lay sense of the word. That is, in the topography of his network, it's not directing traffic here or there. It is only sitting there between his server (which is the real router on his LAN), and the cable modem, but it's opening packets, and repackaging them as a router does, and not simply passing them through as a bridge would.
I can't find a model number for the piece of equipment, but giving this more consideration, I don't think it can actually be configured to be a bridge. I believe that it can only act as a router. It can act as a NAT router, or it can operate as a normal router. Not normal in the same since as a "home" or "broadband" router, which normally acts as a NAT router, but normal as in it routes packets to various public IP addresses. In this case, there's only one IP address to route to, but that doesn't mean the equipment stops opening packets like a router does, and turns into a bridge that doesn't open packets. (Remember that a router and a bridge operate on different levels of the OSI model.)
Also, if it were just a bridge, there's no ISP that's going to waste a publicly routable IP address on it. As a bridge, it's IP address would only be useful for managing the equipment, and would not be a part of the path through the device. For that, they'd use a private range IP address just like they do for the cable modem.
The more I think about this issue, assuming that everyone is reporting honestly, my confidence that it's not the cable modem, and that the failure is happening because something is crashing the router part of the Netgear box goes up.
There's a switch in there and another router now, so that shouldn't be happening. There may also be a switch on the Netgear ???? Still don't know the model.
Right. If there's more than one Ethernet port, there would be a switch involved. But a switch operates on an even lower-level than a bridge, so the chances that it's a switch issue is low. And since the most likely switch-related issue would be the physical hardware, since three different Netgear boxes have been used, it's not likely that they all had the same physical defect.
I was referring to the fact that if there is a switch, the packets from the LAN may not even make it to the router portion. Therefore, no local LAN pinging problem could exist. And we know there's another switch farther in that should allow the local PCs to ping each other without a router getting involved. This in response to Tom's pinging stmt.
I just want to thank everyone for their time and effort. I sincerely appreciate it. Really. I'd be totally on my own without this discussion.
Correct, with the addition of a Linksys WRT54GL between the LAN switch and Netgear.
It's a Netgear CG814CCR v2. I'm sorry. I thought I provided this a long time ago, but I did not.
This is how I understand it.
That's correct. There is no bridge mode in play here at all. That was a terminology error on my part.
I've been 100% honest, although I can't say for sure I've reported 100% of the pertinent information. I've done my best, but I've spent a tremendous amount of time with this issue. If I'm leaving something important out, it's simple oversight.
As for events since I posted last: Last night I logged into the Linksys and disabled outbound traffic from the server. I put a 24/7 block on the server's internet NIC. This morning at 7:50 the Netgear was unresponsive to ping from my office.
To me, this is compelling information, although I'm not sure how to interpret it. Does this demonstrate definitively that outbound server traffic is not the root cause? Did my block indeed prevent all packets from reaching the Netgear? I seems so. Am I missing something?
Next I want to completely turn the server off for the night. This takes some doing, because we back up data at night, and I do not have complete access to the building. But I can arrange it. Then, depending on the results, I want to disconnect everything from the Netgear except one clean PC.
I'm not sure what else to try.
Also, what information exactly should I request from Comcast? A text file containing the router logs?
I know you don't have any access to configure the modem part of the Netgear, but do you have any access to configure the router side?
If not, or if unknown, try these ideas: From the customer's side, use a web browser to access 192.168.100.1, or 192.168.1.1, 192.168.0.1 or
10.1.10.1 the public IP address assigned to the Netgear, or
formatting link
If a login/password screen comes up, try cuadmin / highspeed . I would advise not changing any settings, but rather just look around. There is probably a "blocked services" (or similar) menu, and there should be an option for setting a schedule.
If you find that the router has been configured to block services based on a schedule, any Comcast didn't give you the ability to manage the router, then call them up, and talk to them again about this situation. When they've said that the modem doesn't go into sleep mode, they may not have been thinking about what the router can/can't do, and they may not have thought about it's ability to block services on a schedule. In other words, if they were focusing on the modem, they may have overlooked the anything dealing with the router. On some level they probably realized it was a combo unit, but they may not have made the cognitive connection correctly.
If they claim they can't manage the router, ask them to send a tech who can.
If you are able to look at the router configuration, and you find there's nothing there that should be a problem, then we've reached a huge stumbling block. When you shut-down traffic from the server to the Netgear, that should eliminate the issue of traffic from the LAN crashing the router. And if Comcast has been honest about the modem logs indicating that the modem side isn't going down, then we've isolated the problem to the router side of the Netgear. And since multiple Netgears have exhibited the same problem, it seems to point towards a configuration problem on the router side of the Netgear.
BTW... Did you make sure that when they replaced the Netgear they also replaced the power brick? And have you confirmed that it's not on a circuit that could be experiencing a surge or brown-out condition during the time in question? If not, those, and not the configuration, could still be an issue.
Either way, assuming that Comcast is being truthful about the modem side not going down, the problem has sufficiently been isolated to the router side of the Netgear. If they haven't been truthful about the modem status, then the problem could be further out on their side.
If it were me, I'd be asking for a separate cable modem without a router. Then use your Linksys as the router. There's no logical reason why they can't provision another modem model. If that works, then I'd ask them for a separate router too if they're supposed to supply one on a bus. acct. unless of course you don't mind using your own.
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.