Koozali.org: home of the SME Server
Contribs.org Forums => General Discussion => Topic started by: edb on March 05, 2008, 04:11:44 PM
-
Hi
Was hoping that maybe someone would have an idea as to why I periodically have long ping times given my SME setup.
I have my SME server in gateway mode on a Sonicwall 2040 - DMZ port with a public IP and a private IP on the internal nic.
Things work great one minute and then the next minute our branch offices which are running over the Sonicwall VPN are slowing down to a crawl with ping times over 2000+ms which are ordinarily about 48ms.
If at the time this is happening I reboot the SME server the ping times quickly return to 45ms again but when the server comes back up it is back to the 2000+ms again. Sometimes this last for a couple of minutes and sometimes it lasts for an hour or more.
For those who are familiar with Sonicwall firewall setups it is configured in transparent mode.
Could this be a chatty NIC that needs replacing? I have even lowered our MTU size on the Sonicwall to 1404 but no change.
Just looking for ideas if anyone has any for this particular issue. Really weired.
edb
-
Hi
Was hoping that maybe someone would have an idea as to why I periodically have long ping times given my SME setup.
I have my SME server in gateway mode on a Sonicwall 2040 - DMZ port with a public IP and a private IP on the internal nic.
Things work great one minute and then the next minute our branch offices which are running over the Sonicwall VPN are slowing down to a crawl with ping times over 2000+ms which are ordinarily about 48ms.
If at the time this is happening I reboot the SME server the ping times quickly return to 45ms again but when the server comes back up it is back to the 2000+ms again. Sometimes this last for a couple of minutes and sometimes it lasts for an hour or more.
For those who are familiar with Sonicwall firewall setups it is configured in transparent mode.
Could this be a chatty NIC that needs replacing? I have even lowered our MTU size on the Sonicwall to 1404 but no change.
Just looking for ideas if anyone has any for this particular issue. Really weired.
edb
To me this sound like a conflict somewhere in your network.
Are there perhaps multiple systems providing DHCP to your network. Normally a gateway priovides DHCP and SME Server does (if you say so during setup) as well, you can not have two servers in the same subnet handing out DHCP addresses.
I suspect you configured your SME Server to hand-out DHCP addresses (and your Sonicwall is doing so as well). If so you can resolve it by login at the terminal as admin and choose the option reconfigure your server, disable DHCP in one of the screens and see if this changes anything.
A schematic drawing of your network would help to better understand your situation as you know a picture says more than a thousand words. :-)
-
Hi Cactus
I don't have DHCP enabled on either the Sonicwall or the SME server all my addresses are static.
If a picture is worth a thousand words then here goes ...
(http://i263.photobucket.com/albums/ii152/edb5/networklayout.png?t=1204739064)
Like I said the layout works fine most of the time but usually 3 or 4 times a day it will slow down to a crawl for a few minutes and then even out back to normal again. It must have something to do with the SME server only because when I down the server the network and VPN connections immediately recover back to a normal state.
When the SME server comes back up ... it slows to a crawl again but eventually it returns to normal operation again. It is really quite odd ...
edb
-
Nice picture :-P
It looks like you have couple of routes for testing.
1> does local lan to SME private lan IP also slow down on pings?
2> does local lan PC to a branch office PC or Server slow down?
I like to use Colasoft's ping tool on a windows machine to troubleshoot these. You can ping multiple addresses at once and see at a glance on the graph if certain addresses are slower then others. The addresses I usually run are as follows,
My workstation to:
1> local file server or pdc
2> LAN internet gateway
3> ISP's closest internet gateway to me
4> google.com or other reliable WAN target
5> targets across various VPN tunnels
I then use pingplotter to watch which hop is causing trouble if I have one route that is not working correctly. (pingplotter does not help on my tunnels as all of them show as just one hop)
It sounds suspiciously like hardware to me (nic on server, switch port or could be a nic on a workstation.) That is assuming this was a stable situation that has just now degraded.
-
edb
Your pic show's a hub, if in fact it is a hub I would suggest that the hub be changed out to a switch
especially with all the VPN traffic you have.
-
edb
Considering your network arrangement, my thought is that your problem could be local DNS issues.
Your network devices are getting conflicting/wrong information about which device is handling DNS requests from your network.
So what device is configured as the DNS server for your network ?
Are your workstations configured as such ?
-
We had a similar problem at work and found that someone :x was using a torrent to download personal content. So much for rules. It was intermittent in nature and was frustrating to solve. As I recall, the isp said that uploading at the limit caused an issue with the service and slowed the download. Something else to check.
-
edb
Your pic show's a hub, if in fact it is a hub I would suggest that the hub be changed out to a switch
especially with all the VPN traffic you have.
Yes, it is a switch not a hub. Thanks
-
edb
Considering your network arrangement, my thought is that your problem could be local DNS issues.
Your network devices are getting conflicting/wrong information about which device is handling DNS requests for your network.
So what device is configured as the DNS server for your network ?
Are your workstations configured as such ?
Thanks Ray, I'll consider that ... right now DNS is provided by the Windows 2003 DC server for both local DNS and Internet DNS lookups. Workstations are set up with DNS pointing to the Windows 2003 Domain Controler.
thanks
-
We had a similar problem at work and found that someone :x was using a torrent to download personal content. So much for rules. It was intermittent in nature and was frustrating to solve. As I recall, the isp said that uploading at the limit caused an issue with the service and slowed the download. Something else to check.
Very good point imcintyre, I will have to search that out and find a way to block it just in case or do some software inventory analysis to find the culprit. ;)
-
edb
... right now DNS is provided by the Windows 2003 DC server for both local DNS and Internet DNS lookups. Workstations are set up with DNS pointing to the Windows 2003 Domain Controler.
You didn't mention a Win2003 server anywhere !
Where is it connected ?
What is the role of your sme server ?
Is your sme server configured to get DNS from your Win2003 server ?
-
I like to use Colasoft's ping tool on a windows machine to troubleshoot these. You can ping multiple addresses at once and see at a glance on the graph if certain addresses are slower then others.
I then use pingplotter to watch which hop is causing trouble if I have one route that is not working correctly. (pingplotter does not help on my tunnels as all of them show as just one hop)
It sounds suspiciously like hardware to me (nic on server, switch port or could be a nic on a workstation.) That is assuming this was a stable situation that has just now degraded.
I tried the Colasoft ping tool (very nice) thank you, I didn't know about that one.
Also, think it may be a bad NIC or as imcintyre pointed out it could be a torrent which I checking out now.
Thanks for your input!
-
edb
Aren't you overlooking your comment:
"If at the time this is happening I reboot the SME server the ping times quickly return to 45ms again but when the server comes back up it is back to the 2000+ms again. Sometimes this last for a couple of minutes and sometimes it lasts for an hour or more."
While not directly involved with Internet requests, you could have a browsemaster issue which slows down your network and creates the problem. If sme and your Win2003 server are conflicting with each other and both are trying to win elections, this can cause disruption. Search forums on browsemaster & adjust sme for a lower "os level" value in smb.conf.
-
edb
Aren't you overlooking your comment:
"If at the time this is happening I reboot the SME server the ping times quickly return to 45ms again but when the server comes back up it is back to the 2000+ms again. Sometimes this last for a couple of minutes and sometimes it lasts for an hour or more."
While not directly involved with Internet requests, you could have a browsemaster issue which slows down your network and creates the problem. If sme and your Win2003 server are conflicting with each other and both are trying to win elections, this can cause disruption. Search forums on browsemaster & adjust sme for a lower "os level" value in smb.conf.
Hi Ray,
I did the following just in case this was the culprit ...
config setprop smb OsLevel 30
signal-event workgroup-update
I'll see tomorrow if we have the problem fixed as it sure would be nice. :)
edb
-
You didn't mention a Win2003 server anywhere !
Where is it connected ?
What is the role of your sme server ?
Is your sme server configured to get DNS from your Win2003 server ?
Sorry I missed this message earlier Ray ...
The Windows 2003 Domain Controller is connected to the LAN side only and serves as Data server.
The SME server is in gateway mode for Web/Mail/Ecommerce and does not get it's DNS from the Win2003 server.
If I recall during the setup of SME the DNS is left blank.
Thanks for your assistance
edb
-
Any vlan switches involved?
-
Any vlan switches involved?
No to that question. Thanks
-
Hi Ray,
I don't think the smb browsemaster was the issue.
I rebooted the server just to make sure ... but I just tried a test of downloading a file from the SME over the Internet connection.
Shaw Cable has a test file they use to test download speeds and the file is a 20MB dat file so I put it on my server, started up the visual ping utility suggested by "mercyh" earlier in this thread and started the download from my home PC. I watched the visual ping utility and the ping times went from 45ms to 300ms while I was doing the download.
This seemed odd so I started a second download so that both were going at the same time and now the ping time went to 600ms. Obviously, it seems that the server is being taxed .... if I quit both of the 20MB downloads the ping times quickly return to 45-50ms again.
I don't want to post my website here but if you send me an email I'll give you the url where you can test what I'm saying.
Any comments?
edb
-
edb
MTU 1404 will cause the problems you are having.
Unless your ISP is recommending that setting a MTU 1500 should be used.
For some DSL ISP's 1494 may be required.
Suggest you set MTU to 1500 and reboot.
If your still having the problems then I suggest testing for MTU packet length
and should it be something other the the two settings above then investigate
that with your ISP.
MTU should match that of your ISP.
Using 1404 on a 1500 network will fragment packets forcing client systems to
wait and ultimately timeout when when they receive the 96 byte fragment.
That fragmentation is the latency you are experiencing throughout your system.
The results you have for the D/L & ping test are the exact results one would see on a system
that is fragmenting packets.
As the D/L progresses the timeouts degrade the systems ability to respond to other request i.e. pings.
As a point of interest where was 1404 derived from??
-
Hi electroman00
Here is how I arrived at my MTU size:
MTU is the Maximum Transmission Unit. If the setting is too high packets can fragment and transmission speeds will be poor.
The default MTU is 1500. A DSL connection with PPPoE cannot be above 1492 and the default settings could cause problems. The MTU should be set the same on both sides of your router, the internal LAN (your network) and the external WAN (the Internet).
Ask your ISP for their recommend MTU setting. If they won't give it to you continue reading below. Verizon recommended using 1492 for their DSL with PPPoE, however, our testing showed that 1490 works better.
To find the proper MTU Size you will have to do a ping that tests for fragmented packets. Refer to the ping test, above, to learn how to find your ISPs DNS server address. We will use 12.34.56.78 in the examples below.
At the DOS prompt start the special ping using a value of 1472. Work down in jumps of 10 until the packets are not fragmented. The syntax is: ping 12.34.56.78 -f -l <test value>. Below are results from a sample test.
ping 12.34.56.78 -f -l 1472 <result = fragmented packet>
ping 12.34.56.78 -f -l 1462 <result = fragmented packet>
ping 12.34.56.78 -f -l 1452 <result = reply>
Start at 1472 and work your way down by 10 each time. Once you get a reply, go up by 2 until you get a fragmented packet.
Once you find the proper value add 28 to account for the various TCP/IP headers.
If the value was 1462 adding 28 gives 1490, which is the optimum for your network..
My MTU size was determined to be 1444 as a result of the above tests.
I did however, change it back to a MTU of 1500 on the Sonicwall and we'll see what happens I guess but if I recall this was why I changed it to 1444 in the first place.
edb
-
edb
Your correct 1492.
However you stated 1404 in your initial post....???
My MTU size was determined to be 1444 as a result of the above tests.
That would indicate something is not quite right with the connection.
I would disconnect everything from the modem except one client and retest.
If it ends up being different from your initial test, I would suspect a problem from the router upstream somewhere.
BTW on what client did you perform the ping MTU test, I assume the smeserver or multiple clients or from home?
Also did you ping inside and outside the lan.
Do you know the distance to the ISP hub?
I would venture to guess it's less then a mile these days and with that 1492 should be expected
unless there is a problem somewhere.
As a side note I was going to post this, then I saw you posted the above, but here it is anyway just in case it may help.
Regular Ethernet frame uses a frame format that limits the size of the payload it sends to 1500 bytes. This means Ethernet can't deal with IP datagrams greater than 1500 bytes in size.
Some systems will use datagrams larger then 1500 which is considered a Jumbo Frame and some systems can accommodate those frames.
However I have not seen any ISP's using Jumbo Frames because all of their clients would need Jumbo Frame capability.
The other side of the coin is frames being sent 1500 in size to a system where the MTU is set less then 1500 which will force fragmentation of the frames
and the receiving system waits for the remainder of the frame for reassembly.
Conversely if a system is sending 1492 frames to a 1500 network then the system again waits for the remainder of the frame and on receipt
will reassemble the packets which instills the latency on the receiving network.
All fragmentation is reassembled by the receiving host.
With that it is important to MTU ping test to various points and survey/analyze all the data collected to help isolate the problem.
-
electroman00
Thanks for the reply ....
If it ends up being different from your initial test, I would suspect a problem from the router upstream somewhere.
I am starting to think it must be the Shaw Cable upstream gateway router
BTW on what client did you perform the ping MTU test, I assume the smeserver or multiple clients or from home?
I did my testing from home but I have come up with the same results testing from work.
If I use the method in my last email to come up with the best MTU size I ping over my VPN links and get the same results. I get a successful ping response at ping 192.168.50.50 -f -l 1418 but at ping 192.168.50.50 -f -l 1420 I get "Packet needs to be fragmented but DF set." so according to the formula I would take 1420 + 28 = 1448 as an optimum performance.
I still have it set back to 1500 for right now.
Also did you ping inside and outside the lan.
Yes. I get the same results when I ping xxx.xxx.xxx.xxx -f -l 1420 the WAN interface of the SME server or www.google.ca or the local LAN interfaces.
Do you know the distance to the ISP hub?
We are right downtown so I don't think the gateway router is even a mile from us.
The other side of the coin is frames being sent 1500 in size to a system where the MTU is set less then 1500 which will force fragmentation of the frames
and the receiving system waits for the remainder of the frame for reassembly.
Conversely if a system is sending 1492 frames to a 1500 network then the system again waits for the remainder of the frame and on receipt
will reassemble the packets which instills the latency on the receiving network.
All fragmentation is reassembled by the receiving host.
With that it is important to MTU ping test to various points and survey/analyze all the data collected to help isolate the problem.
Yes, I agree ... but I'm still scratching my head over this MTU aspect.
edb
-
edb
I'm a little confused here.
Home and work both dsl?
What modems are being used?
Also without a doubt, cable... like in RF (RG6) cable tv & internet should be mtu 1500.
Cable doesn't have the datagram header issue like DSL.
I have Brighthouse Cable here and in fact the tech just left here.
There was a considerable amount of latency to websites due to packet loss.
Initial test at modem connection showed high packet loss.
So we went to the demark and tested and all was fine, no packet loss.
110 ft wire to computer modem became suspect, so we retested at the modem connection.
No packet loss on the retest, so it looks like the connection at the demark might have been a little corroded
causing a bad connection on the shield.
It doesn't take much of a bad connection with RF cable to have me notice a problem.
My D/L bandwidth drop was about 200kb average and latency to sites very long and
the modem would drop off line several times a day due to 43000+ flaps a.k.a line resets.
If flaps get severe the modem will drop off line on a soft reset.
Sometimes it required a hard reset to bring it back online.
That was the issue the last couple of days here.
Also had them install a brandy new out of the box modem.
Things are sweet again here, everything seems to be back to abbie normal here.
With DSL things are a little different, but not much.
Packet loss is still packet loss and needs to be rectified as your finding out.
-
edb
I'm a little confused here.
Home and work both dsl?
What modems are being used?
Home and work are both cable and we are using Terayon modems at both locations.
I'm highly suspect that the modem could be my culprit as well in this case so I'll be calling Shaw Cable to come and replace it.
Thanks for all the dialogue electroman00!! You've been a great help ...
edb
-
edb
I'm sorry....I assumed due to the 14xx you were DSL. :sad:
MTU for all cable modems is 1500.
Cable modems use ethernet connection...thus...
Regular Ethernet frame uses a frame format that limits the size of the payload it sends to 1500 bytes.
This means Ethernet can't deal with IP datagrams greater than 1500 bytes in size
and you don't want to pipe anything smaller then 1500 or you will fragment every frames/packet
through the system and your client hosts will be consumed with packet reassembly :smile:
That surely will dog the host system to very low performance not to mention slowing down the entire VPN network.
That certainly fits the problem you were pinging for.
If you set the MTU back to 1500 system wide and you still have ping MTU problems
then it might be
1. Cable modem has a bad upload or wrong bin cap
2. RF cabling terminations
3. Your near or at the end of the distribution chain and signal quality is less then desirable
however still within signal spec.
It would be a good idea to retest...
after a complete system reboot
only a single client connected to the modem
Cable modems have very sensitive transceivers that will adjust performance based on
signal quality.
If signal quality is poor the modem will flap aka soft line reset which may frag packets.
If flaps are excessive the modem will soft reset the line and may go off line and online
by itself.
Under really poor signals the modem may not go online after a soft line reset.
RG6 coax should be checked for penetrations, cuts, splices.
I had them run the coax here unspliced direct to modem (no wall box outlet).
The fewer splices the better.
It has been suggested not to route the modem cable through a signal amp.
I'm not sure I would say don't try that based on what I know.
Without a full explanation it's easier to say "your mileage may vary".
RG6 connectors are 7/16" wrench and you may want to rework/inspect
all terminations, work them off and on and tight, especially the outdoor connections.
A leak on the RG6 shield can transmit RF (radio frequency) signal a 1/2 mile or more.
Thats why cable companies send their magic wand trucks through the hoods to seek
them out and fix or the FCC will give them a spanking.
Any compromise to the coax will also allow RF signals to leak onto the coax creating signal
noise thus reducing signal quality, creating excessive flaps within the modem.
They knocked on my door once, shield connection was bad in a wall box, the techs hand held wand
pointed us right to the box.
He said he picked it up two blocks way in his truck.
As my electronics RF experience is extensive I wasn't surprised.
In fact with a more sensitive detector one could detect that signal leak miles away.
At the point of the shield break the remainder of the cable becomes a antenna for the RF signal.
The SA - Scientific Atlanta modems seem to be the better of the modems cable ISP's use.
I had the modem your using and I had them swap it out for the SA yesterday.
My experience with the SA was slightly better then all the others I've tried over the years.
If nothing else I like the led indicators better, power, pc, cable and data in/out.
The data in/out are extremely beneficial in detecting my sons torrent usage.
-
Cable MTU ping stats here
Pinging [xx.xx.xx.xx] with 1472 bytes of data:
Reply from xx.xx.xx.xx: bytes=1472 time=21ms TTL=62
Reply from xx.xx.xx.xx: bytes=1472 time=20ms TTL=62
Reply from xx.xx.xx.xx: bytes=1472 time=21ms TTL=62
Reply from xx.xx.xx.xx: bytes=1472 time=21ms TTL=62
Ping statistics for xx.xx.xx.xx:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 20ms, Maximum = 21ms, Average = 20ms
Pinging [xx.xx.xx.xx] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for xx.xx.xx.xx:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
One could safely assume there are problems within the system if
MTU result is other then 1472/1473.
This may not apply to DSL, just cable modems.
-
Electroman00
You sure seem to know what your talking about and the information you provide is very useful and appreciated.
I have an appointment for Monday afternoon with the cable company to come and check the cabling and stuff and I will get them to replace my modem at the same time. I told them that when I placed the call.
The fact that cable uses only a 1500 MTU size is something I didn't know but do now!
Here is what I get when I ping even from my home which is also cable or from the office:
Pinging www.l.google.com [72.14.205.147] with 1418 bytes of data:
Reply from 72.14.205.147: bytes=56 (sent 1418) time=227ms TTL=247
Reply from 72.14.205.147: bytes=56 (sent 1418) time=228ms TTL=247
Reply from 72.14.205.147: bytes=56 (sent 1418) time=347ms TTL=247
Reply from 72.14.205.147: bytes=56 (sent 1418) time=224ms TTL=247
Ping statistics for 72.14.205.147:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 224ms, Maximum = 347ms, Average = 256ms
Pinging www.l.google.com [72.14.205.99] with 1420 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 72.14.205.99:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
The upstream router must have a modified MTU setting wouldn't you agree?
Thanks again
edb
-
edb
The upstream router must have a modified MTU setting wouldn't you agree?
No, typically the internet is 1500 and it's not advantageous to set MTU lower then the Ethernet
standard because that would slow things down en route due to the additional packets that would be sent.
Keep in mind DSL is a different MTU game, since we are talking all cable here we'll stay on the cable track of 1500.
As you can see framing can have a fairly profound effect on network performance, so imagine your network times 10 in size and
one device setup with packet/framing inconsistent with the network.
It can take down the best, of the biggest, in a heart beat networks.
Also be aware that a system may have all the correct settings/setup and there's a component within the system
generating inconsistent frames/packets.
It's times like these that I begin to loose that lovin' feeling?
Here's my ping to googlie and as you can see 1472/1473
Pinging www.l.google.com [209.85.165.147] with 1472 bytes of data:
Reply from 209.85.165.147: bytes=56 (sent 1472) time=20ms TTL=245
Reply from 209.85.165.147: bytes=56 (sent 1472) time=20ms TTL=245
Reply from 209.85.165.147: bytes=56 (sent 1472) time=18ms TTL=245
Reply from 209.85.165.147: bytes=56 (sent 1472) time=20ms TTL=245
Ping statistics for 209.85.165.147:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 18ms, Maximum = 20ms, Average = 19ms
C:\Documents and Settings\rph>ping www.google.com -f -l 1473
Pinging www.l.google.com [209.85.165.147] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 209.85.165.147:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
I would suggest at home you just connect with one client to the modem, no router
and retest.
If you can, do the same at work...if you can.
BTW that's what the shaw turkey's will want to gobble at you when they arrive.
Concept is to get things down to bare bones and test, which will make it easier to
diagnose/isolate.
You definitely have a problem, it's now a matter of finding and the above is the
suggested starting point.
It's imperative diagnostic information.
Be sure to reboot all before testing.
Also if you would, MTU ping your router and lets see what that has to offer.
Should be 1472/73.....if not, we would look at the lan side and/or the test client.
If you haven't done so already make sure the sonic is set 1500 and rebooted.
Also if you changed MTU on your win clients, you might need to do some reg surgery.
Check
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
Create a restore point....
Programs > Accessories > System Tools > System Restore
and then...
Run > regedit > Favorites > Add to Favorites
Carefully Copy/Paste the reg line above
Check each interface if more then one.
If you see MTU settings other then 1500 change them to 1500.
Do not add MTU's to any interface, if MTU is not found.
There should be at least one interface with the MTU property.
Prepare for reboot and reboot.
Almost forgot you might have changed the MTU on your Win clients which
could really send us upstream paddling.
I highly suspect the Win clients at this point, due in part to your google results
at both sites.
Your Win clients are one of the commonalities between the two sites.
We need to ensure both are setup correctly.
If you can, check and test.... and let us know.
-
EDB,
Did you ever get this sorted?
Just curious of the resolution.
-
No, not yet ... I'm still working on it with our cable supplier.
The cable modem has been swapped out but no change so the next thing is to test the line from the demark to the modem.
I'm starting to think that I may have to get a T1/DS1 line so that I have the same upload and download capacity.
So far I believe it may be just a case of cable being over-subscribed but I'm still trying to determine the root cause of the severe latency issues.
I will post back here any results as I get them.
edb
-
Well I discovered something interesting with the Colasoft graphical ping tool ...
I went to http://www.speakeasy.net/speedtest/ (http://www.speakeasy.net/speedtest/) and ran a test from any of the servers listed there and I watched the ping tool results as I conducted the test. I have repeated this several times.
What I saw happening was that on the download portion of the speed test the ping times remained stable but as soon as it began the upload portion of the test and until it was over I witnessed complete packet loss (just a big blank space of time on the screen). Once the tests were completed the charted ping times returned to normal again.
This may explain the totally eradic problem with the long ping times.
I have seven site-to-site VPNs running as well as an ecommerce/web/mail server and I'm starting to think that it is the lack of upload capacity that is causing my issue. We have a monthly flyer which can be downloaded by our online customers and it is usually around 10-12 MB in size. Right now we don't have all that much traffic to our online store but It may be the combination of bandwidth starvation when it comes to anything upload related.
comments?
edb
-
Interesting....
I replicated your testing on my connection. (2.8mbps symmetrical DSL) I normally get about 1.4 actual on speed tests with upload running just a little faster then download.
The ping times remained flat during the download side of the test but doubled on the upload side. Ping to www.kansas.com was around 45Ms download and 90Ms upload. The speed test times showed 1388kbps download and 1620kbps upload. I don't understand how traffic is routed but why does upload apparently take precedence over download traffic? (upload seems to saturate the bandwidth but download does not.) I am not running any traffic shaping on my network and I presume both upload and download is happening on the same protocol (http).
Ping to the ISP gateway. (The first router on the WAN side of my modem) Was 5ms prior to the test, 20ms during the download portion of the test and 79ms during the upload part of the test.
Ping to my LAN gateway. (My router) remained 1ms throughout the test.
-
That is Interesting mercyh
I'm surprised by your upload speed being as high as it is becuase usually it's throtled.
I wonder if anyone with a T1 connection would get the same results being a none shared connection?
My assumption is that it would be an unchanged up & down ping time but I don't have a T1 yet to test. :)
edb
-
My ISP is a small town (population 3,000) phone Co. that writes their own rules. They are the only broadband isp here other then radio or satellite. They truly are selling an unthrottled upload/download connection, however the bandwidth is still shared among all customers. I think they are currently serving from around 12mbs of paired ds3/t1s. Our 1:00pm speadtests bog down to around 450kbs.
-
Ok, that makes sense .... I'm thinking of getting a bonded T1 connection to give me 3.08Mbps both up and down but I'm just trying to confirm that it would actually make a big difference in the end and that it's not an internal networking issue on my end.
Don't want to just throw money at it unless the T1 would actually help becuase as far as download speeds they are comparable to cable but much better on the upload side due to cables throtling.
Since I'm starting to believe that my issue is upload related a T1 may be my fix.
edb
-
edb
Perhaps this would help
http://wiki.contribs.org/Wondershaper
-
Would wondershaper on SME help if the SME is not the gateway router?
-
Would wondershaper on SME help if the SME is not the gateway router?
Well in the very first post edb says "I have my SME server in gateway mode on a Sonicwall 2040 - DMZ port with a public IP and a private IP on the internal nic."
If another router is the gateway, then that may need outbound traffic shaping.
Also see this post re wondershaper & ping times, it may be a clue to resolving your problems.
http://forums.contribs.org/index.php?topic=29546.30
-
Thank for that tip Ray ...
I don't know much about traffic shaping but I'll look into that.
I think the Sonicwall 2040 has it's own bandwith management and QOS stuff but I've not looked at what it can do in that area because I didn't think it would help to any great extent.
I also had a look at this thread http://forums.contribs.org/index.php?topic=40019.0 (http://forums.contribs.org/index.php?topic=40019.0) which talks about qmail adding to bandwidth starvation. Any relevance I don't know.
edb
-
Here is an example of when things are seemingly running smoothly and I run the http://www.speakeasy.net/speedtest/ (http://www.speakeasy.net/speedtest/) speed test. What you see in the graph is the increased ping times when it begins the upload test and until it finishes. Note that the ping times went from 120ms to 2000+ms for that short period of time. This is the kind of thing that happens regularly and kills my Point-Of-Sale VPN connections when it does.
It can happen randomly for a few seconds or several minutes at a time.
Like finding a needle in a haystack as to what the cause is.
(http://i263.photobucket.com/albums/ii152/edb5/Chart4.jpg)
-
<~~not an expert but aren't "no load" ping times of 120 ms on an internal network excessive?
I'm on a wireless AP --- switch ---- gateway--modem (+some other stuff). No gigabit hardware anyware and wireless G. I have 1- 2 ms to get to gateway router, to my home network, I have 40 ms avg.
I ran the same speedtest and got Toronto - New York - 3235 kbps down and 3730 kbps up with almost no change internally and maybe doubling of external, see graph. Well I would show you the graph if I could get it into the post. I tried to cut and past bitmap and jpeg but neither would work. :?
Anyways I tried just pinging internal addresses with the speedtest running and I don't see the ping time to gateway at more than 2 ms for either up or down.
I guess I'm saying that something else is wrong inside the network, not at the gateway/firewall/modem level.
-
I guess I'm saying that something else is wrong inside the network, not at the gateway/firewall/modem level.
I would agree except that I can't tell from the IP's if these are all targets that are across the vpn tunnels. If one of these targets is on the local network there is something strange inside.
-
<~~not an expert but aren't "no load" ping times of 120 ms on an internal network excessive?
These internal IPs are my site-to-site VPN tunnels through the Sonicwall to other store locations.
-
add the internal IP of the sonicwall itself to your ping list I would assume this is your LAN internet gateway address. Also add the Sonicwall's gateway IP address on the Wan side. (This should be the first router past the sonicwall.) If the problem is on the cable side the internal IP address will not increase it's ping time but the external one will. If the problem is on the LAN side both pings will increase.
-
I think my issue may have a lot to do with email attachments.
We are a sales oriented company so the sales reps are doing quotes and sending customers pdf attachments that can sometimes be several MB in size.
Also, our sales reps receive pdf files from our suppliers regularly as well through email.
Here is the graph when I send a 1MB pdf email attachment to myself.
Anyone else seen anything like this?
(http://i263.photobucket.com/albums/ii152/edb5/send-email.jpg)
-
I just did an experiment that may help. I did the speedtest and had 3206 kbps down and 3807 up.
I connected by openvpn to home network, streamed some music and had 622 down 525 up. During speed test, streamed music started to break up but went when speed test was over. Internal pings did not move at all and external pings were only marginally lengthed if at all.
I stopped streaming but left vpn connection open and had 625 down and 603 up. So the VPN connection has a fair amount of "overhead" that I did not expect
I disconnected vpn and have 3800 down and 3600 up.
Perhaps the experts have something re traffic shapping.
Hope that this is helpful.
-
Are you onsite with the mailserver or is it across the VPN tunnel for you??
Try your speedtest with the following tool.
http://www.pingplotter.com/freeware.html
download from the link at the bottom of the page.
install and set your trace to google.com or some other such target, set your trace delay to 2.5 seconds, fire up your speed test and you can see which hop is causing your problem.
This is a graphical traceroute utility. I would expect the problem to be at the first hop after the sonicwall if the cable provider is the problem.
-
I sent an 6 meg file to my home network and ran the speed test. At work I have an external mail server. Internal/External pings were not affected. Speed test results for upload were down by approx 1000 kbps.
-
Here is the graph where I sent an email with a 1MB pdf attachment from work to my home account.
Notice the internal side Sonicwall gateway(192.168.10.88) is uneffected but everything else is.
(http://i263.photobucket.com/albums/ii152/edb5/email2.jpg)
-
Here is the ping plotter result of sending the same email while tracking www.google.ca
(http://i263.photobucket.com/albums/ii152/edb5/email3-1.jpg)
-
Did you run these on the same machine???
On pingtool you show your gateway as 192.168.10.88 on the pingplotter graph you have the first hop as ISP's router When I run pingplotter I get the first hop as 192.168.123.254> My LAN internet gateway. My next hop is my ISP's router. When you run IPCONFIG /all from the command line of your workstation do you have the correct gateway shown??
If that pingplotter graph is not obfuscated I think you have a DHCP server that is handing out the wrong gateway address. (Or I am not following your topography at all which is highly possible)
-
Your are correct in that 192.168.10.88 is my computers default gateway.
Here is my ifconfig from my workstation
IP Address. . . . . . . . . . . . : 192.168.10.30
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.10.88
DNS Servers . . . . . . . . . . . : 192.168.10.2
If I do a tracert from the DOS command line ... I get the same result with the ISP's router as the first hop.
-
edb
I also had a look at this thread http://forums.contribs.org/index.php?topic=40019.0 (http://forums.contribs.org/index.php?topic=40019.0) which talks about qmail adding to bandwidth starvation. Any relevance I don't know.
Is sme server the mail server ?
It's very easy to change the ConcurrencyRemote setting, to say 5 (or less) in your case, and see what happens.
qmail wil definitely utilise all available bandwidth, so the ConcurrencyRemote (& ConcurrencyLocal) settings will definitely tame this behaviour.
-
Here is the graph where I sent an email with a 1MB pdf attachment from work to my home account.
Notice the internal side Sonicwall gateway(192.168.10.88) is uneffected but everything else is.
(http://i263.photobucket.com/albums/ii152/edb5/email2.jpg)
I would go to the ISP with this graph. It seems to me that your mail server is not really the issue as your bandwidth saturates on any sizable upload. Even if you keep the mailserver from using all your bandwidth you will still have the problem with other downloads from your site. IMO if 1Meg of upload will do this to you your provider has oversold their available bandwidth.
-
Yes, that's what I figure as well mercyh so I will provide them with this info but I think I will just change to a bonded T1(3Mb) connection through Bell Canada instead if they can't resolve the bandwidth issue for me.
Ray
What exactly does the ConcurrencyRemote and Local setting do and how does it affect bandwidth?
We are in fact running SME as our mail server but our email goes though a Barracuda Spam firewall first and is then passed through to the SME for all incoming mail. I only have smtp port 25 open to the Baracuda and all mail is sent from the SME server via SSMTP port 465 and remote users use SPOP3 (995) to receive their email.
I'm just curious how the Concurrency settings change things.
edb
-
edb
What exactly does the ConcurrencyRemote and Local setting do and how does it affect bandwidth?
It sets the max number of concurrent messages being processed by qmail (for remote & local messages).
Without a limit qmail will try to process all messages as quickly as possible therefore using/saturating all available bandwidth, and create problems (slowness) for web users, file downloads etc, while those messages are being processed.
-
EDB,
You need to run a WHOIS on that ISP Router that you at first showed the IP address on. I was working on something else last night and ran into an IP in that Class A subnet. That block is not located in your country as near as I can tell.
If you have interest in taking this discussion further you can PM me.
rh at mercyh dot org
-
edb
I'll remind you of what you said in your very first post.
"If at the time this is happening I reboot the SME server the ping times quickly return to 45ms again but when the server comes back up it is back to the 2000+ms again. Sometimes this last for a couple of minutes and sometimes it lasts for an hour or more."
Isn't this suggestive of a sme setting or conflict, rather than an external issue.
-
edb
I'll remind you of what you said in your very first post.
"If at the time this is happening I reboot the SME server the ping times quickly return to 45ms again but when the server comes back up it is back to the 2000+ms again. Sometimes this last for a couple of minutes and sometimes it lasts for an hour or more."
Isn't this suggestive of a sme setting or conflict, rather than an external issue.
Yes, Ray that is what I had originally thought as well.
However, as the slowdown was happening the other day (and as I was monitoring with ping) I decided to reboot the SME to confirm that the SME may be the issue. To my surprize, with the SME offline the stats didn't change so that is what led me to it just being bandwidth saturation which may also stem from the 7 site-to-site VPNs that I have running through my Sonicwall. I spoke with my cable ISP yesterday and confirmed that I only have 60K upload capacity and no increase to that is forcast for at least six months.
That being said I think it is just a fact that my setup requires much more upload capacity than what I have available.
I did other research in the last couple days which also confirms this and the problems with cable when any upload capacity is required.
Just a note (I have never had any issues with download bandwidth) downloads have always been stable.
I will be moving us over to a bonded T1 which will provide me with dedicate (not shared) 3Mb up & down capacity and this should resolve my issues.
edb
-
You need to run a WHOIS on that ISP Router that you at first showed the IP address on. I was working on something else last night and ran into an IP in that Class A subnet. That block is not located in your country as near as I can tell.
Actually, it is located in Calgary, AB Canada
-
hi all..
my 2c: if the problem exists ONLY when you send email and/or upload files, it's a problem of upload bandwidth saturation.. which is evil on adsl connections :-)
try to shape your outgoing traffic
Ciao
Stefano
-
OK
I was going by memory on the IP and hadn't really taken good notice, it was stuck in my head as 12.x.x.x and that block is listed as AT&T USA. I thought it was possible that something was doing a redirect on your network and running all your traffic through a router that was not related to your ISP.
-
edb
... I spoke with my cable ISP yesterday and confirmed that I only have 60K upload capacity...
That pretty much answers it then.
Barely enough for one user !
-
Just want to thank everyone that has replied to this thread.
This is a great community where we can bounce stuff off of each other and I really appreciate it. :-)
Upload bandwidth appears to be the root of the issue for those that read this thread from the bottom up.
edb
-
edb
Even with only 60K outgoing, traffic shaping/bandwidth usage control/Concurrency settings would still be effective ways to manage that limitation, if you had to or wanted to.
-
I saw that people include a number of pictures or graphs in this thread, but I was unable to do so.
Any hints?
-
Procedure to insert an image into a forum post.
(http://www.mercyh.org/files/ImageInsertPic.JPG)
Place the image on a server that is accessible from the www.
From the create post window (See above pic) click on the insert image icon (circled).
Type the URL to the image between the two image placeholders created.
The above example creates the post below.
Of course if you delete the image file on the server you will have a broken post
-
(http://www.mercyh.org/files/Chart.jpg)
-
thx
-
edb
Even with only 60K outgoing, traffic shaping/bandwidth usage control/Concurrency settings would still be effective ways to manage that limitation, if you had to or wanted to.
Yes, thanks Ray
I will try the Concurrency setting but do you recall the default setting is so that I can set it back to normal when I get my new bandwidth in place. I will try your suggested setting of 5 and work from there and see what happens and as far as traffic shaping goes I'm still looking into that as well.
I'm reading about what Sonicwall has to offer in that area. They do have extensive bandwidth control as well so I'll start working on that as well.
Here is the link to the Sonicwall documentation for anyone who may be interested http://www.sonicwall.com/downloads/configuring_qos_and_bwm.pdf (http://www.sonicwall.com/downloads/configuring_qos_and_bwm.pdf)
edb
-
I saw that people include a number of pictures or graphs in this thread, but I was unable to do so.
Any hints?
Just an FYI but you can get a free account from photobucket for such purposes if you want to post pictures but not have them lead to your own site. That is what I used to post mine in this thread. It takes two minutes to signup and get started. Give it a try :-)
http://photobucket.com/
-
Ok, I found the Concurrecy default settings
How to limit or increase the concurrent outbound SMTP connections
Check the default setting
(ConcurrencyRemote - max number of remote deliveries to attempt)
cat /var/qmail/control/concurrencyremote
20
Note there is also a setting for ConcurrencyLocal
(ConcurrencyLocal - sets the max number of local deliveries to attempt)
cat /var/qmail/control/concurrencylocal
10To make the change
config setprop qmail ConcurrencyRemote 5
signal-event email-updateconfig show qmail
Taken from previous posts.
edb
-
edb
config setprop qmail concurrencyremote 5
That's incorrect, it has wrong capitalisation, it should read:
config setprop qmail ConcurrencyRemote 5
and
config setprop qmail ConcurrencyLocal 10
Taken from previous posts.
Be careful what you take from previous posts.
Those settings do not have a default db entry, but they do have a default value which is used when there is no db entry, as determined by the code in the templates.
To reset to default values just do:
config delprop qmail ConcurrencyRemote
config delprop qmail ConcurrencyLocal
signal-event email-update
PS With only 60K of outgoing bandwidth I'd be setting that to 1 ie
config setprop qmail ConcurrencyRemote 1
signal-event email-update
-
My Bad ... thanks for that correction Ray :-)
-
EDB,
thx for suggestion on photobucket.
At the start you said you're with Shaw Cable and somewhere else that 60 kbps is all upspeed they can get you. Just curious is this due to location or is Shaw messed up. It seems curious that Bell has something that Shaw doesn't
-
EDB,
thx for suggestion on photobucket.
At the start you said you're with Shaw Cable and somewhere else that 60 kbps is all upspeed they can get you. Just curious is this due to location or is Shaw messed up. It seems curious that Bell has something that Shaw doesn't
Yes, it is an inherent disadvantage of Cable with the useless upload speeds but some areas have much better upload capacity.
In our particular area this is the restriction that they have in place and I really didn't even know it until just this week.
Most of their customer base is the "home user" rather than Business customers which is why it is all designed for download capacity rather than upload.
With a Bell T1 line it is a dedicated 1.544Mb up & down with a Service Level Agreement and in business this can be important as we have had a time where Shaw had been down for two days and they also like to change your static IPs 2-3 times per year.
Also, with cable you can get 3200Kbps download one minute and then 386Kbps the next because the bandwidth is shared with all subscribers in that area. I just tested mine again and I got Download speed: 450 kilobits per second from PCPitstop.com and at 6:00pm if I try it I would get 3-4000Kbps.
If I can get Bell to tie my T1s directly into their backbone it would make cable look sick. :-)
edb
-
If I were you I would go directly to 3 up and down.
We don't have anything near as complicated as your set up. We were with Bell 1.5 up and down and had issues with uploading getting saturated and slow speed. We went on a witch hunt and found one torrent user, still had issues and replaced our router twice. We ended up going to 3 up/down and don't have any noticeable issues.
Good luck.
-
If I were you I would go directly to 3 up and down.
We don't have anything near as complicated as your set up. We were with Bell 1.5 up and down and had issues with uploading getting saturated and slow speed. We went on a witch hunt and found one torrent user, still had issues and replaced our router twice. We ended up going to 3 up/down and don't have any noticeable issues.
Good luck.
Thanks imcintyre ... that is exactly what I will be doing and it is great to hear that you have no more issues now.
It will likely take at least 3 weeks or so before I actually get it though because Bell is slow to act.
Nice to know someone else that is using a Bonded T1 :-)
-
imcintyre
Are you on Bell's ProConnect service or standard T1?
The ProConnect service can “prioritize” traffic into classes and runs about $350/month on an MPLS service arrangement so it is substantially cheaper than standard T1 or bonded T1 also.
The MPLS service runs on a fibre connection, and can provide much higher amounts of internet b/w in increments of 1 Mbps to 10 Mbps.
The Bell engeneers I've been speaking with say that all more bandwidth will do is speed up the time it takes to do the download but while the download is occurring my POS systems will still suffer but for a much shorter time because the download will complete sooner. He is probably right so with the their new ProConnect service I could maybe get away with a 2Mb connection instead of a 3Mb due to the “prioritize” traffic ability.
I'm glad I asked a lot of questions because this certainly sounds like the way to go considering my issue was that my VPN point-of-sale systems bogged when a customer was downloading a 12MB pdf document off of our webserver.
Makes sense to me ...
edb
-
edb
The Bell engeneers I've been speaking with say that all more bandwidth will do is speed up the time it takes to do the download but while the download is occurring my POS systems will still suffer but for a much shorter time because the download will complete sooner. He is probably right so with the their new ProConnect service I could maybe get away with a 2Mb connection instead of a 3Mb due to the “prioritize” traffic ability.
I'm glad I asked a lot of questions because this certainly sounds like the way to go considering my issue was that my VPN point-of-sale systems bogged when a customer was downloading a 12MB pdf document off of our webserver.
Whatever amount of bandwidth you have, it can still be saturated by too much activity.
That's why some form of bandwidth control/qos/prioritisation is required, particularly on business networks that have multiple users doing multiple "unknown" things.
You would probably find that even 1Mbps upload would still be adequate as long as you use outgoing traffic shaping eg the Wondershaper solution previously mentioned or similar.
-
edb
Have you disconnected everything except for one client to the modem and run an MTU ping.
If your mtu ping changes from 1500 then it's upstream.
The modem could be loaded with the wrong bin cap file or it's corrupt.
Also did you poke at the modem 192.168.100.1 to check signals?
Name
WebSTAR DPC2100R2
Hardware Version
2.1
Software Version
v2.0.2r1256-060303
Receive Power Level
14.3 dBmV
Transmit Power Level
46.5 dBmV
Cable Modem Status
Operational
If the receive level is 0dbmv or less then your problem is, your at or near the end of the line
and they need to boost it up or find the problem.
My d/l is 7mbit and up 6.5-7kb with those sig levels.
Your modem may be capped for less b/w or your paying for the slower service.
You have to make sure they load the right bin cap file to the modem.
BTW what did they say the flap were on the modem, if they said what is flaps
then you need to get more qualified folks out there to check things out.
The guys they send to you are bottom of the barrel techs, surely you'll never
see a 60k eng come out to visit.
You need to find out three things.....
Receive sig level
Modem flaps
MTU ping with only one pc client on the modem.
A low sig will cause flaps and erratic mtu pings.
Cable mtu ping should be rock solid 1500 else you have a problem Houston.
If mtu is erratic then your just going to chase your tail..........
10-4
-
edb
Whatever amount of bandwidth you have, it can still be saturated by too much activity.
That's why some form of bandwidth control/qos/prioritisation is required, particularly on business networks that have multiple users doing multiple "unknown" things.
You would probably find that even 1Mbps upload would still be adequate as long as you use outgoing traffic shaping eg the Wondershaper solution previously mentioned or similar.
Ray
I understand that traffic shaping is necessary in any case when you have a busy server. My Sonicwall 2040 has bandwidth allocation as well as Class Base Queuing (CBQ) on Ingress & Egress which I have tried but in my present state of only 60K up it doesn't really help.
My upload pipe is just too small right now.
However, when I get a reasonable upload capacity of 300-400K the Sonicwall BWM (Bandwidth Management) maybe all that is required to fine tune things. If I were to stop all email/web activity going through my current pipe I wouldn't have an issue at all with my VPN connections and my POS systems would hum. It's only when a download or large email is sent that it brings my VPN connections to a stand-still.
I think whether I go with Bell's Managed ProConnect service or the standard T1 either one would resolve my issue that I'm currently experiencing. There is a ballance that is necessary between available bandwidth and traffic shaping when it comes to latency such as what I'm currently faced with. Like you said before 60K is barely enough for one user never mind 50-100 and a busy website.
edb
-
Also did you poke at the modem 192.168.100.1 to check signals?
How were you able to check the stats of your cable modem?
I call them and had them check my modem levels and they said everything looks perfect, no flaps at all and receive levels were optimum but they told me that my issue was likely due to the 60K limitation on the upload side and there was nothing they could do about that until they update their network which wouldn't be for six months or so. After all the talk and reading I don't think Cable is the answer for Business no matter what they do to improve their network but it is awesome for a very small office or home type setup. They have a who cares attitude at best and make no guarantees on their service what so ever. This may improve over time but I'll be taking myself off of their list of Business customers right shortly. Anyways, I was tired of them changing my static IPs every time I turned around.
Thanks for your comments though ...
edb
-
Type that in your browser 192.168.100.1
Not sure what modem you have but most respond to that IP.
Google your modem model # and get the admin IP address.
60k up on cable is ridiculous, thats not even dial up.
You need to speak to the right people, they obviously are like so many dumb ass support
folks they don't realize what they say and if you accept that then oh well.
The bandwidth provided is in your contract, the paper you received when you signed up.
What's on their website now and your contract may be two diff things.
Your contract is the one to go by.
Any cable company offering 60k up these days should shut it's doors and go home.
What ISP is it?
My ISP is a small town (population 3,000) phone Co. that writes their own rules.
They better start writting some new rules before they go out of business....!!!
Have you checked your mtu ping and what is the result.
Sounds like they don't have many folks that know whats up.
If mtu ping is anything other then 1500 then it doesn't matter what speed they offer
you won't get what's advertised and that is b/c they have a system problem.
I would call the office president and speak with him, sure he would like to
know what problems exist on his system.
I had to do that here several times to get the right people motivated to
fix things.
60k their joking...right!!
Like I said you need to check things for yourself and verify eveything and stop taking peoples word
as gospel.
If someone wants to piss me off all they have to say is
"Well sir the problem appears to be at your end, we don't have any other people complaining"
98% of the people on the internet don't know they even have a problem more or less complain
about it.
Get the answers to the three things in my previous post and then you will know for sure if 60k is real.
MTU rock solid 1500
Flaps count <100/week
Modem Receive level >5dbmv
Like I said connect one pc to the modem and verify.
It's the only way to rule out everything else on your side of the fence.
BTW no flaps at all.....yea right, somebody is blowing smoke.
Every modem will flap even as much as 10 a week....so no flaps = smoke.
Anything more then that can be considered suspect.
Also if you think dsl will be any better, well I would suggest not turning off your cable to quick.
I think they are currently serving from around 12mbs of paired ds3/t1s.
You would have to know how many connections they have avail in order to support 3000 base.
You have a support web page for your isp?
hth
-
electroman00
Your quotes are not from anything I have written but rather one of the replies I received from mercyh I beleive.
I will try connecting to the Terayon to have a peek, I didn't realize you could do that.
Always learning something new but what are the chances that they don't have a default setup on these modems since it would be public knowledge I wouldn't think that would be very smart on their part.
edb
-
edb
Don't know but I will check into it, I'm not the IT guy.
-
electroman00
Your quotes are not from anything I have written but rather one of the replies I received from mercyh I beleive.
Sorry about that.....anyway this might help ya....
http://www.hwkb.com/Uwe/Forum.aspx/network-cable-modem/542/IP-Address-for-Terayon-Modem-Needed (http://www.hwkb.com/Uwe/Forum.aspx/network-cable-modem/542/IP-Address-for-Terayon-Modem-Needed)
You might also need the password.
Depends on how your ISP sets up the modem as to what info you get.
Always learning something new but what are the chances that they don't have a default setup on these modems since it would be public knowledge I wouldn't think that would be very smart on their part.
You can't set anything up, but you can get very relevant info i.e. rec signal level which is enough to diagnose most problems.
i.e. MTU problems.
hth
-
Well I tried connecting to the Terayon modem through 192.168.100.1 but it's a no go on my system.
Maybe ISPs where you are have things setup differently. I really couldn't see that being possible becuse what if I was a customer and wanted to make my network 192.168.100.0 and give my router the address of 192.168.100.1 which would be the normal procedure. This would cause a conflict giving it the same IP as the modem but the customer doesn't know that the address is already taken by the modem.
Bottom line is that accessing the modem doesn't work here anyway and I assume the ISP has the pages blocked if nothing else.
edb
-
edb
Don't know but I will check into it, I'm not the IT guy.
Thanks imcintyre :-)