Semoweb Up And Down Constantly

Portal Home > Knowledgebase > Industry Announcements > Web Hosting Main Forums > Providers and Network Outages and Updates > Semoweb Up And Down Constantly

Posted by gilbert, 05-01-2012, 01:06 PM
I'm not getting much support from there tech support. The VPS goes down all the time throughout the day and then comes back online. There tech support blames it on network but doesnt appear to have a problem to deal with it.
Posted by Techy, 05-01-2012, 01:08 PM
If you are unhappy with your provider why don't you find a different one? Also, is the network currently down, or are you just posting a quasi review of the support you're getting from SemoWeb?
Posted by gilbert, 05-01-2012, 01:12 PM
I'm trying to get management involved even they are ignoring me on here it seems. I setup a monitor on pingdom last night you can see the public image here...
http://share.pingdom.com/banners/d45223fb
Posted by Dustin Cisneros, 05-01-2012, 01:35 PM
I'm sorry, I am as blunt as they come, and I will tell you from the start
I am not going to hold your hand nor my team is, you have an unmanaged VPS... your issue is isolated to your container, in addition you apparently
think that SolusVM is used to manage your VPS for reviewing uptime, real time memory usage, etc... I told you that SolusVM is great but if you want real memory usage statistics etc use the command line, check your processes via the command line, check the uptime via the command line...

You keep calling stating your have issues with UP/DOWN OK???? Prove it, provide MTR's & Tracerts of the issue, I dont care about your pingdom report ok? Figure it out.... your httpd service is going down why??? is there packet loss?

We need you to investigate it, we handle network/hardware related issues on unmanaged vps and your not facing either, your facing an isolated issue that has nothing to do with the node, you keep saying "Oh its not the network, I THINK its the nodes hardware" UGHHH NO!!!! your up/down would
be a network issue or something specifically causing your httpd service to crash..

EVERYTHING you say is the nodes problem, when your VPS was running out of memory OUR NODE was out of memory apparently,, UGGHHHH NOOO figure it out its your issue... and I am sorry we wont hold your hand...

If you want a refund no worries open a ticket I'd be willing to hand it over to you.
Posted by [JSH]John, 05-01-2012, 01:46 PM
It sounds like you need a managed VPS or a VPS with more resources.
Posted by Techy, 05-01-2012, 01:47 PM

Quote:

Originally Posted by semoweb

I'm sorry, I am as blunt as they come, and I will tell you from the start
I am not going to hold your hand nor my team is, you have an unmanaged VPS... your issue is isolated to your container, in addition you apparently
think that SolusVM is used to manage your VPS for reviewing uptime, real time memory usage, etc... I told you that SolusVM is great but if you want real memory usage statistics etc use the command line, check your processes via the command line, check the uptime via the command line...

You keep calling stating your have issues with UP/DOWN OK???? Prove it, provide MTR's & Tracerts of the issue, I dont care about your pingdom report ok? Figure it out.... your httpd service is going down why??? is there packet loss?

We need you to investigate it, we handle network/hardware related issues on unmanaged vps and your not facing either, your facing an isolated issue that has nothing to do with the node, you keep saying "Oh its not the network, I THINK its the nodes hardware" UGHHH NO!!!! your up/down would
be a network issue or something specifically causing your httpd service to crash..

EVERYTHING you say is the nodes problem, when your VPS was running out of memory OUR NODE was out of memory apparently,, UGGHHHH NOOO figure it out its your issue... and I am sorry we wont hold your hand...

If you want a refund no worries open a ticket I'd be willing to hand it over to you.

WOW...

You wanted management involved, you got it. PS - this isn't a helpdesk.
Posted by gilbert, 05-01-2012, 01:52 PM
The vps is running litespeed webserver from a setup I have installed on 4 other similar vservers with other providers. The vserver is only using somewhere between 500 to 600 megabytes of ram at anytime out of the 1.25 gigs free.

I also setup iptables firewall to drop all icmp and udp messages. And have a strong per ip limit to limit ddos attacks etc. The vserver at anytime has no more than 26 connections on port 80 via netstat command the only open port.

Quote:

Originally Posted by Techy

WOW...

You wanted management involved, you got it. PS - this isn't a helpdesk.

It might be unmanaged but things like hardware and stable network connection are still his responsibility.
Posted by Dustin Cisneros, 05-01-2012, 02:13 PM

Quote:

Originally Posted by gilbert

The vps is running litespeed webserver from a setup I have installed on 4 other similar vservers with other providers. The vserver is only using somewhere between 500 to 600 megabytes of ram at anytime out of the 1.25 gigs free.

I also setup iptables firewall to drop all icmp and udp messages. And have a strong per ip limit to limit ddos attacks etc. The vserver at anytime has no more than 26 connections on port 80 via netstat command the only open port.

It might be unmanaged but things like hardware and stable network connection are still his responsibility.

Gilbert...

There you go, I can almost GUARANTEE your issues are due to your firewall set up, your httpd monitor is all out of wack most likely due to ICMP Rate limiting, I suggest you ssh into your container and then start doing some work, its definitely isolated to your container...

Its within your own set up and there's nothing we can do about it, you need to manage your own set up.
Posted by cpoalmighty, 05-01-2012, 02:15 PM

Quote:

Originally Posted by gilbert

The vps is running litespeed webserver from a setup I have installed on 4 other similar vservers with other providers. The vserver is only using somewhere between 500 to 600 megabytes of ram at anytime out of the 1.25 gigs free.

I also setup iptables firewall to drop all icmp and udp messages. And have a strong per ip limit to limit ddos attacks etc. The vserver at anytime has no more than 26 connections on port 80 via netstat command the only open port.

It might be unmanaged but things like hardware and stable network connection are still his responsibility.

I think they answered your concerns already and I doubt they would give you a head start in the right direction if they did not know or at least investigate the matter themselves. If you would like the support, then simply pull out your cc and pay for it. That is how business is now a days. I am sure they have to handle their customers who actually pay for support on a daily basis. Just pay a small one time fee for them to resolve the issue amicably and then you can get back to your vps without a problem.
Posted by cd/home, 05-01-2012, 02:26 PM

Quote:

Originally Posted by gilbert

I also setup iptables firewall to drop all icmp and udp messages. And have a strong per ip limit to limit ddos attacks etc.

I think the problem is here...
Posted by gilbert, 05-01-2012, 02:38 PM
Do you guys even have a clue as to how iptables works? Stop saying bs like I think its your iptables and changing the subject. ICMP is a completely different networking protocol than TCP.

ICMP messages are only used for ping. TCP is used by web servers completely different. And yes I have my monitor set correctly to the right tcp.

Don't comment in here if you dont have anything intelligent to say or don't know a dammed thing about how computer networks and the internet work and are connected together.
Posted by cd/home, 05-01-2012, 02:42 PM

Quote:

Originally Posted by gilbert

Do you guys even have a clue as to how iptables works? Stop saying bs like I think its your iptables and changing the subject. ICMP is a completely different networking protocol than TCP.

ICMP messages are only used for ping. TCP is used by web servers completely different. And yes I have my monitor set correctly to the right tcp.

Do you even know how Pingdom actually works?

Also Pingdom is checking every 5 minutes unless you have created rules to allow their IPs within your firewall I would slack it back to 15 minutes at least
Posted by gilbert, 05-01-2012, 02:44 PM

Quote:

Originally Posted by cd/home

Do you even know how Pingdom actually works?

Yes its an uptime monitoring service for various different networking resources. That alerts you to when your website etc goes offline via text message or email etc.

Once again your trying to change the subject. I said not to comment in here if you didn't have anything intelligent to say.
Posted by cpoalmighty, 05-01-2012, 02:45 PM

Quote:

Originally Posted by gilbert

Do you guys even have a clue as to how iptables works? Stop saying bs like I think its your iptables and changing the subject. ICMP is a completely different networking protocol than TCP.

ICMP messages are only used for ping. TCP is used by web servers completely different. And yes I have my monitor set correctly to the right tcp.

Don't comment in here if you dont have anything intelligent to say or don't know a dammed thing about how computer networks and the internet work and are connected together.

It's easy for us to say don't post if you don't want to pay for extra support but hey, at least people are posting to try to give you free support here. Also, the tone of your style of writing has much to be desired and I think its part of that why your host enforced that you have an unmanaged VPS with them

Quote:

Originally Posted by cd/home

Do you even know how Pingdom actually works?

Too funny. Lets wait for the answer
Posted by cd/home, 05-01-2012, 02:48 PM

Quote:

Originally Posted by gilbert

Yes its an uptime monitoring service for various different networking resources. That alerts you to when your website etc goes offline via text message or email etc.

Once again your trying to change the subject. I said not to comment in here if you didn't have anything intelligent to say.

Exactly if you have a strict firewall in place Pingdoms nodes will actually get blocked at times.

Its well proven around here and at all other sources Pingdom doesnt give a true reflection of service if your firewall is too strict.

I guess people like you cannot be helped since you have to make such utta useless statements when your here asking for help...

So if your not wanting help I can only see your attempt here is to bash Semoweb.

As for intelligence am more than qualified to comment on any server related issue and can tell you from experience and dealing with many cases like your own if Dustin is saying the network is good and all your showing is a Pingdom report and saying you have a strict firewall then the problem lies with YOU
Posted by KnownHost-Jonathan, 05-01-2012, 02:56 PM

Quote:

Originally Posted by gilbert

I said not to comment in here if you didn't have anything intelligent to say.

Then don't post your issues in a public forum.
Posted by gilbert, 05-01-2012, 05:32 PM
Everytime I log into Solus VM when my vserver goes down I get this screen no matter how many times I try to boot.

http://i.imgur.com/o8AG9.png

Plus I cant even login to the console either.
Posted by gilbert, 05-01-2012, 06:00 PM
If anyone wants to see the uptime of the node please click here...

http://stats.pingdom.com/lz5bx4j3c7rt

I have setup another 5 minute check (ICMP Ping) to the nodes ip address (hosts system) 184.171.255.59 so you can see for yourself the node going online and off and online and offline etc. And that what others in the forum claim me to be some crazy wacko here on WHT who just can't manage his own vps.

Also compare those stats to my vservers ping stats here if you like. I think you will find the correlation interesting when you see that they are both down at the same time.
http://stats.pingdom.com/xvqf8t7y09y2

Please note I just setup the nodes stats and you might want to wait until more data comes in later in the day. But both checks run every 5 minutes.
Posted by cd/home, 05-01-2012, 06:27 PM

Quote:

Originally Posted by gilbert

If anyone wants to see the uptime of the node please click here...

http://stats.pingdom.com/lz5bx4j3c7rt

I have setup another 5 minute check (ICMP Ping) to the nodes ip address (hosts system) 184.171.255.59 so you can see for yourself the node going online and off and online and offline etc. And that what others in the forum claim me to be some crazy wacko here on WHT who just can't manage his own vps.

Also compare those stats to my vservers ping stats here if you like. I think you will find the correlation interesting when you see that they are both down at the same time.
http://stats.pingdom.com/xvqf8t7y09y2

Please note I just setup the nodes stats and you might want to wait until more data comes in later in the day. But both checks run every 5 minutes.

So how can your VPS have a higher uptime than the main node?

Main node:

Quote:

Uptime last 7 days
66.56%

Virtual Machine:

Quote:

Uptime last 7 days
83.04%

As what I have already said the problem lays with Pingdom and your setup!
Posted by SM-Dominic, 05-01-2012, 06:29 PM

Quote:

Originally Posted by gilbert

If anyone wants to see the uptime of the node please click here...

http://stats.pingdom.com/lz5bx4j3c7rt

I have setup another 5 minute check (ICMP Ping) to the nodes ip address (hosts system) 184.171.255.59 so you can see for yourself the node going online and off and online and offline etc. And that what others in the forum claim me to be some crazy wacko here on WHT who just can't manage his own vps.

Also compare those stats to my vservers ping stats here if you like. I think you will find the correlation interesting when you see that they are both down at the same time.
http://stats.pingdom.com/xvqf8t7y09y2

Please note I just setup the nodes stats and you might want to wait until more data comes in later in the day. But both checks run every 5 minutes.

Maybe i'm missing something but according to pingdom the host node is down and your VPS is up.
It's possible that Semoweb has a strict firewall on the host node that causes "fake downtime reports" as stated earlier, and your own firewall is wrongly configured as well.
Posted by gilbert, 05-01-2012, 06:59 PM

Quote:

Originally Posted by cd/home

So how can your VPS have a higher uptime than the main node?

I just setup the report for the hosts systems today. Pingdom started checking my vserver yesterday around this time.

As time progresses things should even out. My goals was to point out the correlation as time progresses that its not my vps or anything I'm doing to cause the problem. It's simply an entire node problem and this is the best way I could think to prove it.
Posted by cd/home, 05-01-2012, 07:09 PM

Quote:

Originally Posted by gilbert

I just setup the report for the hosts systems today. Pingdom started checking my vserver yesterday around this time.

As time progresses things should even out. My goals was to point out the correlation as time progresses that its not my vps or anything I'm doing to cause the problem. It's simply an entire node problem and this is the best way I could think to prove it.

Well the server is blocking the requests made by Pingdom.

Like I said slack back the monitoring to 15 minutes instead of 5

Its an all too common problem that servers at times will block requests by Pingdom due to the frequency of requests, etc
Posted by lonea, 05-01-2012, 07:43 PM
As most ISP technical support would ask.

"Can you turn off the firewall and try again ?"
Posted by neovo, 05-03-2012, 02:57 PM
I'm on the same node as you... when I 1st started something similar was happening to me constant downtime and I only installed webmin this was sorted out very quickly by support I have no idea on my total downtime but it does go down quite alot its .....but its doing what I want it to do.

Support @ semoweb can be a little to quick to close tickets but this is what happens when your paying for an unmanaged service. Though support have answered everything I have asked and thats good enough for me specially for the price of the service.
Posted by Dustin Cisneros, 05-03-2012, 04:29 PM

Quote:

Originally Posted by neovo

I'm on the same node as you... when I 1st started something similar was happening to me constant downtime and I only installed webmin this was sorted out very quickly by support I have no idea on my total downtime but it does go down quite alot its .....but its doing what I want it to do.

Support @ semoweb can be a little to quick to close tickets but this is what happens when your paying for an unmanaged service. Though support have answered everything I have asked and thats good enough for me specially for the price of the service.

Every ticket is closed once answered and there is a signature in every department that states this or every ticket... And can easily be reopened by responding.. As such we simply answer and resolve issues and close tickets due to the many inbound tickets we get, it makes it easier and cleaner for us to work through issues much faster
Posted by neovo, 05-03-2012, 05:02 PM
I wasn't having ago m8 I have only just noticed you can reopen a ticket even when its closed ...need to put my glasses on.
Posted by gilbert, 05-04-2012, 03:31 PM
Thanks neovo for speaking up! I appreciate not feeling all alone anymore.
Posted by Flapadar, 05-04-2012, 05:00 PM

Quote:

Originally Posted by gilbert

If anyone wants to see the uptime of the node please click here...

http://stats.pingdom.com/lz5bx4j3c7rt

I have setup another 5 minute check (ICMP Ping) to the nodes ip address (hosts system) 184.171.255.59 so you can see for yourself the node going online and off and online and offline etc. And that what others in the forum claim me to be some crazy wacko here on WHT who just can't manage his own vps.

Also compare those stats to my vservers ping stats here if you like. I think you will find the correlation interesting when you see that they are both down at the same time.
http://stats.pingdom.com/xvqf8t7y09y2

Please note I just setup the nodes stats and you might want to wait until more data comes in later in the day. But both checks run every 5 minutes.

I'm pinging 184.171.255.59 with MTR right now, and it's showing 4-18% loss. I presume this is them ignoring ICMP at high rates, which would explain why you saw such activity on pingdom.

The server isn't down.
Posted by gilbert, 05-04-2012, 05:40 PM

Quote:

Originally Posted by Flapadar

I presume this is them ignoring ICMP at high rates

Problem is I experience the downtime on http tcp based connections at the same exact times on my vps monitor.

He was nice enough to offer me eventually hosting on a different node but that one was experiencing downtime blips as well so I never transfered my sites. I plan to just finish my months contract and then just move away.

My guess is the cabinet he uses to hosts these nodes with the vps servers on them are just strained on networking resources. He sells 10 terabytes of hosting per vps and in order for him to be able to fulfill that promise it would take 31.25 mbps per vps. http://www.webhostingtalk.com/archiv...t-1109632.html

Plus if these vps servers are high traffic going through some sort of denial of service filter. This denial of service filter system could be simply overloaded / underpowered to deal with large ammounts of traffic.

I originally started this thread in public forum to try and get him to actually deal with problems on his network. I started a support ticket one week before starting this thread and only opened this thread because I felt the problem was being ignored after several attempts to get them to actually look into the problem.
Posted by Flapadar, 05-04-2012, 05:50 PM
Contact them with extensive MTR reports to and from your VPS and see if that helps them diagnose the issue, if there is one.
Posted by Erawan Arif Nugroho, 05-04-2012, 07:10 PM
Um.. So you have the 10TB bandwidth VPS package. I was having that too, but I just cancel it a few days ago, because it's not stable.
I have the same issues as you. Sometimes it shows offline, and suddenly rebooted.
Posted by moltra, 05-06-2012, 08:10 AM
I too have the 10TBVPS package and have already had tech support move me to a new node due to random stability problems. The new node looked good at first, but now it is starting to randomly be off line. Tech supports asks for proof of a problem, when all they have to do is look at the statistics for the VPS.

I have noticed alot of people in this thread saying that the way the data is being collected could be the problem. The data I have is coming straight from Semoweb's VPS Control Panel by SolusVM.

If you look at the charts I saved from the control panel you can see where the memory used is zero. This means that their VPS monitoring system is logging that the VPS is down. So why do they need more information from the end user, if they can tell that the VPS is down.

And as you can see from the log, I have not rebooted or shutdown the VPS since 5/3/2012.

Judging by the responses to the tickets, Tech support is checking to see if the VPS is up, not what is causing it to be unstable. With multiple people complaining about the same problem, I would look at the hosting not the end users.
Posted by Flapadar, 05-06-2012, 08:15 AM

Quote:

Originally Posted by moltra

I too have the 10TBVPS package and have already had tech support move me to a new node due to random stability problems. The new node looked good at first, but now it is starting to randomly be off line. Tech supports asks for proof of a problem, when all they have to do is look at the statistics for the VPS.

I have noticed alot of people in this thread saying that the way the data is being collected could be the problem. The data I have is coming straight from Semoweb's VPS Control Panel by SolusVM.

If you look at the charts I saved from the control panel you can see where the memory used is zero. This means that their VPS monitoring system is logging that the VPS is down. So why do they need more information from the end user, if they can tell that the VPS is down.

And as you can see from the log, I have not rebooted or shutdown the VPS since 5/3/2012.

Judging by the responses to the tickets, Tech support is checking to see if the VPS is up, not what is causing it to be unstable. With multiple people complaining about the same problem, I would look at the hosting not the end users.

While those graphs can be indicative of problems, that can also occur without one being there. You should collect further evidence to provide them with - for example, MTR reports.
Posted by moltra, 05-06-2012, 08:26 AM
How would a MTR report which is a network diagnostic tool, give more information than the hosting providers own, Virtual Private server management system that is used to provision the VPS? I can see the MTR giving information on the system being unreachable, but not with the load and memory usage being zero, which is an indication of the VPS being shutdown.

Here is a TRACEROUTE from the 1st node I was on. It shows a problem past the Hostdime.com. This was sent to semoweb with one of the earlier tickets I submitted to them.

Run 1
Traceroute #1 to 192.168.102.1
Hop Time (ms) IP Address FQDN
1 0.688 192.168.102.1 192.168.102.1
2 4.643 96.255.249.1 L300.WASHDC-VFTTP-85.verizon-gni.net
3 6.882 130.81.180.208 G0-3-5-6.WASHDC-LCR-21.verizon-gni.net
4 9.885 130.81.199.30 so-7-1-0-0.RES-BB-RTR1.verizon-gni.net
5 7.278 152.63.34.21 0.ae1.BR2.IAD8.ALTER.NET
6 26.908 4.68.62.137 ae17.edge1.washingtondc12.level3.net
7 32.011 4.69.158.18 vl-3501-ve-115.ebr1.Washington12.Level3.net
8 22.447 4.69.148.105 ae-6-6.ebr1.Atlanta2.Level3.net
9 31.646 4.69.137.149 ae-1-8.bar1.Orlando1.Level3.net
10 32.446 67.30.140.2 HostDime.com-10G-ethernet.core1.level3.net
11
12
13
14
Run 2
Traceroute #2 to 192.168.102.1
Hop Time (ms) IP Address FQDN
1 0.453 192.168.102.1 192.168.102.1
2 4.975 96.255.249.1 L300.WASHDC-VFTTP-85.verizon-gni.net
3 7.186 130.81.180.208 G0-3-5-6.WASHDC-LCR-21.verizon-gni.net
4 7.269 130.81.199.30 so-7-1-0-0.RES-BB-RTR1.verizon-gni.net
5 7.901 152.63.34.21 0.ae1.BR2.IAD8.ALTER.NET
6 37.013 4.68.62.137 ae17.edge1.washingtondc12.level3.net
7 17.467 4.69.158.18 vl-3501-ve-115.ebr1.Washington12.Level3.net
8 32.237 4.69.148.105 ae-6-6.ebr1.Atlanta2.Level3.net
9 29.755 4.69.137.149 ae-1-8.bar1.Orlando1.Level3.net
10 32.349 67.30.140.2 HostDime.com-10G-ethernet.core1.level3.net
11 32.846 184.171.255.59 mail-out.dixhost.com
12 34.137 184.171.255.136 184-171-255-136.static.dimenoc.com
Run 3
Traceroute #3 to 192.168.102.1
Hop Time (ms) IP Address FQDN
1 0.508 192.168.102.1 192.168.102.1
2 4.778 96.255.249.1 L300.WASHDC-VFTTP-85.verizon-gni.net
3 7.246 130.81.180.208 G0-3-5-6.WASHDC-LCR-21.verizon-gni.net
4 87.336 130.81.199.30 so-7-1-0-0.RES-BB-RTR1.verizon-gni.net
5 9.976 152.63.32.141 0.ae1.BR1.IAD8.ALTER.NET
6 36.929 4.68.62.133 ae16.edge1.washingtondc12.level3.net
7 19.985 4.69.158.18 vl-3501-ve-115.ebr1.Washington12.Level3.net
8 24.850 4.69.148.105 ae-6-6.ebr1.Atlanta2.Level3.net
9 42.196 4.69.137.149 ae-1-8.bar1.Orlando1.Level3.net
10 49.685 67.30.140.2 HostDime.com-10G-ethernet.core1.level3.net
11 34.942 184.171.255.59 mail-out.dixhost.com
12 37.285 184.171.255.136 184-171-255-136.static.dimenoc.com

Quote:

Originally Posted by Flapadar

While those graphs can be indicative of problems, that can also occur without one being there. You should collect further evidence to provide them with - for example, MTR reports.

How could those graphs occur without there being a problem? If you are saying their monitoring system cannot enable them to tell if they have a problem, then they should look at another. When a server is suppose to be up, the memory usage should never be zero.
Posted by Flapadar, 05-06-2012, 08:39 AM

Quote:

Originally Posted by moltra

How would a MTR report which is a network diagnostic tool, give more information than the hosting providers own, Virtual Private server management system that is used to provision the VPS? I can see the MTR giving information on the system being unreachable, but not with the load and memory usage being zero, which is an indication of the VPS being shutdown.

MTR shows where there is a connectivity problem. If their nodes were physically going down, I'm sure they would have noticed by now.

Quote:

How could those graphs occur without there being a problem? If you are saying their monitoring system cannot enable them to tell if they have a problem, then they should look at another. When a server is suppose to be up, the memory usage should never be zero.

SolusVM is very buggy - for example quite frequently it shows clients using 60PB/s of bandwidth. Nor is it a monitoring tool.
Posted by moltra, 05-06-2012, 09:52 AM
I have a question for you. You get home and find out that your electric is out. What do you do? Do you call your electric company and report it? Or do you get in your car and start following the power lines to find out where the power is out? I can see giving the company information that might help them, but is that information useful, when their own systems are telling you that they are offline.

I know if I was running a company that supplied a service to consumers, (which is what my website is suppose to do), then I would make sure that I had the required infrastructure in place to ensure that the service was monitored and I was informed immediately if there was a problem.

For example, the data in my site is currently being used by one client and three more in the developement stage, I monitor my website and API constantly to ensure that my clients are getting what I promised them. I use various methods to ensure that my website and database is aviliable 24/7. And the service that I provide is at no cost to the clients.

Quote:

Originally Posted by Flapadar

MTR shows where there is a connectivity problem. If their nodes were physically going down, I'm sure they would have noticed by now.

SolusVM is very buggy - for example quite frequently it shows clients using 60PB/s of bandwidth. Nor is it a monitoring tool.

So you are saying that they are using a subpar Virtual management system. If they are using a buggy virtual servar manager, then are they serving their clients? I know I would want as rock solid management system as possible. If the one I was currently using was "very buggy", then I would find another system, or put in place a method of telling if part of my system was down or unavailable.
Posted by moltra, 05-06-2012, 10:14 AM
@Flapadar, what would be a good site to use to monitor connectivity and help determine the cause of the reliability issues? I am not here to put down a company, or jsut to gripe. I have setup a generic test on pingdom to check the site, and I am looking for a site that does a traceroute on a regular basis.
Posted by Flapadar, 05-06-2012, 10:28 AM

Quote:

Originally Posted by moltra

So you are saying that they are using a subpar Virtual management system. If they are using a buggy virtual servar manager, then are they serving their clients? I know I would want as rock solid management system as possible. If the one I was currently using was "very buggy", then I would find another system, or put in place a method of telling if part of my system was down or unavailable.

As a management system it is fine; but the statistics leave a lot to be desired. Take them with a pinch of salt.

Quote:

Originally Posted by moltra

@Flapadar, what would be a good site to use to monitor connectivity and help determine the cause of the reliability issues? I am not here to put down a company, or jsut to gripe. I have setup a generic test on pingdom to check the site, and I am looking for a site that does a traceroute on a regular basis.

Pingdom for network uptime monitoring, MTR for network diagnosing.
Posted by moltra, 05-06-2012, 11:51 AM
I have started a couple of monitoring sites to help determine the cause of the reliability issues. I will update this thread with any problems that are found.
Posted by moltra, 05-06-2012, 01:24 PM
the more I look at the traceroutes, the more I think the problem is right at the node, or the switch that feeds the node.

Run 1
Traceroute #1 to 192.168.101.1 Hop Time (ms) IP Address FQDN
1 0.408 192.168.101.1 192.168.101.1
2 4.336 96.255.249.1 L300.WASHDC-VFTTP-85.verizon-gni.net
3 6.954 130.81.109.152 G0-3-5-7.WASHDC-LCR-21.verizon-gni.net
4 7.327 130.81.199.30 so-7-1-0-0.RES-BB-RTR1.verizon-gni.net
5 7.310 152.63.34.21 0.ae1.BR2.IAD8.ALTER.NET
6 7.236 4.68.62.137 ae17.edge1.washingtondc12.level3.net
7 17.236 4.69.158.22 vl-3502-ve-116.ebr1.Washington12.Level3.net
8 24.626 4.69.148.105 ae-6-6.ebr1.Atlanta2.Level3.net
9 29.946 4.69.137.149 ae-1-8.bar1.Orlando1.Level3.net
10 49.759 67.30.140.2 HostDime.com-10G-ethernet.core1.level3.net
11
12
13
14 37.130 64.37.56.252 64-37-56-252.static.dimenoc.com

Run 2
Traceroute #2 to 192.168.101.1 Hop Time (ms) IP Address FQDN
1 0.433 192.168.101.1 192.168.101.1
2 3.894 96.255.249.1 L300.WASHDC-VFTTP-85.verizon-gni.net
3 36.884 130.81.109.152 G0-3-5-7.WASHDC-LCR-21.verizon-gni.net
4 7.287 130.81.199.30 so-7-1-0-0.RES-BB-RTR1.verizon-gni.net
5 11.940 152.63.32.141 0.ae1.BR1.IAD8.ALTER.NET
6 9.846 4.68.62.133 ae16.edge1.washingtondc12.level3.net
7 9.369 4.69.158.22 vl-3502-ve-116.ebr1.Washington12.Level3.net
8 30.140 4.69.148.105 ae-6-6.ebr1.Atlanta2.Level3.net
9 29.517 4.69.137.149 ae-1-8.bar1.Orlando1.Level3.net
10 62.474 67.30.140.2 HostDime.com-10G-ethernet.core1.level3.net
11
12 36.916 64.37.56.252 64-37-56-252.static.dimenoc.com

Run 3
Traceroute #3 to 192.168.101.1 Hop Time (ms) IP Address FQDN
1 0.467 192.168.101.1 192.168.101.1
2 4.462 96.255.249.1 L300.WASHDC-VFTTP-85.verizon-gni.net
3 7.147 130.81.109.152 G0-3-5-7.WASHDC-LCR-21.verizon-gni.net
4 7.313 130.81.199.30 so-7-1-0-0.RES-BB-RTR1.verizon-gni.net
5 22.140 152.63.32.141 0.ae1.BR1.IAD8.ALTER.NET
6 9.788 4.68.62.133 ae16.edge1.washingtondc12.level3.net
7 14.759 4.69.158.22 vl-3502-ve-116.ebr1.Washington12.Level3.net
8 25.407 4.69.148.105 ae-6-6.ebr1.Atlanta2.Level3.net
9 31.571 4.69.137.149 ae-1-8.bar1.Orlando1.Level3.net
10 49.792 67.30.140.2 HostDime.com-10G-ethernet.core1.level3.net
11
12
13 34.224 64.37.56.252 64-37-56-252.static.dimenoc.com