Problem with Monitor...underway UDP is lost at packet-dot-net

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

Hi Bas, sorry to hear you’re having problems. The best thing to do is log a ticket with your ISP so they can investigate and contact the peer and ask them to resolve / change their routing.

All of us that pass that server have problems.
The server is in the USA near the monitoring station, way after peering near my ISP.
So contacting them is of no use.
Your data-center should contact them, as they are probably a peer to them.
Opening a ticket here will do nothing, you need to contact packet-dot-net and tell them it’s not resolved at EWR1

The loss is there.

Why is this handled as spam?

Hi Bas, only Ask has the relationship with the provider at the monitor end. He is unlikely to respond for some time, so the only options are to ignore the problem and wait for it to improve on it’s own or for you to contact your ISP as you have the relationship with them. Other people have contacted their providers and they have happily looked at and resolved routing issues between their ends and the monitoring server.

Sorry I can’t be of more help :slightly_frowning_face: but you have to remember that the pool is a free service run by volunteers. :slight_smile: :+1:

Hi Elljay,

I understand that it’s all volunteers, I’m one too :slight_smile:
However, many of us get spammed with automated-messages being removed from the pool.
I’m investigating the matter for more then 2 weeks now, tested everything possible.
And it turned out to be packet-dot-net that hasn’t fixed their faulty, server, as I posted before.

I’m running 2 servers, and every time we hit EWR1 the packages are lost 100%.

I know what my ISP will tell me, that they have no relation with that peer and as such it’s not their problem.

However, I will contact packet myself and tell them about the problem, maybe it helps.

Thanks anyway,

Bas.

Yeay for volunteers! :grinning: :+1:

I agree it’s annoying - I was just writing a proposed update to the alert email that gets sent to add some troubleshooting steps as we seem to get be getting quite a few queries recently!

I think I would push the ISP harder - you pay them to deliver traffic and they’re not doing it properly! :slight_smile: Having set up our own servers we probably have more knowledge than those who haven’t - I don’t think ISPs could expect most people to be able to diagnose where routing isn’t working or expect people to contact that peer directly! The routing is within the ISP/Peers control not ourselves. As I say we’ve had reports back from other people whose ISPs have contacted peers and got things fixed. Good luck! :slight_smile:

Hi Elljay,

Well I used to be a trouble-shooting-engineer and a webhoster myself.
Doing this kind of stuff is fun!
Still hosting but just for friends, not to get paid.

I just got word from packet and they are going to contact NTPpool to sort it out.
Nice!

Bas.

Nice one! Hope they find the root cause! :+1:

Look what happened, they added to extra IP’s to find the cause:

17.|-- 39.ae32.bbr2.ewr1.packet. 0.0% 10 91.5 92.0 91.4 94.1 0.6
18.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
19.|-- 147.75.98.107 0.0% 10 105.2 118.5 104.4 189.0 25.1

and

17.|-- 39.ae32.bbr2.ewr1.packet. 0.0% 10 134.2 96.1 91.6 134.2 13.4
18.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
19.|-- 147.75.98.105 0.0% 10 104.1 105.5 102.9 113.8 3.3

And then after a few “pings” 2 other servers popup:

dsr1 + dsr2 both .ewr1 as extra…and 147.75.98.105 / 107 …

Previous runs didn’t show those…UDP still lost, but 95% and not 100% anymore.
Looks like some monitor of their own.

Bas.

In the meantime I got messages from Packet and NTPpool.

Let’s hope it’s sorted soon.

As it’s a major issue for many, including me…we are on life-support (-5 ~ -30) right now…but the next automated message will flat-line us :cold_sweat:

I for one am not ready to give up! :grinning:

We are getting somewhere, there is a problem with monitoring.
As they asked me to use the beta-server as well.
So I did.

On the normal server ntp1.heppen.be is rubbish, but on the beta-server no issues at all, it’s near 20.
But my seconds, ntp2.heppen.be is perfect on the normal server but rubbish on the beta-server, score about 5.6.

As the beta server is in Amsterdam and not in the USA it has a different path.

In my optinion the monitor can’t be trusted if you have to follow a path that drops UDP-messages.

The uptime-testing should be more robust and not assume your server is bad just because the path to you is broken.

If you have troubles with the blue-line and thus bad scores, it is suggested you enter your server here:

http://web.beta.grundclock.com/

Then wait an hour or so and see if your scores are ok. My “bad” server is shown ok there, so the monitor has a problem.

Look at the scores on different monitors:

Normal:

Beta-server:

Greetings Bas.