Merkelig nettverk/DNS problem.

[SveinHa]

De siste dagene har jeg slitt mer og mer med hjemmenettet, dårlig respons, enkelte maskiner faller helt ut og kan ikke pinges til/fra. Det har utviklet seg over tid men toppet seg i forgårs. Har ikke gjort noe med konfigurering av nettet på evigheter hen kikket gjennom oppsettet uten å finne noe stort.

 

Netter består av:

• Altibox i bromodus
• 5 stk Deco nooder, de fleste kablet, en enhet i Rutermodus kablet til Altibox
• De fleste enheter som kan kables er kablet men der er vel et par titalls WiFi enheter.

Jeg hadde en IP-ping-jobb gående mellom 2 lokale maskiner og den hadde både 20 og 30 ganger for lang responstid men i det øyeblikket jeg restartet Deco-nettet ble ping-responsen helt normal i de få sekundene før WiFi falt helt ut for så å bli dårlig igjen når nettet kom opp igjen. Det fikk meg til å tenke DNS problem selv om ping mellom IP adresser ikke burde ha behov for DNS.

 

Jeg har hatt flere forskjellige DNS servere i Deco, både Google og andre uten at jeg har merket noen forskjell på de. Uansett, jeg gjorde et forsøk med å sette opp Pi-Hole på en virtuell Ubuntu maskin og sette den som DNS server i DHCP oppsettet i Deco og plutselig var der full respons i nettet mitt igjen... De fleste enhetene fant den nye DNS serveren av seg selv men noen få måtte restartes.

 

Nå er der jo også flere i min omgangskrets som har erfart lignende de siste dagene og jeg tenker litt på at vi nå offisielt har 100% overvåking av nettverkstrafikk i Norge (vi har vel hatt det lenge men nå er det blitt offisielt). Ekstra overvåking gir ekstra trafikk... https://steigan.no/2023/03/total-overvaking-av-nordmenn-i-lopet-av-2023/

[Neophyte]

16 minutes ago, SveinHa said:

Jeg hadde en IP-ping-jobb gående mellom 2 lokale maskiner og den hadde både 20 og 30 ganger for lang responstid men i det øyeblikket jeg restartet Deco-nettet ble ping-responsen helt normal i de få sekundene før WiFi falt helt ut for så å bli dårlig igjen når nettet kom opp igjen. Det fikk meg til å tenke DNS problem selv om ping mellom IP adresser ikke burde ha behov for DNS.

 

Nå er der jo også flere i min omgangskrets som har erfart lignende de siste dagene og jeg tenker litt på at vi nå offisielt har 100% overvåking av nettverkstrafikk i Norge (vi har vel hatt det lenge men nå er det blitt offisielt). Ekstra overvåking gir ekstra trafikk... https://steigan.no/2023/03/total-overvaking-av-nordmenn-i-lopet-av-2023/

Hvis du pinger en IP adresse er ikke DNS involvert i det hele tatt. Hvis du pinger et DNS navn gjøres det først et DNS oppslagt og så sendes det en ping pakke. Responsiden du ser når du pinger påvirkes ikke av DNS oppslagt, bare tiden fra du skriver kommandoen til det faktisk sendes ut en ping.

 

Overvåkningen til E-tjensten lager ikke noe ekstra trafikk i ditt nett. Måten det er løst på er at de har et "TAP/SPAN Port" på alle linker som går ut av landet, hvor E-tjensten får en kopi av all trafikken.

[SveinHa]

Neophyte skrev (3 minutter siden):

Hvis du pinger en IP adresse er ikke DNS involvert i det hele tatt. Hvis du pinger et DNS navn gjøres det først et DNS oppslagt og så sendes det en ping pakke. Responsiden du ser når du pinger påvirkes ikke av DNS oppslagt, bare tiden fra du skriver kommandoen til det faktisk sendes ut en ping

Det var slik jeg trodde det skulle være også men litt merkelig at ny DNS løste problemet...

[SveinHa]

SveinHa skrev (På 21.3.2023 den 10.32):

...men litt merkelig at ny DNS løste problemet...

Løste var vel å dra det litt langt... Nettet bedret seg en liten stund med annen DNS-server men det ballet på seg igjen etter noen timer. I går ble det virkelig ille og jeg klarte ikke å lokalisere problemet. 

 

Hadde liggende noen gamle UniFi aksesspunkt som jeg fyrte i gang og så en god bedring. I dag stakk jeg innom Kjell&co og hentet en Ubiquiti EdgeRouter X. Et kjapt basisoppsett og Decoene ble skrudd av og da kviknet nettet dramatisk til. Etter å ha fått satt statiske IP adresser på nøkkelenhetene i DHCP serveren ser det hele ut til å være back-in-business igjen.

 

Et eller annet ser ut til å ha skjedd med Decoene. Statuslyset gikk i rødt med kortere eller lengre intervall. Har hatt 5 Decoer i drift men prøvde å erstatte hoved-Deco med den ene jeg hadde i reserve men ingen forskjell...

 

Håper det varer denne gang...

[storeulv]

Vill gjetting fra min side: kan det ha vært en spanning tree-type greie som utspilte seg?

Jeg vet at det er forskjell på produktene og merkene når det kommer til evnen til å undertrykke slikt, men jeg vet også at nettverk er noe jeg ikke kan.

[SveinHa]

Som sagt så klarte jeg ikke å finne ut hva som virkelig skjedde. Brukte en del dager og flere verktøy men endte opp med en slags eliminasjonsmetode... Spanning tree kan høres ut som en sannsynlig årsak men hva som har fått dette til å bli et stort problem akkurat nå er også et spørsmål. Har hatt Decoene i drift i 3-4 år...

 

storeulv skrev (1 time siden):

men jeg vet også at nettverk er noe jeg ikke kan.

Må vel også si at jeg ikke "kan" nettverk men det har vært en bi-del av jobben min helt siden den tiden Banyan Vines og 10Mbit coax ethernet var det helt store...

[SveinHa]

Tror jeg fant det virkelige problemet i dag. Har flere Ubiquiti EdgeSwitch og for å løse en akutt portkrise ved TVen satte jeg inn en 5-port TP-Link switch. Etter et år eller så med diverse utstyr som har kommet og gått har jeg klart å plugge begge ender av en og samme kabel inn i denne switchen. Etter jeg fikk i gang EdgeRouteren begynte begge LEDene i en av de 2 portene å blinke med 1 Hz, det har jeg aldri sett tidligere og jeg ser lysene på denne switchen der jeg alltid sitter i stuen. En feil jeg har gjort for en tid siden men som Deco ikke skjønte men EdgeRouter oppdaget tenker jeg...

 

Nå vet ikke jeg hvor STP algoritmene ligger men der er tydeligvis en forskjell i Deco og EdgeRouter.

[bjwanvik]

Godt du fant problemet! 🙂
Var igang med å skrive et svar her når du la til posten, så korter det ned betraktelig.

 

Slike litt for enkle enheter som den switchen som tilsynelatende var problemet ditt har gjerne en tendens til å skape litt krøll 😞

 

Null erfaring med Deco, men dette har verken med overvåkning eller DNS å gjøre. (Overvåkning anser jeg som helt usannsynlig - det ville i tilfelle vært fanget opp og flagget blant fagfolk for lengst, dessuten har de nok ingen magisk måte å komme bak alskens firewalloppsett 🙂 )

Edgerouteren du har fått tak i tipper jeg gjør susen. Har selv brukt ER4 i ganske mange år nå, og har igrunnen ikke hatt et feilslag. Sist jeg sjekket var vel oppetida noe over 2 år, men så fikk vi et strømbrudd som varte atskillig lengre enn ups'en var satt opp til å holde ting i live....
Synd det virker som de har "glemt" Edgeserien mtp oppdateringer etc, men det funker stort sett upåklagelig.
 

[SveinHa]

Nytt problem. Ikke så alvorlig som det tråden startet med men ille nok... Aner egentlig ikke hvor jeg skal starte å lete...

 

Nettet mitt ser ut til å fungere fint der det MÅ men de litt mindre viktige tingene som at VNC Viewer henger seg med ujevne mellomrom fra 1 sekund til timer plager meg mye siden jeg bruker VNC veldig mye. Noen ganger våkner VNC til live igjen av seg selv men vanligvis må den restartes og kommer da opp å gå igjen på et blunk som normalt. I NodeRed editor fryser statusoppdateringer (de tallene under noden i eksempelet). Det er ikke så veldig viktig og de livner til igjen med en refresh i nettleseren. Alt annet i NodeRed ser ut til å virke som det skal.

Disse tingene har fungert skuddsikkert i årevis og problemene begynte for en måneds tid siden eller noe slikt. Jeg vet ikke at jeg har gjort noe med nettet som skulle gi slike utslag... 

 

Har nå et rent Ubiquiti nett med 4 stk Unifi trådløse aksesspunkt, noen EdgeMax switcher og EdgeRouterX. Alle UniFi enhetene er av eldre dato (slutt på fw oppdateringer for et par år siden) så et par har blitt skiftet ut til "Ubiquiti Unifi 6 LR Wifi 6 Roaming-aksesspunkt AX3000"  etter problemene oppstod uten at det har gjort noen forskjell... Kjører Pi-Hole på en virtuell Ubuntu maskin og den har gått stødig i årevis. Liker ikke Ubuntu så jeg satte opp en Debian 12 maskin med Pi-Hole omtrent på den tiden problemene startet men stoppet denne og satte i drift den gamle Ubuntu maskinen igjen i dag men ingen forskjell.

 

Noen som har glupe tips om hva som skjer?

Endret 18. januar av SveinHa

[NilsOF]

Spanningtree (STP) er nevnt over.

Jeg kan levende forestille meg at loop kan oppstå med mesh-kapable aksesspunkter blandet med mer eller mindre STP-kapabelt utstyr.

Har man da i tillegg en ustabil forbindelse (boks med hikke, dårlig kabel/plugg eller mesh-APer som bare periodisk ser hverandre).. da er det flytende hvor STP klipperforbindelsen 😉 

 

På Unifi-APene kunne man slå av/på mesh-greiene. Mener man kan låse AP mot AP mesh-messig også..

(Nå kan jeg ikke sjekke dette da Unifi-kontrolleren min forlengst har avgått ved døden og oppsettet mitt venter på at jeg skal få ut fingeren og putte openwrt på APene)

 

Wifiman, Ubiquiti sin app, er den jeg bruker omtrent daglig da den forteller meg når telefonen  roamer mellom APene. Samtidig som den viser signalforhold.

Lenge siden jeg har satt opp noe Unifi nå, men appen plukker opp og kan konfigurere fabrikk-resatte Unifi-APer.

Mener å huske det er forskjell på ios og android -app, med androidversjonen som den mest anvendelige.

Endret 18. januar av NilsOF
Pressisjon

[NilsOF]

Og jeg glemte en meget nyttig funksjon i Wifiman;

Med to dingser med wifiman-app i samme nett så kan man måle hastigheten imellom de. Det fungerer på tvers av android og ios også.

[SveinHa]

Jeg oppgraderte UniFi Network Server til ver 8.0.7 for en tid siden da det var veeeeldig lenge siden sist. Mulig det kan ha noe med saken å gjøre... Finner ikke noe om meshing med ser at STP stod på RSTP så jeg satte den til STP nå. Vet ikke hva som er forskjellen i praksis...

[NilsOF]

Sett den tilbake til RSTP du 😉

R står for Rapid,  RSTP er kjappere og nyere en STP.

RSTP er også bakoverkompatibel med gamle STP.

 

Nå er det ikke sikkert at det er (R)STP som slår inn hos deg.

Nå kan man jo slå av (R)STP og se hva som begynner å lyse solid.

Det blir i tilfelle som å kortslutte sikringen for å se hvor det ryker henne.  😄

 

Jeg ville armert meg med to dingser og målt thruput mellom de histen og pisten. To dingser med wifiman gjør susen så lenge problemet er mellom WiFi-APene.

Endret 18. januar av NilsOF

[SveinHa]

VELDIG varierende resultat med WiFiman. Noen ganger rundt 50-60 Mbps, andre ganger mindre enn 5 og ender med "Speed Test Failed"...

 

Sitter med en enhet i hver hånd og aksesspunkt bak en tømmervegg 5-6 meter unna.

Endret 18. januar av SveinHa

[NilsOF]

Det høres ut som om at 50-60 Mbps er det det skal være, antar at det er 2.4Ghz.

 

[SveinHa]

Ser jeg er tilkoblet på 2.4 ja.

[SveinHa]

Når en eller begge enhetene er på 5 GHz går det langt bedre med hastigheter i området rundt 50-100 Mbps og internethastighet på 150 (som jeg betaler for) men  selv om der SER veldig bra ut med hastigheten så feiler testen ganske ofte med "Speed Test Failed, Speed Test server is unreachable".

 

Edit: Har et gammelt aksesspunkt (nyinstallert men noen år gammelt likevel) som rapporterer en del TX-retries. Har satt dette ut av drift uten at det endret noe merkbart...

Endret 19. januar av SveinHa

[Neophyte]

Er det bare på trådløst du har problemer eller er det med kabel også?

 

 

[SveinHa]

Det er jeg litt usikker på men det ser ut til at det kablede nettet fungerer. Merker meg dog at trafikkLEDene i alle porter har litt mer aktivitet enn jeg synes virker normalt...

[SveinHa]

Litt tidlig å friskmelde men jeg oppgraderte UniFi Network Server fra ver 8.0.7 til ver 8.0.26 og da ble der plutselig liv og skikkelig respons i en ESP32 med MQTT som jeg leker meg med. Denne hadde en responstid på alt fra 30 sekund til uendelig i går og fram til oppgraderingen nå for en halvtime siden. Nå snakker vi millisekund.

 

WiFiman har fremdeles veldig varierende resultat...

[SveinHa]

Siden oppgradering av UniFi Server gjorde en godt merkbar forskjell og det muligens var forrige oppgradering som forårsaket problemene gjorde jeg en nedgradering til ver 7.5.187. Nå kan jeg jo nedgradere til alle versjoner helt tilbake til 1 men valgte siste 7.x versjon inntil videre. Nå går det jo egentlig ikke å nedgradere så hele nettet måtte slettes og settes opp på nytt men det er nå en ganske liten og kjapp jobb som består i å opprette SSID, resette og adoptere alle aksesspunktene.

 

Finnes der noe netscanner program som kan fortelle om slike problemer på en ikke-nettverks-nerdete måte?

 

Edit: Får fremdels disse tilfeldige hengene i nettet så UniFi server er nok ikke årsaken. 

Endret 20. januar av SveinHa

[SveinHa]

Har kjørt 1000 ping til en del utvalgte enheter og resultatet ble slik:

Noen pakketap og litt lange responstider her og der så ingen gode konklusjoner enda. Foreløpig er dette en litt manuell operasjon så jeg skal automatisere litt mer. Har en scriptfil som tar seg av pinging men data må foreløpig leses ut manuelt og legges i regneark. Når jeg i løpet av dagen får litt mer gang på dette så får jeg se litt på WireShark, gode WireShark-tips mottas. 

 

[SveinHa]

Da har jeg lekt meg litt til. Resultatet er et par pythonscript som ender opp i en CSV fil som inneholder ping-statistikk for samtlige IP-adresser i nettet mitt klar for å åpne i regneark.

1. CreatePingFile.py: Bruker nmap for å liste alle aktive IP-adresser. Produserer filen PingAllAuto.sh som er rutinen for å pinge alle enheter et valgt antall ganger (100 ping i utgangspunktet). Resulterer i filen PingAllAuto.txt. PingAllAuto.sh kan bruke veldig lang tid på bli ferdig alt etter hvor mange enheter som er i nettet og hvor mange ping på hver... (antall ping * enheter = sekund kjøretid). Linje 5 i filen må endres til IP passende ditt nett og evt annet antall ping.
2. PingCreateCSV.py: Leser filen PingAllAuto.txt, mellomlagrer i PingAllAuto.fil2 og ender opp i PingAllAuto_yyyymmddhhmm.csv som er tilpasset norske spesialtegn (feltskille ";" og desimaltegn ","). 

Pythonscriptene forutsettes kjørt fra samme mappe med kommando (i denne rekkefølge): "python3 CreatePingFile.py", "./PingAllAuto.sh" og "python3 PingCreateCSV.py". Ellers er det jo en kjapp sak å legge til sti i alle filnavn.

 

PingAllAuto.sh ser slik ut:

ping 172.16.0.1 -c 100  >> PingAllAuto.txt 
ping 172.16.0.50 -c 100  >> PingAllAuto.txt 
ping 172.16.0.51 -c 100  >> PingAllAuto.txt 
ping 172.16.0.52 -c 100  >> PingAllAuto.txt 
ping 172.16.0.53 -c 100  >> PingAllAuto.txt 
ping 172.16.0.70 -c 100  >> PingAllAuto.txt 
+++

PingAllAuto.txt:

PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=1.83 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=1.19 ms
64 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=1.17 ms
***
64 bytes from 172.16.0.1: icmp_seq=98 ttl=64 time=1.10 ms
64 bytes from 172.16.0.1: icmp_seq=99 ttl=64 time=1.08 ms
64 bytes from 172.16.0.1: icmp_seq=100 ttl=64 time=1.12 ms

--- 172.16.0.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99119ms
rtt min/avg/max/mdev = 0.912/1.372/9.961/1.066 ms
PING 172.16.0.50 (172.16.0.50) 56(84) bytes of data.
64 bytes from 172.16.0.50: icmp_seq=1 ttl=64 time=204 ms
64 bytes from 172.16.0.50: icmp_seq=2 ttl=64 time=1.61 ms
64 bytes from 172.16.0.50: icmp_seq=3 ttl=64 time=1.73 ms
+++

Fra foregående fil hentes det ut statistikk til filen PingAllAuto.fil2

--- 172.16.0.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9009ms
rtt min/avg/max/mdev = 1.081/1.165/1.420/0.092 ms
--- 172.16.0.50 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 1.239/52.221/493.546/147.189 ms
--- 172.16.0.51 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 1.276/11.196/79.029/23.370 ms
+++

..som ender opp i PingAllAuto_yyyymmddhhmm.csv:

ip;transp;recvp;min;avg;max;mdev
172.16.0.1;10;10;1,081;1,165;1,420;0,092
172.16.0.50;10;10;1,239;52,221;493,546;147,189
172.16.0.51;10;10;1,276;11,196;79,029;23,370
+++

Da gjenstår bare å importere til regneark og sette på autofilter så kan der dukke opp noen overraskelser...

 

 

Pythonfilene:

CreatePingFile.pyPingCreateCSV.py

 

Laget for Linux men det burde ikke kreve veldig mye å få til å gå andre platformer...

Endret 21. januar av SveinHa

[SveinHa]

Da begynner jeg å nærme meg noe. 172.16.0.220 er en Arduino MKR 1010 WiFi som har putlet og gått i 2-3 år. Nå har den gitt en mengde TX-Retries. For litt siden skiftet jeg UniFi aksesspunktet som den er tilkoblet uten at det endret noe og i dag kjøpte jeg nytt UniFi AC1200 og da forsvant det meste av TX-Retries i det området. Det forrige aksesspunktet var nytt og ubrukt men noen år gammelt da det ble installert. Så får tiden fortelle om dette var det hele men det føles i alle fall mye bedre nå.