Link dropout at Puck

@NetworkAdmins

Good Day

If someone could please assist - It would be much appreciated . . . Been noticing these drops for the past week or so during Gaming Time . . .
Unable to log into RB at 172.26.25.1 Puck with ctwug account . . .

Again later . . . same day . . . at regular intervals - only monitored during Gaming Time.

7th Hop iP . . .

2 Likes

i saw you guys dropping on ts last night and tonight also got very high pings and packet loss on 172.26.65.1

2 Likes

But it comes and goes . . . By the time admins see the post and try to troubleshoot . . . then the link has recovered . . .

Below refers to the same running clean . . . unless the issue/s has been attended to . . . In the latter case, . . . Thank u . . .
But definitely worth looking into . . . as it been going haywire at this rate and intervals for the past week or so . . .
@JellyBean

2 Likes

Ok . . . so its a Non-Mikrotik device . . . dohhh ! ! ! !

But why if I may ask is this device on the ospf routing table . . . I might be a bit blond in doing so . . . But would still like to know . . .if someone could please elaborate for my and everyone else that might be wondering 's understanding - Thanks . . .

This is one of the fibre tunnels:

Your packet is effectively traveling to puck then over tunnel (over the internet) to skouperd and then on to razor.

What I find interesting as the pings seem to be arriving fine at razor. No packet loss on the last hop. But again I’d suggest you round with Count = 100 when you run it. Not just 6 or 7 or 2. I’ve mentioned this before. See example below.

I see dns.puck is now off. Perhaps @JellyBean can let me know what’s up? Can’t check the problem now as traffic is flowing a different route. I do think the dns.skouperd (the skouperd side of the tunnel) has internet connectivity issues from time to time. I think this might be the cause. I’d like to figure this out though.

2 Likes

@spin

Thanks a lot for clearing this up . . . Your feedback brings greater insight to all of us I’m sure . . .
Also . . . I would like to say thanks to you . . . and everyone else for all the work and effort going into making the WUG the exciting experimental platform that it was intended to be - Keep up the good work guys. . .

Getting back to the issues above though . . .
What I’ve notice is that at the time of experiencing packet losses while in Gaming Time, I immediately switched from my game that I was busy playing to windows environment and did the initial tracert which initially displayed packet losses of up to 50% . . . and then would slowly regress and die down to no losses again - Because I had the DNS box ticked just to display the identity (name) of the hops in the trace, the ip addresses was not showing . . . so once I could see which hop number and name (7.dns.puck.ctwug.za.net) was giving issues . . . ,

I stopped the trace and re-started it with DNS box disabled to see what the ip of that hop was so that I could later use this info to log into that rb with ctwug account and continue troubleshooting from there. . .
Which is why only 7 packets can be seen in the screenshot above. . .

Above screenshot displays a round trip of 92 packets sent with only 12 % lost at hop number 7 ==> dns.puck.ctwug.za.net . . .

To my understanding and limited knowledge . . . (please correct me if I’m wrong here :wink: )
I derived that the lost packets might have been resend due to the nature and design of the TCPIP Protocol used in data transfer . . . So these packets that was lost in the initial transfer, has now been resend . . .
And due to the connection recovering in the meanwhile, they were successfully resend and accounted for on the receiving end - Hence the losses gets lesser the longer the trace is run . . . Am I correct in saying so ?

So then when I left the tracert running - The packet losses completely disappeared because of this error correction built into TCPIP . . . ( as can be seen from the 113 packets sent in the same tracert that was left to run a bit longer in the screenshot below. . .)

But it still doesn’t explain the cause of the link dropping initially - I would like to suggest maybe having a look at the logs on this nginx server @ 172.26.65.1 to check for issues that might indicate problems that lead to the packet losses at that time - Will be sure to enable time and date stamps on my rb’s winbox next time I post regarding such issues . . .

1 Like

As always you cover a lot of ground in your post. So I will take this step by step.

You can use winbox with the name of the machine. You don’t have to have the IP. So you can use winbox directly with the name for example the following would work:

Then looking at this trace you posted:

Your traceroute to dns.puck is of limited value. The problem is actually between dns.puck and the next hop. Althoughthere does seems to be something weird. You should however trace to the final destiantion as your first trace but with more packets. Do not trace to the problem host as you actually want to see if packets are travelling through that link not to that link.

That is not correct. ICMP (Pings) are a different kind of protocol than TCP. Run a 100 ping trace in future. You can set the count as 100 as I showed.

This is wrong. The whole point of ICMP is to measure round trip time (the ms) and also to measure packet loss. So pings are not resent.

This trace is the best. (I prefer Use DNS on though, but for some reason it seems your dns did not resolve)

The packet loss has disappeared but you can see between puck (172.26.65.1) and skouperd (172.18.2.4) there was significant delay as well. And also the Standard Deviation (Std. Dev.) is high. Some call it “Jitter”. This measures how consistent the ping is. If the ping is consistent you may still be able to play. But with high variance it may get difficult. This still shows a problem on that hop (though lesser of a problem than packet loss).

Likely cuase is internet problems at skouperd. Nginx is not involved. It’s merely the webserver and all it’s doing is hosting a speedtest server on dns.puck here:
http://speedtest.puck.ctwug.za.net/ (not available at present)
or a similar one here: http://speedtest.skouperd.ctwug.za.net/

The tunnel is run on tinc and the routing by quagga software packages.

3 Likes

Lastly if you want the IP for hostname you can also run nslookup on the command line as follows:

nslookup dns.puck.ctwug.za.net

The output will look something like this:

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	dns.puck.ctwug.za.net
Address: 172.26.65.1

The above is from a Ubuntu machine but it works on Windows also. The output looks a bit different thought.

3 Likes

:blush: As always . . .
Thanks a lot for your response . . .
Step by Step we all learn . . . and by traveling these learning grounds together . . . we teach each other.
Much learned here in this post though . . . I’m sure that I’m not the only one who feels that way . . .

Appreciating the time you took to enlighten us . . . by detailing your response to the questions above.

See you in the next one . . .

Yours in Wugging
NissaN

Hi, apologies for the delayed response and inconvenience, I was out of the country and could not access my devices.
@spin you should now be able to access it.
From what I can see everything seems to be up now.

2 Likes