Nebula Vianmääritys – Yleiset ongelmat

Tässä artikkelissa käsitellään yleisimpiä ongelmia – jos laite pysyy offline-tilassa, et näe mitään tietoja/lokeja (PoE, CPU:n käyttö, datan käyttö, lokit jne.), asetuksia ei saada siirrettyä (firmware-hallinta) ja tapahtumalokien käyttöä.

Olemme erittäin iloisia nähdessämme Nebula-pilviratkaisumme saavan jalansijaa kentällä sekä että se on yhä enemmän keskiössä portfoliomme laajentamisessa. Alun perin ”spin-off”-ratkaisuna alkanut järjestelmä on investointiemme ja ennusteidemme mukaisesti muodostunut toimintamme ja tuotteidemme kulmakiveksi. Tämän painopisteen muutoksen myötä Nebula-yhteensopivia laitteita käytetään yhä enemmän ammatillisissa verkkoympäristöissä. Tämä muutos herättää monissa asiakkaissamme kysymyksen: ”Mitä voin tehdä analysoidakseni ongelmani ennen kuin otan yhteyttä johonkuhun muuhun?”

Tämä opas tarjoaa ideoita ja vinkkejä tarkistettavista asioista, jos laitteesi eivät toimi oikein – osa niistä on yleisluonteisia (= parhaiden käytäntöjen esimerkkejä) ja osa hieman teknologia-aluekohtaisia.

Huomautus: Nebula-hallittavia laitteita ei ole tarkoitettu konfiguroitavaksi millään tavalla konsoliyhteyden kautta – käytä SSH-yhteyttä Nebula-laitteisiin vain valvontaa varten ja mahdollisesti yhteistyössä tukemme/T&K-osaston kanssa virheenkorjausmittauksiin.

Laitteet pysyvät offline-tilassa

Kuvittele tilanne – olet rekisteröinyt laitteesi onnistuneesti, ehkä jopa konfiguroinut asetuksia mieleiseksesi ja olet nyt laitteen käyttöönoton vaiheessa. Kuitenkin jostain sinulle vielä tuntemattomasta syystä kyseinen laite ei yksinkertaisesti halua tulla online-tilaan paikan päällä, toimia eikä näyttää olevansa online ja reagoiva.

Tämä on yksi yleisimmistä ongelmista Nebula-laitteiden käyttöönotossa – lyhyesti sanottuna syynä on se, että laitteet oletuksena yrittävät ratkaista osoitteet joko s.nebula.zyxel.com tai d.nebula.zyxel.com. Tämä aiheuttaa kaksi ongelmaa:

1. Useaan kertaan ketjutettu aliverkkotunnus (esim. this.that.andthis.alsothis.domain.com) voi aiheuttaa ongelmia joillekin DNS-palveluntarjoajille
2. Uusien standardien mukaan aliverkkotunnus voi koostua myös yhdestä merkistä, kun aiemmin vaadittiin vähintään kolme merkkiä. Joillakin DNS-palvelimilla on tästä ongelmia.

Usein näemme, että internet-palveluntarjoajien DNS-palvelimilla on ongelmia tämän kanssa. Suosituksemme: vaihda oletus-DNS-palvelin joko 8.8.8.8:ksi tai 1.1.1.1:ksi. Lisätietoja löytyy täältä:

Mitä tehdä, jos Nebula-laitteeni ei pääse online-tilaan / yhteysongelmia / ei kommunikoi NCC:n kanssa?

En näe lainkaan tietoja!

Joskus asiakkaat ottavat meihin yhteyttä valittaen, että he ovat kirjautuneet sisään pitkän tauon jälkeen ja heidän tietonsa ovat joko kadonneet tai ”mitään ei näy”. Tämä voi johtua siitä, että portaalin pidemmän käyttämättömyyden vuoksi organisaatio on asetettu Pilvitallennustilaan, joka käytännössä katkaisee kaiken tiedonkeruun 30 päivän käyttämättömyysjakson jälkeen. Pilvitallennustila ilmoitetaan kehotteella ja bannerilla (vaaleansininen banneri). Ratkaisu: poista Pilvitallennustila käytöstä ja odota muutama minuutti, tiedot palautuvat pian.

Lisätietoa löytyy täältä: Pilvitallennustila (Nebula BASE Pack)

Asetuksia ei siirretä

Sinulla saattaa olla tilanne, jossa laite näyttää olevan online, mutta asetusten muuttaminen ei näytä vaikuttavan? Tarkista firmware! Jotkut muutokset vaativat uusimman firmware-version toimiakseen oikein, ja joskus muutoksia pidätetään tämän vuoksi:

Tämä on täydellinen esimerkki siitä, mitä emme halua nähdä – tässä tapauksessa palomuurin firmware on vanhentunut, ja tämä estää lopulta uusien konfiguraatiokokonaisuuksien käyttöönoton, vaikka kaikki muut tilastot (CPU, RAM-käyttö, asiakasmäärä, online/offline-tila) näyttävät olevan kunnossa. Konfiguraatiolohkojen pidättäminen koskee erityisesti, mutta ei yksinomaan, uusimpaan firmwareen toteutettuja uusia ominaisuuksia. Tämä, DNS-ongelman lisäksi, voi olla hyödyllinen vinkki.

Nebula-valvonta – hyödyllisiä näkymiä käden ulottuvilla!

Valvontatoiminnot tarjoavat todellista hyötyä ja työkaluja valvonta- ja analytiikkavarallesi. Aloitetaan yksinkertaisella – laite näyttää offline-tilassa olevalta, mutta sinusta tuntuu, että se kommunikoi edelleen Nebula-Pilvikeskuksen kanssa oikein? Mene laitteen pääsivulle – yhdyskäytävillä se on:

Devices -> Firewall

ja tee Ping-testi – jos ping-testi onnistuu kertomaan laitteelle "Ping-kohde W.X.Y.Z" ja laite todella vastaanottaa tämän ja voi antaa palautteen onnistuneista pingauksista, tämä tarkoittaa, että laite on edelleen yhteydessä NCC:hen ja offline-tila voi johtua selaimen välimuistista tai evästeongelmasta.

Toinen käytännön esimerkki: useat kytkimen portit näyttävät jatkuvasti tapahtumalokiviestejä, jotka osoittavat vaihtelua 10 Mb/s ja 1 Gb/s yhteyksien välillä, ja olet epävarma, aiheuttaako kytkin ongelmia?

Tarkista MAC-taulu seuraavasti:

Devices > Switches > (valitse Kytkin) > Live Tools > Switch Tables > Run-Button

Sinulla on nyt tietoa, joka voi auttaa – mainitussa käytännön esimerkissä kävi ilmi, että kaikki portit, jotka näyttivät tätä käyttäytymistä, kuuluivat tietylle MAC-valmistajalle, mikä puolestaan viittaa tiettyyn asiakastyypin ongelmaan, ja että kytkin ei ollut viallinen – mahdollinen ratkaisu voisi olla kiinteän nopeuden asettaminen kyseisille asiakkaille ja vastaaville kytkinporteille.

On monia muita esimerkkejä siitä, miten valvonta voi tehdä ihmeitä virheiden ratkaisemiseksi, mutta uskon, että saat idean tästä.

Tapahtumalokien käyttäminen prosessien ”kulissien takana” ymmärtämiseen

Jokaisella teknologia-alueella on omat tapahtumalokit, jotka tarjoavat valtavasti apua syiden selvittämisessä, miksi asiat eivät toimi – erityisesti WiFi-ongelmissa.
Tarkastellaan esimerkkiä WiFi-verkosta, jossa on kolme erilaista merkintää:

Analysoidaan kolme eri kohtaa yksi kerrallaan:

1. Tämä kertoo, että tietty asema, jolla on tietty MAC-osoite, on yhdistänyt kyseiseen tukiasemaan. Yhteys muodostettiin signaalivoimakkuudella -81 dBm, mikä on lopulta liian heikko.
2. Asema on poistunut tietystä SSID:stä, AP:stä ja kanavalta WiFi-syyn 3 vuoksi. WiFi-syykoodit ovat yhtenäisiä koodeja WiFi-käyttäytymisen tunnistamiseen ja ymmärtämiseen. WiFi-syykoodi 3 tarkoittaa yksinkertaisesti, että asema on itse aktiivisesti päättänyt poistua SSID:stä.
3. Tietyllä asiakkaalla on ollut roaming-prosessi (= siirtyminen yhdestä tukiasemasta toiseen).

Tämä on tietenkin vain pintaraapaisu siitä, mitä tapahtumalokit voivat kertoa, mutta se osoittaa, että tapahtumalokit voivat olla tehokas työkalu verkon todellisen tilanteen ymmärtämiseen. Erityisesti WiFi-ongelmien osalta on olemassa lisätyökaluja WiFi-laadun arviointiin, kuten Wireless Health, asiakaslistat jne. Seuraavat artikkelit voivat tarjota lisätietoa tästä aiheesta:

Nebula AP ”Easy Troubleshoot”

Wireless Health -ratkaisu Zyxel Networksilta