Openload til netværkstest

[Christian.Arvai]

Det er også mere interessant at prøve at bruge TCP i stedet for ICMP med ping kommando. Årsagen er at nogle routere eller firewalls dropper ICMP pakker, og det vil virke som om der ikke er forbindelse til routeren, selv om der i virkeligheden er det.

Der er nogle fra klassen der mener at det skyldes "forkert IP konfiguration", men som jeg ser det skyldes problemet en blanding imellem "for lang afstand til routeren" og "egoistiske elever der misbruger nettet unødigt", da nettet virker perfekt, indtil ca kl 9, når antallet af brugere begynder at stige. Omvendt begynder det igen at virke senere på dagen (efter kl 14), så jeg tvivler sådan set på at det er et opsætningsproblem, men nærmere at netværket ikke kan håndtere så mange forbindelser på en gang.

PS: Det er lige før at det er værd at oprette en tråd med det SP, da det sikkert også vil gælde for mange større arbejdspladser.

[NickyThomassen]

TCP tracerouting kommando hedder tcptraceroute.

Meget spændende kommentar, og dens output ser godt ud til debugging. Man kan ihvertfald se om man selv kan løse problemet.

tcptraceroute kunne jo sagtens bygges ind i et script som det vi har lavet her, og når / hvis et ping så fejler, så starte tcptraceroute. Afslutter tcptraceroute heller ikke med succes, så kan den skrive til en log, maile en eller anden eller noget tredje.

[lath]

Det er også mere interessant at prøve at bruge TCP i stedet for ICMP med ping kommando. Årsagen er at nogle routere eller firewalls dropper ICMP pakker, og det vil virke som om der ikke er forbindelse til routeren, selv om der i virkeligheden er det.

Der er nogle fra klassen der mener at det skyldes "forkert IP konfiguration", men som jeg ser det skyldes problemet en blanding imellem "for lang afstand til routeren" og "egoistiske elever der misbruger nettet unødigt", da nettet virker perfekt, indtil ca kl 9, når antallet af brugere begynder at stige. Omvendt begynder det igen at virke senere på dagen (efter kl 14), så jeg tvivler sådan set på at det er et opsætningsproblem, men nærmere at netværket ikke kan håndtere så mange forbindelser på en gang.

PS: Det er lige før at det er værd at oprette en tråd med det SP, da det sikkert også vil gælde for mange større arbejdspladser.

Hvis du har ret så skal du fortælle dem at de skal erstatte deres dumme switche med managed switches.
De managed switche skal så konfigureres til QoS (Quality of Service), hvor de ip adresser der har mest trafik nedprioriteres til fordel for dem der ikke har så meget trafik.

En anden mulighed er at sortere i udadgående ikke for undervisningen relevant trafik.
Det kunne fx være facebook trafik og andre sociale medier det gik ud over.
Man skulle så både både DNS blokere fx. facebook og IP (IPv4 og IPv6) adresserne for facebook blokeres i undervisningstiden i en central firewall.
Før kl 9 og efter kl 14 hvor problemet ikke opstår kan man så åbne igen for en altid-ufiltreret-adgang trafik.

/Lars

[Christian.Arvai]

Jeg skal have ændret i scriptet, da det ikke virker på VUC, selv om selve netværket virker.

Kode: Vælg alt

c@c:~$ cd ~/ && sh net_test.sh www.google.dk 5000

 8:04:28 - Serveren kunne ikke nås -
 8:04:28 - Pingede www.google.dk på  ms. (4999 ping mangler)
 8:04:48 - Serveren kunne ikke nås -
 8:04:48 - Pingede www.google.dk på  ms. (4998 ping mangler)
 8:05:08 - Serveren kunne ikke nås -
 8:05:08 - Pingede www.google.dk på  ms. (4997 ping mangler)
 8:05:28 - Serveren kunne ikke nås -
 8:05:28 - Pingede www.google.dk på  ms. (4996 ping mangler)
 8:05:48 - Serveren kunne ikke nås -
 8:05:48 - Pingede www.google.dk på  ms. (4995 ping mangler)
 8:06:08 - Serveren kunne ikke nås -
 8:06:08 - Pingede www.google.dk på  ms. (4994 ping mangler)
 8:06:28 - Serveren kunne ikke nås -
 8:06:28 - Pingede www.google.dk på  ms. (4993 ping mangler)

[NickyThomassen]

Der er det samme problem i Nordsjælland, eller det vil sige, tjenester der ikke ligger på port 80, er blokeret.

Løsningen er måske som Lars forslog, at bruge tcptraceroute:

Kode: Vælg alt

titanus@asrock:~$ tcptraceroute aptget.dk
Selected device eth0, address 192.168.20.42, port 40193 for outgoing packets
Tracing the path to aptget.dk (46.21.105.38) on TCP port 80 (www), 30 hops max
 1  192.168.20.1  1.440 ms  1.197 ms  1.239 ms
 2  * * *
 3  * * *
 4  * * *
 5  te4-1-0.mr5.hoer.dk.ip.fullrate.dk (90.185.5.66)  23.126 ms  22.538 ms  25.527 ms
 6  90.185.4.137  60.239 ms  22.834 ms  22.941 ms
 7  ge-1-2-0-711.kdnqu1.dk.ip.tdc.net (80.63.8.41)  59.988 ms  23.348 ms  22.545 ms
 8  * * *
 9  te0-3-0-0.ccr21.sto03.atlas.cogentco.com (154.54.72.222)  33.265 ms  33.060 ms  44.299 ms
10  * * *
11  149.6.168.110  48.315 ms  32.458 ms  31.743 ms
12  vl-301.cr1-bma.glesys.net (195.20.206.4)  87.902 ms  33.922 ms  33.173 ms
13  te-4-1.cr1-fbg.glesys.net (46.21.96.145)  36.655 ms  37.356 ms  36.875 ms
14  79-99-2-70-static.serverhotell.net (79.99.2.70)  36.234 ms  36.791 ms  36.384 ms
15  mail.aptget.dk (46.21.105.38) [open]  37.014 ms  96.986 ms  36.751 ms

Den burde fungere på skolens netværk, men det er måske værd at teste programmet, inden at vi bygger et script op omkring det...

---

Btw, aptget står hos samme host som UbuntuDKs nye server, og cogentco.com er et tier 1 firma

[NickyThomassen]

Jeg har lavet en form for "af-art" af det her - nemlig et script der kan puttes ind i crontab'en.

Derfra kan man så bestemme hvor tit det skal køre, og alt efter syntaksen i crontab'en, om der skal sendes email efter hver kørsel, kun ved fejl eller slet ikke.

Det kontakter et efter et de sider der står i @sites, og printer svartiden, eller fejlkoden hvis siden ikke kan findes / nås.

Der er så en twist: Scriptet er skrevet i Perl

Kode: Vælg alt

#!/usr/bin/perl -w

use strict;
use warnings;
use LWP::UserAgent;
use Data::Dumper;
use Time::HiRes qw( time );

my @sites = (
"http://aptget.dk/",
"http://nt-data.dk/",
"https://ubuntudanmark.dk/"
);

for my $site (@sites) {

   my $time_start = time();
   my $con = LWP::UserAgent->new()->get("$site");
   my $time_stop = time();
   my ($sec,$min,$hour,$mday,$mon,$year)=localtime(time);

   if ($con->is_success) {
      printf STDOUT "D.%2d/%2d-%4d kl.%2d:%02d:%02d\n",
         $mday,$mon,$year+1900,$hour,$min,$sec;
      printf STDOUT "%.3f sekunders svartid fra $site\n\n", $time_stop - $time_start;
   } else {
      printf STDERR "D.%2d/%2d-%4d kl.%2d:%02d:%02d\n",
         $mday,$mon,$year+1900,$hour,$min,$sec;
      print STDERR "Error ", $con->status_line, "\n\n";
   }
}

Jeg er overrasket over hvor lidt det fylder i Perl, men det er selvfølgelig brugen af moduler der gør forskellen.

Kode: Vælg alt

titanus@asrock:~$ perl Skrivebord/ping.pl
D. 5/11-2012 kl.15:49:35
0.568 sekunders svartid fra http://aptget.dk/

D. 5/11-2012 kl.15:49:36
0.217 sekunders svartid fra http://nt-data.dk/

D. 5/11-2012 kl.15:49:36
0.245 sekunders svartid fra https://ubuntudanmark.dk/

titanus@asrock:~$