@JDMcPea said: @Janevski By "fine" I mean it's currently working for me as in sending daily backups of my website to the Dallas DAZ008 machine. And also I can ping Dallas from it and I can't from home. And traceroute does not time out. If there are issues with the connection between the two VPS doesn't seem to be causing problems for me at least in this instance.
Don't know what the !X means in the trace, that's why I came here for help free consultation
At this point am going to guess AlwaysSkint's suggestion of FUBARed routing table is most likely with Comcast blocking access as runner up. Time will tell.
edit: typo
Okay so I figured I'd give you an update here in case anyone is interested, might as well. It definitely seems to be a routing issue and also seems to be some weird coincidence. I've contacted everyone to correct it on their end but somehow the /24 IPv4 we leased for DALZ008 around May 2022 or so got announced with AS35913 (INAP) as expected, BUT
I was essentially writing out a long drawn out ticket to get it relayed to INAP to take a look since everything looked OK on our end and by the end of it I realized it didn't make sense that it'd happen around the same time we had the reported issues in LAX.
So I looked up the IRR on HE and it looks like the block is still announced from 2021 and it just happens to be with AS29802 which is Hivelocity and it's marked as their LAX datacenter. So I don't know what finally "activated" it but I'm having that looked at now. Basically it looks like NYC Metro is having problems connecting specifically to this one /24 block, and the nameservers (8.8.8.8, 8.8.4.4) have 30ms ping because it's now effectively updated as being in Los Angeles because BGP.
@vyas said:
Mods: Title may need editing. If Provider is not at fault here, why does title mention their name?
OP begins with Virmach, then ends up with Jarland. Mentions PDiddy for good measure. Only 53 more names to go
This is stupid.
It is a Virmach VPS and the subnet is blacklisted at mxrbl.com (run by mxroute.com).
Both providers are relevant to OP's problem.
Reading Virmach’s wall of text above, it is evident that wht should have been a ticket 🎟️ from OP to Virmach, will now be addressed via PM, so still a 1:1 that the “helpers “ and “advisers” will not be privy to, unless shared by OP or Virmach with OP permission.
Paying customer resolving 1:1 with services provider who is recipient of payment. Which was my point.
Now who should feel stupid?
You clearly should.
Because it is stupid to attack people because they ask for help on a forum.
Especially when you are LES staff (Content Writer).
Could we kindly tone it down on the “stupid” remarks going forward? If everyone calls everyone stupid, MaxKVM will have nothing to say upon their return.
@MichaelCee said:
Could we kindly tone it down on the “stupid” remarks going forward? If everyone calls everyone stupid, MaxKVM will have nothing to say upon their return.
You can cut from my “staff” salary everytime I say Stupid.
Apparently I get paid a lot writing
Enough of this crap. Buffoons less than two weeks here make allegations, of attacking.
What was and should have been a ticket with the concerned provider has taken a dump.
Reading Virmach’s wall of text above, it is evident that wht should have been a ticket 🎟️ from OP to Virmach, will now be addressed via PM, so still a 1:1 that the “helpers “ and “advisers” will not be privy to, unless shared by OP or Virmach with OP permission.
Paying customer resolving 1:1 with services provider who is recipient of payment. Which was my point.
Now who should feel stupid?
Have a nice day
I disagree.
I think people should do their own troubleshooting first. It is a good idea to search the internet for troubleshooting information. It is also good to learn by asking in internet forums. Perhaps you missed something obvious or lack one tidbit of knowledge that experienced people take for granted.
Opening a ticket is the last resort. You open a ticket after you have read the manual and done your own homework, research, and troubleshooting.
In my opinion, people open tickets and call the manufacturer for help far too often. They don't bother to analyze the problem for themselves any longer. In my opinion, this behavior change has resulted in the "dumbing down" of customer support. By the time I am ready to open a ticket or call for help, I am often at the point where I know more about the product and the problem than the support person. It can be frustrating when the entire customer support apparatus does not know enough about their products to provide real support beyond scripts like "Is it plugged in?" "Let's reboot it and try again." "Delete all of your settings and customization and work, reinstall the product, reconfigure everything and call us back in a week. Did the problem go away?"
Asking your friends for some helpful advice on LowEndSpirit is not "free consulting" but an effort to try and learn to do better troubleshooting rather than resorting to tickets.
I haven't really read what everyone's been posting about what should and shouldn't have been a ticket in our system and I'll say in this instance it was definitely helpful that it was not a ticket as it turned out to be an abnormal event where without much information and discussion, it would have been very easy for it to have a negative outcome with how our tickets are going right now.
OP definitely appears to have first done his due diligence to a very high level before coming here for help so it's not just a case of a customer immediately going to a message board to blast a company to try to get priority support.
If he had first presented all this information in a ticket, there's a high chance we would reach a conclusion there as well but it would be hindered by the volume of "other" tickets and obviously our biases that go into that when the last hundreds of reports we've primarily looked at have been vague and already resolved or not on our end.
Anyway, my vote goes for thinking this would be a good example of what should be posted to a "help" section of a hosting-related message board, whether or not the host is part of said message board as it's equally likely someone here would have eventually noticed the double entries on RADB versus a technical support agent at any host company noticing first.
@VirMach said:
If he had first presented all this information in a ticket, there's a high chance we would reach a conclusion there as well but it would be hindered by the volume of "other" tickets and obviously our biases that go into that when the last hundreds of reports we've primarily looked at have been vague and already resolved or not on our end.
This should never occur, sack any and all staff that treat any customer correspondence with any form of bias due to other tickets - I get some are even bording on ridiculous at times, having had a fair few myself over the years but if your staff have that mindset you may aswell give up now!
Having said that, it's absolutely an appropriate discussion to have here, it's very silly to suggest otherwise! It's also beneficial to others!
───────────────────────────────────
🌐 Blesta.club - Blesta Modules, Plugins, Gateways and more
💬 Join our community today and start your journey!
───────────────────────────────────
@chris said: This should never occur, sack any and all staff that treat any customer correspondence with any form of bias due to other tickets - I get some are even bording on ridiculous at times, having had a fair few myself over the years but if your staff have that mindset you may aswell give up now!
I'm just being realistic here. In any profession, even if you are aware of potential biases, it's definitely easier for you to accidentally misdiagnose something. I agree with you that anyone should strive to avoid that but there's no way to completely 100% get rid of that when humans are involved.
It is unfortunately how a brain functions. If you are presented with 999 situations that fall in line one way and then 1 situation that's extra-ordinary, there's a likelihood of it being mislabeled.
Luckily we're only speaking of servers here and not human lives. There have been plenty of cases that represent this issue in aviation and medical care, where lives are directly at risk.
@chris said: This should never occur, sack any and all staff that treat any customer correspondence with any form of bias due to other tickets - I get some are even bording on ridiculous at times, having had a fair few myself over the years but if your staff have that mindset you may aswell give up now!
I'm just being realistic here. In any profession, even if you are aware of potential biases, it's definitely easier for you to accidentally misdiagnose something. I agree with you that anyone should strive to avoid that but there's no way to completely 100% get rid of that when humans are involved.
You can and you should, it's OK to think it may be X/Y/Z and check that first but every ticket should be treated as a new problem until resolved! I'm not trying to be argumentative here - I'm just of the opinion it leads to less work in the long run!
Any staff with that mindset will ruin your business reputation for you though
───────────────────────────────────
🌐 Blesta.club - Blesta Modules, Plugins, Gateways and more
💬 Join our community today and start your journey!
───────────────────────────────────
Greetings,
if the provider in question is okay with and has tacit consent for using LES as extended helpdesk, then I stand corrected and I concede. My past comments on the matter may be treated as void.
This subnet is reachable from Comcast business line in Washington DC area.
Source IP: 50.253.56.21
traceroute to 45.42.215.1 (45.42.215.1), 50 hops max, 64 byte packets
1 172.16.60.1 (172.16.60.1) 1.82 ms 1.76 ms 1.72 ms
2 50-253-56-22-static.hfc.comcastbusiness.net (50.253.56.22) 3.48 ms 4.00 ms 4.06 ms
3 96.120.11.117 (96.120.11.117) 14.70 ms 14.50 ms 12.80 ms
4 24.124.178.9 (24.124.178.9) 13.70 ms 13.10 ms 13.00 ms
5 69.139.174.145 (69.139.174.145) 15.00 ms 13.80 ms 12.10 ms
6 96.108.111.41 (96.108.111.41) 15.60 ms 14.60 ms 15.30 ms
7 96.110.235.69 (96.110.235.69) 14.50 ms 13.70 ms 16.40 ms
8 be-31421-cs02.beaumeade.va.ibone.comcast.net (96.110.40.21) 17.30 ms 17.00 ms 18.00 ms
9 be-3211-pe11.ashburn.va.ibone.comcast.net (96.110.32.126) 15.40 ms 16.30 ms 18.30 ms
10 62.115.51.193 (62.115.51.193) 17.60 ms 16.10 ms 15.40 ms
11 62.115.123.124 (62.115.123.124) 18.50 ms 18.70 ms 16.40 ms
12 62.115.136.200 (62.115.136.200) 20.70 ms 22.00 ms 21.00 ms
13 62.115.135.133 (62.115.135.133) 22.70 ms 21.30 ms 20.50 ms
14 213.248.66.102 (213.248.66.102) 20.40 ms 22.20 ms 21.50 ms
15 216.52.95.46 (216.52.95.46) 22.60 ms 23.40 ms 23.30 ms
16 74.201.164.150 (74.201.164.150) 24.40 ms 21.90 ms 22.60 ms
17 45.42.215.1 (45.42.215.1) 56.30 ms 38.30 ms 47.60 ms
I'm reminded of the mom who goes to watch her seventh grader march in the school parade. Sitting with her friends she exclaims: "Look. My little boy is the only one in step." Funny how ALL of the network disasters strike Virmach and nobody else in the industry. We have 40+ servers with different providers just to test functionality for the Incredible PBX project. Guess which one (and only one) regularly fails to connect?
Very happy to report that today the weird routing problem was having accessing my VPS on DALZ008 has been apparently been resolved. and it's accessible from home again. Thank you to everyone who offered advice. Below are the 10/14/22 results from my Comcast residential IP address:
Pinging 45.42.215.xxx with 32 bytes of data:
Reply from 45.42.215.xxx: bytes=32 time=52ms TTL=38
Reply from 45.42.215.xxx: bytes=32 time=52ms TTL=38
Reply from 45.42.215.xxx: bytes=32 time=60ms TTL=38
Reply from 45.42.215.xxx: bytes=32 time=52ms TTL=38
Ping statistics for 45.42.215.xxx:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 52ms, Maximum = 60ms, Average = 54ms
** Tracing route to 45.42.215.xxx over a maximum of 30 hops**
1 2 ms 2 ms 1 ms 10.0.0.1
2 10 ms 10 ms 13 ms 96.120.73.17
3 11 ms 10 ms 10 ms 24.124.224.129
4 14 ms 13 ms 13 ms 68.85.63.97
5 12 ms 13 ms 13 ms be-31133-cs03.newark.nj.ibone.comcast.net [96.110.42.41]
6 11 ms 11 ms 12 ms be-1311-cr11.newark.nj.ibone.comcast.net [96.110.35.74]
7 12 ms 12 ms 12 ms be-303-cr12.newyork.ny.ibone.comcast.net [68.86.84.242]
8 14 ms 12 ms 12 ms be-1112-cs01.newyork.ny.ibone.comcast.net [96.110.35.129]
9 11 ms 12 ms 12 ms be-3111-pe11.111eighthave.ny.ibone.comcast.net [96.110.34.18]
10 * * * Request timed out.
11 14 ms 14 ms 12 ms be3496.ccr42.jfk02.atlas.cogentco.com [154.54.0.141]
12 17 ms 16 ms 17 ms be2807.ccr42.dca01.atlas.cogentco.com [154.54.40.110]
13 30 ms 32 ms 31 ms be2113.ccr42.atl01.atlas.cogentco.com [154.54.24.222]
14 45 ms 45 ms 46 ms be2690.ccr42.iah01.atlas.cogentco.com [154.54.28.130]
15 49 ms 50 ms 50 ms be2443.ccr32.dfw01.atlas.cogentco.com [154.54.44.230]
16 49 ms 49 ms 49 ms be2939.rcr21.dfw04.atlas.cogentco.com [154.54.6.114]
17 49 ms 49 ms 50 ms be3795.nr51.b028597-0.dfw04.atlas.cogentco.com [154.24.61.202]
18 59 ms 59 ms 51 ms 38.140.239.18
19 50 ms 52 ms 50 ms border5.ae1-bbnet1.dal006.pnap.net [216.52.191.44]
20 51 ms 51 ms 51 ms dedipath-57.border5.dal006.pnap.net [107.150.158.10]
21 51 ms 52 ms 50 ms 185.161.69.135
22 51 ms 52 ms 50 ms 45.42.215.xxx
Trace complete.
Very happy to report that today the weird routing problem was having accessing my VPS on DALZ008 has been apparently been resolved. and it's accessible from home again. Thank you to everyone who offered advice. Below are the 10/14/22 results from my Comcast residential IP address:
Yep, confirmed on my end some time yesterday or the day before and also fixed the accompanied panel issue. I was actually looking for your ticket and couldn't find it in the sea of tickets but just remembered there was a thread here and came in to check, so I'm glad it's working for you again.
Comments
Don't, virmach has stained they underpants enough to be pre-banned by all email server operators. Thank you.
Okay so I figured I'd give you an update here in case anyone is interested, might as well. It definitely seems to be a routing issue and also seems to be some weird coincidence. I've contacted everyone to correct it on their end but somehow the /24 IPv4 we leased for DALZ008 around May 2022 or so got announced with AS35913 (INAP) as expected, BUT
I was essentially writing out a long drawn out ticket to get it relayed to INAP to take a look since everything looked OK on our end and by the end of it I realized it didn't make sense that it'd happen around the same time we had the reported issues in LAX.
So I looked up the IRR on HE and it looks like the block is still announced from 2021 and it just happens to be with AS29802 which is Hivelocity and it's marked as their LAX datacenter. So I don't know what finally "activated" it but I'm having that looked at now. Basically it looks like NYC Metro is having problems connecting specifically to this one /24 block, and the nameservers (8.8.8.8, 8.8.4.4) have 30ms ping because it's now effectively updated as being in Los Angeles because BGP.
AlwaysInterested
It wisnae me! A big boy done it and ran away.
NVMe2G for life! until death (the end is nigh)
You clearly should.
Because it is stupid to attack people because they ask for help on a forum.
Especially when you are LES staff (Content Writer).
Could we kindly tone it down on the “stupid” remarks going forward? If everyone calls everyone stupid, MaxKVM will have nothing to say upon their return.
Michael from DragonWebHost & OnePoundEmail
You can cut from my “staff” salary everytime I say Stupid.
Apparently I get paid a lot writing
Enough of this crap. Buffoons less than two weeks here make allegations, of attacking.
What was and should have been a ticket with the concerned provider has taken a dump.
Outta here.
———-
blog | exploring visually |
I disagree.
I think people should do their own troubleshooting first. It is a good idea to search the internet for troubleshooting information. It is also good to learn by asking in internet forums. Perhaps you missed something obvious or lack one tidbit of knowledge that experienced people take for granted.
Opening a ticket is the last resort. You open a ticket after you have read the manual and done your own homework, research, and troubleshooting.
In my opinion, people open tickets and call the manufacturer for help far too often. They don't bother to analyze the problem for themselves any longer. In my opinion, this behavior change has resulted in the "dumbing down" of customer support. By the time I am ready to open a ticket or call for help, I am often at the point where I know more about the product and the problem than the support person. It can be frustrating when the entire customer support apparatus does not know enough about their products to provide real support beyond scripts like "Is it plugged in?" "Let's reboot it and try again." "Delete all of your settings and customization and work, reinstall the product, reconfigure everything and call us back in a week. Did the problem go away?"
Asking your friends for some helpful advice on LowEndSpirit is not "free consulting" but an effort to try and learn to do better troubleshooting rather than resorting to tickets.
Some friends you are.
I haven't really read what everyone's been posting about what should and shouldn't have been a ticket in our system and I'll say in this instance it was definitely helpful that it was not a ticket as it turned out to be an abnormal event where without much information and discussion, it would have been very easy for it to have a negative outcome with how our tickets are going right now.
OP definitely appears to have first done his due diligence to a very high level before coming here for help so it's not just a case of a customer immediately going to a message board to blast a company to try to get priority support.
If he had first presented all this information in a ticket, there's a high chance we would reach a conclusion there as well but it would be hindered by the volume of "other" tickets and obviously our biases that go into that when the last hundreds of reports we've primarily looked at have been vague and already resolved or not on our end.
Anyway, my vote goes for thinking this would be a good example of what should be posted to a "help" section of a hosting-related message board, whether or not the host is part of said message board as it's equally likely someone here would have eventually noticed the double entries on RADB versus a technical support agent at any host company noticing first.
This should never occur, sack any and all staff that treat any customer correspondence with any form of bias due to other tickets - I get some are even bording on ridiculous at times, having had a fair few myself over the years but if your staff have that mindset you may aswell give up now!
Having said that, it's absolutely an appropriate discussion to have here, it's very silly to suggest otherwise! It's also beneficial to others!
───────────────────────────────────
🌐 Blesta.club - Blesta Modules, Plugins, Gateways and more
💬 Join our community today and start your journey!
───────────────────────────────────
I'm just being realistic here. In any profession, even if you are aware of potential biases, it's definitely easier for you to accidentally misdiagnose something. I agree with you that anyone should strive to avoid that but there's no way to completely 100% get rid of that when humans are involved.
It is unfortunately how a brain functions. If you are presented with 999 situations that fall in line one way and then 1 situation that's extra-ordinary, there's a likelihood of it being mislabeled.
Luckily we're only speaking of servers here and not human lives. There have been plenty of cases that represent this issue in aviation and medical care, where lives are directly at risk.
You can and you should, it's OK to think it may be X/Y/Z and check that first but every ticket should be treated as a new problem until resolved! I'm not trying to be argumentative here - I'm just of the opinion it leads to less work in the long run!
Any staff with that mindset will ruin your business reputation for you though
───────────────────────────────────
🌐 Blesta.club - Blesta Modules, Plugins, Gateways and more
💬 Join our community today and start your journey!
───────────────────────────────────
Greetings,
if the provider in question is okay with and has tacit consent for using LES as extended helpdesk, then I stand corrected and I concede. My past comments on the matter may be treated as void.
———-
blog | exploring visually |
This subnet is reachable from Comcast business line in Washington DC area.
Source IP: 50.253.56.21
HostBrr aff best VPS; VirmAche aff worst VPS.
Unable to push-up due to shoulder injury 😣
I'm reminded of the mom who goes to watch her seventh grader march in the school parade. Sitting with her friends she exclaims: "Look. My little boy is the only one in step." Funny how ALL of the network disasters strike Virmach and nobody else in the industry. We have 40+ servers with different providers just to test functionality for the Incredible PBX project. Guess which one (and only one) regularly fails to connect?
Very happy to report that today the weird routing problem was having accessing my VPS on DALZ008 has been apparently been resolved. and it's accessible from home again. Thank you to everyone who offered advice. Below are the 10/14/22 results from my Comcast residential IP address:
** Tracing route to 45.42.215.xxx over a maximum of 30 hops**
Yep, confirmed on my end some time yesterday or the day before and also fixed the accompanied panel issue. I was actually looking for your ticket and couldn't find it in the sea of tickets but just remembered there was a thread here and came in to check, so I'm glad it's working for you again.