Skip to main content

Näköjään taas joudun kysymään..

 

Technicolor CGA2121 siltaavana ja perässä EdgeRouter X lähiomaisella. Systemi on pelittänyt yleensä häiriöittä mutta toisinaan data vaan lakkaa kulkemasta mihinkään ilman että kaapeliyhteys varsinaisesti katkeaa.  Nyt tällä viikolla tämä on sattunut jo kaksi kertaa, aina joskus aamupäivästä, sitä ennen ei kovin usein. Viikkojakin menty täysin häiriöittä joten ei voi oikein olla mikään perustavaa laatua oleva reitittimen conffausvikakaan.


Kävin paikan päällä katsomassa tilannetta. Modeemissa yhteys normaali. Datan saa taas kulkemaan irroittamalla reitittimen ja modeemin välisen 'WAN' kaapelin hetkeksi (tai sammuttamalla reitittimestä asianomainen portti hetkeksi). Pelkkä DHCP renew yksinään ei palauttanut yhteyttä, joka on mielestäni vähän outoa. Vika vaikuttaisi sellaiselta kuin Telian puolella olisi resetoitu joku kytkin, jonka jälkeen se päästä liikenettä läpi ennen kuin näkee uuden DHCP varauksen (IP source guard). Mutta outoa tässä on tosiaan tuo ettei  pelkkä DHCP renew kuitenkaan riittänyt herättämään yhteyttä. Aivan kuin Technicolor katkaisisi yhteyden eikä palauttaisi sitä ennen kuin näkee että perässä oleva laite kävi alhaalla.

 

Onkos muilla ollut vastaavaa / mistä voisi johtua? Epäilen että tämä tulee jostain huoltotöistä koska näitä on sattunut vain arkisin ja toisaalta välillä mentiin monta viikkoa ilman mitään häiriöitä. Vai voiko nyt olla että itse kaapeliyhteydessä on ollutkin joku hetkellinen katkos, mutta erillisen reitittimen kyseessäollessa yhteys ei palaudukaan enää takaisin täysin itsenäisesti?


Onkohan ainoa keino tehdä automaattinen korjaus virittämällä ER-X:lle cron-taski joka pingaisi vaikkapa Telian gatewayta ja yhteyden kadottua käyttäisi reitittimen eth0 porttia hetken alhaalla?

Hei! Kartoitetaas tilannetta hieman, niin päästään tutkimaan johtuisiko katkeilu mahdollisesti huoltotöistä. Missä päin modeemi sijaitsee tai on sijainnut katkoksien aikaan, ja minä päivinä katkoksia on ollut? 
Jos katkoksia esiintyy toistuvasti edelleen, on sinun hyvä kirjata päivämäärät sekä kellonajat ylös, ja kokeilla yhteyden toimivuutta muilla laitteilla, kytkemällä esimerkiksi tietokone ei-sillattuun LAN-porttiin.



 



@VeraEk  kirjoitti:

Hei! Kartoitetaas tilannetta hieman, niin päästään tutkimaan johtuisiko katkeilu mahdollisesti huoltotöistä. Missä päin modeemi sijaitsee tai on sijainnut katkoksien aikaan, ja minä päivinä katkoksia on ollut? Jos katkoksia esiintyy toistuvasti edelleen, on sinun hyvä kirjata päivämäärät sekä kellonajat ylös, ja kokeilla yhteyden toimivuutta muilla laitteilla, kytkemällä esimerkiksi tietokone ei-sillattuun LAN-porttiin.


Katkokset suoraan Unifin alerteista, tällä viikolla eka 8.8.2022 klo 10:06 ja nyt 11.8.2022 klo 11:13 - sitä ennen monta viikkoa ilman ainutakaan häiriötä. Yhteys ei tavitse olla kauaa poikki kun IPsec katkeaa ja silloin alkaa tulla hälyjä mulle tänne lokeihin. Modeemi sijaitsee postinumeroalueella 78850. Modeemissa kaikki portit sillattuna ja veikkaisin että mikä tahansa laite kyllä toimii koska myös ER-X löytää yhteyden heti kun piuhaa käyttää hetkisen irti. Mysteerio on vaan tuo että miksi se lakkaa alun perin välittämästä liikennettä.

 

Näkiköhön CGA2121:sta lokeja mistä löytyisi jos kaapeliyhteys olisi pätkäissyt eli vika olisi nyt siinä että yhteys ei osaa palautua ulkoisen reitittimen kanssa takaisin tämän tapahduttua. Tosin joudun käymään paikan päällä katsomassa sitä koska siihen en pääse IPsecin kautta käsiksi.



@SINAD  kirjoitti:






Katkokset suoraan Unifin alerteista, tällä viikolla eka 8.8.2022 klo 10:06 ja nyt 11.8.2022 klo 11:13 - sitä ennen monta viikkoa ilman ainutakaan häiriötä. Yhteys ei tavitse olla kauaa poikki kun IPsec katkeaa ja silloin alkaa tulla hälyjä mulle tänne lokeihin. Modeemi sijaitsee postinumeroalueella 78850.






Kyseisellä alueella ei ole ollut huoltokatkoja tai muitakaan alueellisia kaapeliverkon häiriöitä, joten niistä tuskin on tässä ollut kyse.




@SINAD  kirjoitti:





Näkiköhön CGA2121:sta lokeja mistä löytyisi jos kaapeliyhteys olisi pätkäissyt eli vika olisi nyt siinä että yhteys ei osaa palautua ulkoisen reitittimen kanssa takaisin tämän tapahduttua. Tosin joudun käymään paikan päällä katsomassa sitä koska siihen en pääse IPsecin kautta käsiksi.






CGA2121 asetuksissa on ainakin DOCSIS Event Log, joka näyttää katsomishetkestä taaksepäin, mutta pidemmän aikavälin logeja ei taida pystyä katsomaan tai tallentamaan. Jos kaapeliyhteydessä on kohinaa, joka yhteysongelmaa aiheuttaa, voi modeemin uudelleenkäynnistys olla tarpeen. Jos ongelma toistuu vain reitittimen kanssa modeemin sillatusta portista, mutta samaan aikaan toimii muista porteista suoraan esim. tietokoneelle, niin modeemissa silloin ongelma tuskin on. Jos ongelma toistuu todistetusti usealla laitteella eri porteista, niin sitten voisin välittää tästä viestiä laitevastaaville ja voisimme yrittää toistaa ongelmaa.



Uutta tietoa eilisen katkoksen perusteella:

 

1. Aiempi lausuntoni ettei DHCP renew palauta yhteyttä on väärä, ER-X reitittimen WebUI:sta paljastui bugi eli renew ajettuna sieltä ei todellisuudessa tee yhtään mitään, mutta renew dhcp interface eth0 ajettuna komentopromptissa palautti yhteyden. Ennen palautusta katsoin kuitenkin leasen tiedot ER-x:ltä ja lease OLI voimassa, eli kyse ei näyttäisi olevan siitä että ER-X ryssisi DHCP:n kanssa nyt jotenkin, se oli siis saanut asianmukaisen leasen aiemmin, eikä se ollut vielä kulunut umpeen.

 

2. Siltaavaksi asetetun CGA2121:n DOCSIS Event Log on täynnä vaikka minkälaista herjaa, mm. lukuisia DHCP FAILED ilmoituksia - mihis nämä muuten liittyy kun modeemi on laitettu siltaavaksi? Mutta siis joka tapauksessa myös modeemi itsessää herjaa DCHP:stä ja ER-X:n yhteyden katoaminen liittyy jotenkin leasen umpeutumiseen ennen aikojaan. Varsinaisia yhteyden katkeamisia ei lokissa mielestäni ole. Pääsettekö katsomaan noita CGA2121:n lokeja etänä vai pitäisikö minun toimittaa niitä?

Tässä muutama herja mitä lokissa esiintyi:

'No Ranging Response received -T3 time-out'

'MDD message timeout'

'SYNC Triming Syncronization failure - Failed to receive MAC SYNC frame within time-out period'

'Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out'

'DHCP failed - Critical field invalid in response' (näitä on todella paljon)

'DHCP failed - Discover sent; no offer received' (näitäkin todella paljon)

'TLV-11 - unrecognized OID'

'DHCP RENEW WARNING - Field invalid in response v4 option'

'Unicast Ranging Received Abort Response - Re-initializing MAC'

 

Unifin lokeihin viimeisin yhteyden katkeaminen on kirjautunut eilen 17.8. klo 16:35 mutta tässä on jonkin verran viivettä ennen kuin Unifi laukoo tuon alertin, esim. laitteet voi lähiomaisen päässä bootata ilman että tuota herjaa ehtii tulla. Mutta siis joka tapauksessa joskus klo 16 jälkeen mennyt jumiin. Tällä kohtaa ei DOCIS lokeissa ole mitään muuta erityistä kuin toistuvia DHCP herjoja klo 13 jälkeen.



@SINAD  kirjoitti:



2. Siltaavaksi asetetun CGA2121:n DOCSIS Event Log on täynnä vaikka minkälaista herjaa, mm. lukuisia DHCP FAILED ilmoituksia - mihis nämä muuten liittyy kun modeemi on laitettu siltaavaksi? Mutta siis joka tapauksessa myös modeemi itsessää herjaa DCHP:stä ja ER-X:n yhteyden katoaminen liittyy jotenkin leasen umpeutumiseen ennen aikojaan. Varsinaisia yhteyden katkeamisia ei lokissa mielestäni ole. Pääsettekö katsomaan noita CGA2121:n lokeja etänä vai pitäisikö minun toimittaa niitä?






Tarkkaa tietoa DHCP FAILED -ilmoituksien triggeristä en tiedä. Olisiko siksi, että modeemi ei itse liikennettä käsittele?  Yhteyden katoamisen syystä on vaikea sanoa näin yhteisön kautta ja sitä olisi tärkeää rajata vielä esim. CGA2121 toisesta LAN-portista, katkeaako yhteys myös silloin muilla laitteilla, jotka ei olekkaan ER-X:n takana? Eli onko yhteysongelmat vain ER-X:n ja siltaavan modeemin välisiä?

Etänä ainakaan täältä Yhteisöstä emme logeja näe, mutta verkkosiantuntijoillamme on kyllä tarvittavat työkalut kaapelimodeemien yhteysongelmien tutkimiseen. Ongelmien jatkuessa myös muista LAN-porteista, on tärkeää ilmoittaa häiriöstä meille. Vain liittymän omistajan tai käyttäjän tekemän häiriöilmoituksen jälkeen voimme tarvittaessa tutkia verkkoliikennetta siltä osin kuin palvelukuvauksen mukaisen toiminnan varmistamiseksi on tarpeen. Eli omien verkkolaitteiden virheilmoituksien/logi -merkintöjen tarkkaa syytä tai niiden liikenteen logimerkintöjä ei tutkita häiriöilmoituksella. Toki niistä voi olla apua yhteysongelman selvittämiseen, eli niistä on tärkeää mainita.



@HenriLie  kirjoitti:


Tarkkaa tietoa DHCP FAILED -ilmoituksien triggeristä en tiedä. Olisiko siksi, että modeemi ei itse liikennettä käsittele?  Yhteyden katoamisen syystä on vaikea sanoa näin yhteisön kautta ja sitä olisi tärkeää rajata vielä esim. CGA2121 toisesta LAN-portista, katkeaako yhteys myös silloin muilla laitteilla, jotka ei olekkaan ER-X:n takana? Eli onko yhteysongelmat vain ER-X:n ja siltaavan modeemin välisiä?


CGA2121:n lokeissa näkyvät DHCP herjat ajoittuvat samoille päiville jolloin ER-X on menettänyt yhteyden! Eli esimerkiksi tämän kuun 11. päivä ja ja nyt jälleen 17. päivä. Valtaosan ajasta noita herjoja ei siis docis lokeissa ole. Eli kyllähän siellä verkossa nyt jotain pielesäs on koska sekä CGA2121 että ER-X näkevät saman ongelman. CGA2121 lokeissa nuo herjat tulee vähän aiemmalla timestampilla (liekö ne sitten UTC ajassa) mutta joka tapauksessa pian tämän jälkeen on IPsec menee alas ja Unifissa alertti. Nähtävästi yhteys myös palautuisi itsekseen kun odottelisi leasen loppua mutta kaapelissa kun on oikeanlainen pitkä lease niin se ei tapahdu heti. Modeemin perässä ei ole mitään muita laitteita kuin ER-X joten tuota pyytämääsi testiä ei voida mitenkään tehdä.

 

Mulla on nyt viimeinen kesälomaviikko menossa eli jatkossa ei ole enempää aikaa alkaa selvitellä tätä. Jotain vikaa selkeästi on olemassa mutta jos se ei lähde tällä etenemään niin ei mahda mitään. Täten päätyin tekemään tähän automaattisen yhteyden palauttamisen eli ER-X pingaa 5 minuutin välein Telian gatewayta ja jos se ei vastaa, ajetaan DHCP renew. Eli ei korjata varsinaista vikaa vaan kierretään se. Pääasia että toimii / palautuu takaisin itsekseen ja mun ei tarvitse keskittyä enää selvittelemään näitä.

 

Ja jos jollakin muulla sattuu olemaan sama ongelma niin tässäpä conffia ER-X:lle, ekana perustetaan scriptifilet:

 

cd /config/user-data
sudo mkdir scripts
sudo chown root scripts
cd scripts
sudo touch linetest.sh
sudo touch dhcprenew.sh
sudo chmod 0755 linetest.sh
sudo chmod 0755 dhcprenew.sh

 

Sitten editoidaan linetest.sh sisällöksi:

ping -c 1 -w 1 80.220.240.1 || /config/user-data/scripts/dhcprenew.sh

 

Ja dhcprenew.sh sisällöksi:

renew dhcp interface eth0
echo >>/home/ubnt/stall.log $(date)

 

Lopuksi tehdään systeemitason ajastin:

configure
set system task-scheduler task LineTest
set system task-scheduler task LineTest crontab-spec '*/5 * * * *'
set system task-scheduler task LineTest executable path /config/user-data/scripts/linetest.sh
commit
save
exit

 

Tämä viritys pitäisi kestää myös firmispäivitykset koska kaikki tulee systeemitason conffeihin. Mahdollisista katkoksista kirjataan ylös aikaleima ubnt käyttäjän kotihakemistoon stall.log nimiseen lokitiedostoon. Jos olet tehnyt muun käyttäjän kuin ubnt niin muuta se tuonne scriptiin echo-komennon perään. Conffitiedostojen editoinnissa tarvitaan jotakin editoria, vi lienee oletuksena mutta jos sen käyttö on liian vaikeaa niin nanonkin voi aina asentaa koska EdgeRouterit ajaa suhteellisen täydellistä Linuxia. Vaatii vaan ekana debianin repositoryn määrittelyn, ohjeet saa Googlella.


Havaittiin ettei tuo automaattikorjaus toiminutkaan tositilanteessa ja vika on on tuossa dhcprenew.sh scriptissä. Yritin korjata tuota yllä olevaa postaustani mutta Yhteisö ei näköjään sen muokkaamista enää. Niinpä vähän hölmösti tässä korjaus nyt ihan erikseen

Elikkäs yllä olevassa postauksessani on dhcprenew.sh sisältö väärin:



renew dhcp interface eth0
echo >>/home/ubnt/stall.log $(date)



 



Selvisi, että TÄMÄ EI TOIMI, koska EdgeOS ei salli tuon renew-komennon ajoa scriptistä käsin tuolla tavoin, vaikka se suoraan komentoriville kirjoitettuna toimiikin. Scripti tuotti ainoastaan virheilmoitusta. Ratkaisuna on ajaa vaadittava komento vyatta-op-cmd-wrapperin kautta, jolloin se toimii (testattu nyt ihan tcpdumpin kanssa että dhcp renew todella tapahtui).

Eli dhcprenew.sh tulee olla:



#!/bin/vbash
/opt/vyatta/bin/vyatta-op-cmd-wrapper renew dhcp interface eth0
echo >>/home/ubnt/stall.log $(date)



 



Echo-komennon voi myös jättää kokonaan pois jos ei halua tapahtuneita yhteyden palauttamisia lokiin. Jos katkoja on usein tai katkos on pitkä eli tuota palautusta ehditään yrittää lukuisia kertoja niin tuon lokin kirjoittelu kuluttaa laitteen flashia koska merkintä toistuu 5 min. välein. Hyvä idea on pitää se ehkä aluksi mukana ja sitten myöhemmin kun kaikki toimii, ottaa se pois.



 



--



 



Muokkaus TeroRe: Muokkasin komentoa käyttäjän pyynnöstä


Vastaa