Jäätävä A T K-räpellys (Algron28:n laitetilaprojekti)

Tuommoinenhan on suhteellisen helposti kaivettavissa. Ainoastaan jos välissä on asvaltti niin sit voi mennä vaikeeks.
Välissä nurmikkoa ja kivituhka päällysteiset pihatiet. En nyt tuota erityisen halvaksi sanoisi kun kaivuu pitää tehdä useampaan taloon. Ehkä siinä vaiheessa tulee mahdolliseksi kun talojen vesi/lämpö linjat saneetataan. Ne kum joutuu kaivamalla vaihtamaan.
 
Täytyy kyllä sanoa, että on kyllä päheet viritykset.

Onko ulkonaolevalta "mastolta" line of sight varsinaiseen asuntoosi?
Mikäli on, niin senhän välin pystyy toteuttamaan myös PTP langattomalla linkillä, esim Ubiquiti - LiteAP™ AC. Sitten vaan asunnon puolelle AirMAX CPE.
Yksi vaihtoehto on myös AirFIber (sillä pystyy toteuttaa 1G+ linkin), mutta maksaa maltaita.

Pyytääkö taloyhtiö tilasta vuokraa vai miten itse tilan käyttökustannukset?
 
Täytyy kyllä sanoa, että on kyllä päheet viritykset.

Onko ulkonaolevalta "mastolta" line of sight varsinaiseen asuntoosi?
Mikäli on, niin senhän välin pystyy toteuttamaan myös PTP langattomalla linkillä, esim Ubiquiti - LiteAP™ AC. Sitten vaan asunnon puolelle AirMAX CPE.
Yksi vaihtoehto on myös AirFIber (sillä pystyy toteuttaa 1G+ linkin), mutta maksaa maltaita.

Pyytääkö taloyhtiö tilasta vuokraa vai miten itse tilan käyttökustannukset?
Langaton linkki on asunnon sijoittumisesta johtuen hieman hankala mutta kyllä sitä vdsl2 linkeillä tuossa on vielä pärjännyt.

Tila on vuokrattu talonyhtiöltä. Hinta on aika edullinen, osittain koska tila on melko pieni. Sähkö on omalla liittymällä/mittaroinnilla.
 
Ja kaivetaas tämä taas naftaliinistä. Tilan ilmanvaihtoa on nyt parannettu joten kesäiset lämpöongelmat toivottavasti helpottavat.

2.jpg



Lisäksi tilaan on tullut uusi "asukki" HPE DL20 GEN10

1.jpg


Laitteeseen on asennettu proxmox ja tänään siirtelin aikaisemmin Dellin palvelimella sijainneen UISP (eli entinen UNMS) virtualisoiduksi tuon uuden päälle. Seuraavaksi on tarkoitus vaihtaa tuohon Delliin SSD vanhan kiintolevyn tilalle ja siirrellä tuossa HPn pöytäkoneessa nyt asusteleva PFsense (joka toimii VPN gatewayna) tuohon Delliin. Tuon HPn pöytäkoneen virtalähteen tuuletin hirtti jo ennen joulua, mutta kone on jaksanut yllättäen toimia ilmankin. Ilmeisesti etulevyn prossan puhallin on sen verran jaksanut ilmaa pyörittää. Kuitenkin kesän kuumia ajatellen tuo siirto on tehtävä.

Samalla tarkoitus katsoa saako tuon PFsensen kanssa toimimaan 10GE SFP+ verkkokorttia joka hyllyltä löytyy. Tuossa DL20 palvelimessa on kans sellainen, mutta pitäisi hommata SFP+ moduleita ja kytkin tms jossa myös 10G portteja. Tuossa Juniperissä periaattessa on, mutta pitäisi jaksaa perehtyä sen konffaukseen. Juniperin laitteet kun ei ole konffauksen suhteen tuttuja. Jostain jos saisi Nokialaisen (tai Alcatelin) SAS kytkimen parilla 10G portilla niin avot. Pitää varmaan alkaa ebayta selaamaan.


Lisäksi en muita olenko postannut tätä aikaisemmin, mutta löysin tuollaisen ulos vedettävän hyllyn joka toimii kätevästi konffi läppärin alustana silloin kuin pitää jotain paikallisesti konffata.

3.jpg
 
Tuossa iskin tuon Juniperin MX80 tulille ja sain naputeltua siihen sen verran peruskonffia että etähallinta pelaa. Sattuuko Tekissä olemaan Junos experttejä? Millähän tyylillä tuota kannattaisi lähteä vääntämään toimimaan ihan paikallisena L2 kytkimenä? jonkinlaisen VPLS palvelun avulla varmaan mutta googletuksen perusteella niitä oli useita eri tyyppisiä ja pitäisi siis saada toimimaan ilman remote päätä. Tarkoitus olisi siis ihan yksinkertaisuudessaan saada servereistä tulevat 10G trunkit tiputettua 1G nopeudelle ja kytkettäväksi olevien reitittimien perään. Tämä sen takia että tuossa on 4kpl 10G portteja + gigasia kortilla.

Tämä on varmaan hyvinkin väliaikainen ratkaisu sillä vaikka tuo MX80 on monipuolinen laite niin sen käyttö tässä tarkoituksessa ei ole oikein perusteltua. Lisäksi se syö tarpeeseen nähden paljon sähköä ja puhkuu myös lämpöä. Tarkoitus on tulevaisuudessa korvata tuo Alcatelin SAS-M joka siis nyt toimii "core kytkimenä" jollain jossa on myös 10G portteja.
 
Eikös JunOS oo suhteellisen samankaltainen kun Ciscon IOS?

Tuossa iskin tuon Juniperin MX80 tulille ja sain naputeltua siihen sen verran peruskonffia että etähallinta pelaa. Sattuuko Tekissä olemaan Junos experttejä? Millähän tyylillä tuota kannattaisi lähteä vääntämään toimimaan ihan paikallisena L2 kytkimenä?

Tämä varmaan auttaa: [MX] How to configure the bridge domain to pass traffic of the same VLAN when interfaces are configured as access ports - Juniper Networks

Itsellä ois kyl mukavaa päästä tutustumaan JunOS:ää ja harjoittelemaan sen käyttöä, mutta muutoin ei oo kyllä mitään hajuakaan.

P.S Mistä löysit MX80:n ja kuinkas paljon sellaisesta joutui maksamaan?
 
Viimeksi muokattu:
Eikös JunOS oo suhteellisen samankaltainen kun Ciscon IOS?



Tämä varmaan auttaa: [MX] How to configure the bridge domain to pass traffic of the same VLAN when interfaces are configured as access ports - Juniper Networks

Itsellä ois kyl mukavaa päästä tutustumaan JunOS:ää ja harjoittelemaan sen käyttöä, mutta muutoin ei oo kyllä mitään hajuakaan.

P.S Mistä löysit MX80:n ja kuinkas paljon sellaisesta joutui maksamaan?
Tuo on saatu lahjoituksena kun erään IT ammattilaisen kanssa kerran tuli puhetta tästä omasta harrastekötöstyksestä ja he olivat omasta käytöstä näitä romuttamassa. En varmaan olisi itse tälläistä alkanut hankkimaan rahalla.

Tuo linkkaamasi ohje varmaan toimii silloin kun kyseessä on untagged likkenne mutta tässä tapauksessa nuo servereitä tulevat yhteydet on VLAN nippuja jotka hajautetaan sitten tuolla myöhemmin mikä minnekkin. Ainakin juniperin ohjeissa näytetään monesti viittavaan siihen että access portti on vain yhden vlanin portti. Mutta tuo bridge domain vaikuttaa lupaavalta hakutermiltä. En mie nyt kovin samanlaiseksi Ciscon kanssa tätä sanoisi. Molemmilla omat termit ja asiat näyttäisi löytyvän hieman eri paikkoihin ryhmiteltynä. Itsellä lisäksi hiertää tuo config tree -tyyli. Jotkut kehuu että se on vähän niinkuin ohjelmointikieli ulkomuodoltaan mutta ehkä just sen takia se sitten tökkiikin itsellä.
 
Viimeksi muokattu:
Tuo on saatu lahjoituksena kun erään IT ammattilaisen kanssa kerran tuli puhetta tästä omasta harrastekötöstyksestä ja he olivat omasta käytöstä näitä romuttamassa. En varmaan olisi itse tälläistä alkanut hankkimaan rahalla.

Tuo linkkaamasi ohje varmaan toimii silloin kun kyseessä on untagged likkenne mutta tässä tapauksessa nuo servereitä tulevat yhteydet on VLAN nippuja jotka hajautetaan sitten tuolla myöhemmin mikä minnekkin. Ainakin juniperin ohjeissa näytetään monesti viittavaan siihen että access portti on vain yhden vlanin portti. Mutta tuo bridge domain vaikuttaa lupaavalta hakutermiltä. En mie nyt kovin samanlaiseksi Ciscon kanssa tätä sanoisi. Molemmilla omat termit ja asiat näyttäisi löytyvän hieman eri paikkoihin ryhmiteltynä. Itsellä lisäksi hiertää tuo config tree -tyyli. Jotkut kehuu että se on vähän niinkuin ohjelmointikieli ulkomuodoltaan mutta ehkä just sen takia se sitten tökkiikin itsellä.

Mikset käytä sitä siinä ominaisuudessa mihin se on tarkoitettu, eli reittimenä/reittämiseen?
 
Mikset käytä sitä siinä ominaisuudessa mihin se on tarkoitettu, eli reittimenä/reittämiseen?

@Algron28 taisi juuri pari viestiä aikaisemmin mainita ne syyt, miksi ei oikein huvittaisi käyttää pidemmän päälle eli:

Tämä on varmaan hyvinkin väliaikainen ratkaisu sillä vaikka tuo MX80 on monipuolinen laite niin sen käyttö tässä tarkoituksessa ei ole oikein perusteltua. Lisäksi se syö tarpeeseen nähden paljon sähköä ja puhkuu myös lämpöä. Tarkoitus on tulevaisuudessa korvata tuo Alcatelin SAS-M joka siis nyt toimii "core kytkimenä" jollain jossa on myös 10G portteja.

Ja jotain niistä MX80 powereista MX5, MX10, MX40, and MX80 Power System - TechLibrary - Juniper Networks
 
Tuo on saatu lahjoituksena kun erään IT ammattilaisen kanssa kerran tuli puhetta tästä omasta harrastekötöstyksestä ja he olivat omasta käytöstä näitä romuttamassa. En varmaan olisi itse tälläistä alkanut hankkimaan rahalla.

Tuo linkkaamasi ohje varmaan toimii silloin kun kyseessä on untagged likkenne mutta tässä tapauksessa nuo servereitä tulevat yhteydet on VLAN nippuja jotka hajautetaan sitten tuolla myöhemmin mikä minnekkin. Ainakin juniperin ohjeissa näytetään monesti viittavaan siihen että access portti on vain yhden vlanin portti. Mutta tuo bridge domain vaikuttaa lupaavalta hakutermiltä. En mie nyt kovin samanlaiseksi Ciscon kanssa tätä sanoisi. Molemmilla omat termit ja asiat näyttäisi löytyvän hieman eri paikkoihin ryhmiteltynä. Itsellä lisäksi hiertää tuo config tree -tyyli. Jotkut kehuu että se on vähän niinkuin ohjelmointikieli ulkomuodoltaan mutta ehkä just sen takia se sitten tökkiikin itsellä.

Jos ymmärsin oikein hakemaasi niin, tee bridge-domain jokaiselle haluamallesi vlanille, ja vlanin reitityspisteeksi irb-interface. Esim näin;

set bridge-domains VLAN100 domain-type bridge
set bridge-domains VLAN100 vlan-id 100
set bridge-domains VLAN100 interface ge-0/1/2.100
set bridge-domains VLAN100 interface xe-0/0/0.100
set bridge-domains VLAN100 routing-interface irb.100

set interfaces irb unit 100 family inet address 1.2.3.4/24
set interfaces ge-0/1/2 unit 100 family bridge
set interfaces ge-0/1/2 unit 100 encapsulation vlan-bridge
set interfaces ge-0/1/2 unit 100 vlan-id 100
jne.
 
Jos ymmärsin oikein hakemaasi niin, tee bridge-domain jokaiselle haluamallesi vlanille, ja vlanin reitityspisteeksi irb-interface. Esim näin;

set bridge-domains VLAN100 domain-type bridge
set bridge-domains VLAN100 vlan-id 100
set bridge-domains VLAN100 interface ge-0/1/2.100
set bridge-domains VLAN100 interface xe-0/0/0.100
set bridge-domains VLAN100 routing-interface irb.100

set interfaces irb unit 100 family inet address 1.2.3.4/24
set interfaces ge-0/1/2 unit 100 family bridge
set interfaces ge-0/1/2 unit 100 encapsulation vlan-bridge
set interfaces ge-0/1/2 unit 100 vlan-id 100
jne.
Pitääs kokeilla viikonloppuna. Pitääpä kattella jostain sellainen sähkönkulutusmittari ja kattella paljonko tuo kuluttaa. Mutta lämpöä se hönkii järettömästi ja meluakin siitä lähtee todella paljon.


Tänään muuten posti toi Verkkiksestä tilatut SFP+ modulit. Ostin Ubiquitin myymiä lähinnä hinnan takia. Toivotaan että toimivat verkkokortin kanssa. Jossain laatikon kätköissä oli XFPt tuohon Juniperiin.
 
Viimeksi muokattu:
set interfaces irb unit 100 family inet address 1.2.3.4/24
Millä logiikalla tuohon kannattaa valita IP osoite? Jos ymmärsin oikein niin jokainen VLANin bridge vaatii oman irb:n ja täten taas osoitteen. Tarkoitushan ei ole tässä vaiheessa että MXsän tarvitsee mitään reitittää vaan L2 läpikulku riittää ja reititys VLANien välillä (niissä jotka tarvii) hoidetaan muualla verkossa.
 
Viimeksi muokattu:
Millä logiikalla tuohon kannattaa valita IP osoite? Jos ymmärsin oikein niin jokainen VLANin bridge vaatii oman irb:n ja täten taas osoitteen. Tarkoitushan ei ole tässä vaiheessa että MXsän tarvitsee mitään reitittää vaan L2 läpikulku riittää ja reititys VLANien välillä (niissä jotka tarvii) hoidetaan muualla verkossa.

Mä koittaisin vlanin mukaan osoittetta testata. Oon itseasiassa just tällä viikolla säheltynyt itse VLAN:ien ja SRX:n kanssa. Eihän se sama asia oo kun sun laite, mutta aika lähellä. Eikä ole mun oma, mutta laina-laite.
 
Millä logiikalla tuohon kannattaa valita IP osoite? Jos ymmärsin oikein niin jokainen VLANin bridge vaatii oman irb:n ja täten taas osoitteen. Tarkoitushan ei ole tässä vaiheessa että MXsän tarvitsee mitään reitittää vaan L2 läpikulku riittää ja reititys VLANien välillä (niissä jotka tarvii) hoidetaan muualla verkossa.

Vedin ehkä omassa ajattelussani mutkia suoraksi ja kirjoittelin vain miten itse tulee yleensä tehtyä. Mutta jos sinulla on reitityspiste muualla verkossa vlaneille, niin jätä routing-interface vain pois ja irb luomatta. Silloin tuo bridge-domain toimii vain L2-kytkimenä.
 
Tuommosen mä nyt sinne naputtelin kokeeksi ja toimii

Koodi:
interfaces {
    xe-0/0/0 {
        vlan-tagging;
        encapsulation extended-vlan-bridge;
        unit 0 {
            vlan-id 42;
        }
    }
    ge-1/1/0 {
        vlan-tagging;
        encapsulation extended-vlan-bridge;
        unit 0 {
            vlan-id 42;
        }
    }
}
bridge-domains {
    YAR {
        domain-type bridge;
        interface xe-0/0/0.0;
        interface ge-1/1/0.0;
    }
}

Tuolla näyttää pelittävän. Varmaan hyvä tapa olisi pitää interfacen unit numerointi yhteneväisenä tuon VLAN numeron kanssa tai ainakin se varmaan helpottaa siinä vaiheessa kun vlaneja on useita.

Kävin muuten ostamassa sellaisen energiankulutusmittarin ja idlenä ilman SFPeitä tuo MX80 riipaisee mittarin mukaan sellaiset mukavat 250w. Vähän on kyllä sellainen "tykillä kärpästä" tunne. Tämä MX80 ilmeisesti jaksaisi vääntää sen 80Gb reitittäen. Pitää miettiä jaksaako tästä alkaa vääntämään pidempiaikaista ratkaisua. Lähinnä se on opettelun vaiva ja kuitenkaan näihin Juniperin vehkeisiin harvemmin törmää. Reitittimet pitää olla kuitenkin erikseen mm. VPN terminointien takia ja koska tähän ei ole mitään sopparia niin päivityksiä ei saa ja laite taitaa muutenkin olla jo iäkkäämpää tekniikkaa niin ei verkon reunalle internettiin päin kehtaa laittaa.
 
Viimeksi muokattu:
Tuolla näyttää pelittävän. Varmaan hyvä tapa olisi pitää interfacen unit numerointi yhteneväisenä tuon VLAN numeron kanssa tai ainakin se varmaan helpottaa siinä vaiheessa kun vlaneja on useita.

Tämä on mielestäni kyllä aivan ehdoton sääntö, mikäli vlaneja on laitteella enemmän kuin yksi. Joskus perus SRXiä ja sen vlaneja tutkiessa törmää hirvityksiin kuten "set vlans vlan3 vlan-id 13 l3-interface irb.31", joilla saa kyllä troubleshoottauksessa ärräpäät lentämään samantien.

Hyvä että lähti pelittämään, vaikka kuten itse totesitkin, onhan tuo vähän järeä laite tekemään pelkkää kytkentää.
 
Kun sulla noita laitteita ja softia tuntuu olevan niin millä meinaat hoitaa keskitetyn monitoroinnin ja hälytykset esim meiliin. Itse katsellut zabbixia tähän tarkoitukseen ja hyvältä vaikuttaa. Resurssien ja palveluiden monitorointi tapahtuu järjestelmään asennettavilla agenteilla ja templateilla joita tuntuu löytyvän ihan pirusti kaikenlaisille verkkolaitteille ja käyttiksille, Aika samanlaiselta vaikuttaa kuin nagios.
 
Kyllä se aika heiveröisellä pohjalla on. Käytännössä tällä hetkellä ainoa keskitetty valvonta on UNMS joka tosin ei-ubiquiti laitteiden kohdalla osaa vain pingillä valvoa (aikanaan Ubi kyllä lupaili kolmannen osapuolen tukea mm. SNMP muodossa ja osaa se hakea porttitiedot laitteesta tuolla mutta Ubin ison suunnanmuutoksen jälkeen on ollut aika hiljaista tuon saralla.) Keskitettyä valvontaa enemmän kaipaisi kyllä jotain kätevää tapaa saada dokumentoitua verkon fyysinen ja looginen rakenne.
 
Kun sulla noita laitteita ja softia tuntuu olevan niin millä meinaat hoitaa keskitetyn monitoroinnin ja hälytykset esim meiliin. Itse katsellut zabbixia tähän tarkoitukseen ja hyvältä vaikuttaa. Resurssien ja palveluiden monitorointi tapahtuu järjestelmään asennettavilla agenteilla ja templateilla joita tuntuu löytyvän ihan pirusti kaikenlaisille verkkolaitteille ja käyttiksille, Aika samanlaiselta vaikuttaa kuin nagios.
Itse käytän oman kotiverkon ja laitteiden monitorointiin Zabbixia. Meillä on zabbix myös töissä käytössä joten oli helppo lähteä sillä omaakin valvontaa tekemään. Nagios on omasta mielestäni hankalampi, tosin joissakin jutuissa ehkä parempi. On noita aika monta muutakin vastaavaa ilmaista mutta itse totesin Zabbixin helpoimmaksi.

Viestejä itselläni lähtee tarpeen mukaan sähköpostiin, tekstarina ja telegramina ja laitteita tosiaan on kotiverkossakin valvonnassa ihan kohtalaisesti. Muutamana esimerkkinä mainittakoon proxmox-virtualisointialusta ja sen virtuaalikoneet, pöytäkone, muutama raspberry pi, muutama kotiautomaation ESP32:sta, hallittavia kytkimiä, pari UPSia, kaapelimodeemi, muutama valvontakamera, AV-laitteita jne. Tällä hetkellä liki 100 hostia valvonnassa. Joukossa on kaikenlaisia "virtuaalilaitteitakin" kuten muutama asia mitä ihan kyselen netistä kuten käyttämieni DNS-serverien tila jne. Itse olen aika paljon tehnyt noita templateja ja omia valvontoja kun nuo vakiona olevat eivät riittäneet alkuunkaan.

Graafeja taas minulla piirtelee vasteajoista sun muista Grafana joka on kanssa aika simppeli työkalu. Verkkodokumentaatiota itse pidän OpenDCIM:ssä johon saa räkkikuvat, johdotukset sun muut kivasti. Ei paras mahdollinen mutta itselleni riittävä. Vastaavia työkaluja varmaan löytynee hakusanoilla DCIM tai IPAM.
 
Itse käytän oman kotiverkon ja laitteiden monitorointiin Zabbixia. Meillä on zabbix myös töissä käytössä joten oli helppo lähteä sillä omaakin valvontaa tekemään. Nagios on omasta mielestäni hankalampi, tosin joissakin jutuissa ehkä parempi. On noita aika monta muutakin vastaavaa ilmaista mutta itse totesin Zabbixin helpoimmaksi.

Viestejä itselläni lähtee tarpeen mukaan sähköpostiin, tekstarina ja telegramina ja laitteita tosiaan on kotiverkossakin valvonnassa ihan kohtalaisesti. Muutamana esimerkkinä mainittakoon proxmox-virtualisointialusta ja sen virtuaalikoneet, pöytäkone, muutama raspberry pi, muutama kotiautomaation ESP32:sta, hallittavia kytkimiä, pari UPSia, kaapelimodeemi, muutama valvontakamera, AV-laitteita jne. Tällä hetkellä liki 100 hostia valvonnassa. Joukossa on kaikenlaisia "virtuaalilaitteitakin" kuten muutama asia mitä ihan kyselen netistä kuten käyttämieni DNS-serverien tila jne. Itse olen aika paljon tehnyt noita templateja ja omia valvontoja kun nuo vakiona olevat eivät riittäneet alkuunkaan.

Graafeja taas minulla piirtelee vasteajoista sun muista Grafana joka on kanssa aika simppeli työkalu. Verkkodokumentaatiota itse pidän OpenDCIM:ssä johon saa räkkikuvat, johdotukset sun muut kivasti. Ei paras mahdollinen mutta itselleni riittävä. Vastaavia työkaluja varmaan löytynee hakusanoilla DCIM tai IPAM.
Kuulostaa juuri sellaiselta mitä itse ajan takaa. Ehkä tyhmiä kysymyksiä zabbixista, mutta menköön
Miten sähköpostihälytykset toimivat, ilmeisesti perustuvat templatejen triggereihin joita kysellään aina välillä ja jos triggerin tila muuttuu lähtee siitä hälytys, olisiko heittää esimerkkinä jotain meilihälytyksen konffia niin pääsisi vähän kiinni miten nuo toimivat. Miten templateja voi itse kirjoittaa. Meneekö koodaamiseksi vai selkeää skriptikieltä. Oletko löytänyt hyvää tapaa virtuaalikoneiden päivitysten valvontaan ja siitä ilmoittamiseen, varmaan joku kiva template tähänkin on olemassa?
 
Kuulostaa juuri sellaiselta mitä itse ajan takaa. Ehkä tyhmiä kysymyksiä zabbixista, mutta menköön
Miten sähköpostihälytykset toimivat, ilmeisesti perustuvat templatejen triggereihin joita kysellään aina välillä ja jos triggerin tila muuttuu lähtee siitä hälytys, olisiko heittää esimerkkinä jotain meilihälytyksen konffia niin pääsisi vähän kiinni miten nuo toimivat. Miten templateja voi itse kirjoittaa. Meneekö koodaamiseksi vai selkeää skriptikieltä. Oletko löytänyt hyvää tapaa virtuaalikoneiden päivitysten valvontaan ja siitä ilmoittamiseen, varmaan joku kiva template tähänkin on olemassa?
Hälytykset eli Actionit toimivat niin että käydään tekemässä uusi Action johon määritellään Trigger tai useampi tyyliin "Trigger name contains Update" kuten itselläni linux-päivitysilmoituksissa, määritellään sille vastaanottajat, millä medialla lähetetään (SMS, email, telegram tms tai vaikka ajetaan joku skripti) ja millainen teksti lähetetään. Tuohon tekstiin voi laittaa triggerin nimeä, hostin nimeä, IP-osoitetta, päivämäärää, kellonaikaa sun muita makroilla ja määritellään lähetysviive, eli jos triggeri kuittaantuu ennen viiveen loppumista, kyseistä Actionia ei suoriteta. Triggerin palautukseen saa myös viestin halutessaan.

Templatet ovat oikeastaan ihan item-kokoelmia eli jos jollekin hostille tekee itemin joka vaikka hakee päivitysten määrän niin siitä voi tehdä templaten. Templaten etu on, että jos jotain asiaa muuttaa siinä niin sen muutokset päivittyvät kaikkiin hosteihin joissa tuo template on käytössä. Ja tosiaan ei tarvitse varsinaisesti koodata enkä sanoisi edes oikeastaan skriptikieleksi. Zabbixissa on paljon valmiita sisäisiä checkejä eli laitetaan vain asian keyword niin se hakee sen asian määritellyltä hostilta. Esim SNMP-kyselyyn ei tarvita kuin tietää kysyttävän asian OID ja SNMP Community niin loput hoituu oikeastaan automaattisesti.

Itsellä on pääsääntöisesti Debian-pohjaisia VM:iä ja Debianille löytyy ihan valmiit APT-templatet ja skriptit Zabbix Share -palvelusta (josta löytyy vähän pirusti muitakin, hyviä ja huonoja templateja)

Ja huomiona tähänkin, älä käytä niitä zabbixin mukana tulevia oletus-templateja suoraan, ne on vain esimerkkejä ja niitä kannattaa vähän säädellä omaan käyttöön sopivammaksi esim pollausvälien ja triggerien herkkyyden suhteen.
 
Hälytykset eli Actionit toimivat niin että käydään tekemässä uusi Action johon määritellään Trigger tai useampi tyyliin "Trigger name contains Update" kuten itselläni linux-päivitysilmoituksissa, määritellään sille vastaanottajat, millä medialla lähetetään (SMS, email, telegram tms tai vaikka ajetaan joku skripti) ja millainen teksti lähetetään. Tuohon tekstiin voi laittaa triggerin nimeä, hostin nimeä, IP-osoitetta, päivämäärää, kellonaikaa sun muita makroilla ja määritellään lähetysviive, eli jos triggeri kuittaantuu ennen viiveen loppumista, kyseistä Actionia ei suoriteta. Triggerin palautukseen saa myös viestin halutessaan.

Templatet ovat oikeastaan ihan item-kokoelmia eli jos jollekin hostille tekee itemin joka vaikka hakee päivitysten määrän niin siitä voi tehdä templaten. Templaten etu on, että jos jotain asiaa muuttaa siinä niin sen muutokset päivittyvät kaikkiin hosteihin joissa tuo template on käytössä. Ja tosiaan ei tarvitse varsinaisesti koodata enkä sanoisi edes oikeastaan skriptikieleksi. Zabbixissa on paljon valmiita sisäisiä checkejä eli laitetaan vain asian keyword niin se hakee sen asian määritellyltä hostilta. Esim SNMP-kyselyyn ei tarvita kuin tietää kysyttävän asian OID ja SNMP Community niin loput hoituu oikeastaan automaattisesti.

Itsellä on pääsääntöisesti Debian-pohjaisia VM:iä ja Debianille löytyy ihan valmiit APT-templatet ja skriptit Zabbix Share -palvelusta (josta löytyy vähän pirusti muitakin, hyviä ja huonoja templateja)

Ja huomiona tähänkin, älä käytä niitä zabbixin mukana tulevia oletus-templateja suoraan, ne on vain esimerkkejä ja niitä kannattaa vähän säädellä omaan käyttöön sopivammaksi esim pollausvälien ja triggerien herkkyyden suhteen.
Kuulostaa hyvältä
Olisiko heittää suoraa linkkiä johonkin aptin päivitystemplateen. Miten olet hoitanut kaapelimodeemin valvonnan, tuo oma sagencomin purkki ei ainakaan oletuksena näytä tukevan snmp:tä. Ilmeisesti ttemplateiden readmeissa on listatu triggerit mitä voidaan käyttää ettei mene arvailuksi?
 
Kuulostaa hyvältä
Olisiko heittää suoraa linkkiä johonkin aptin päivitystemplateen. Miten olet hoitanut kaapelimodeemin valvonnan, tuo oma sagencomin purkki ei ainakaan oletuksena näytä tukevan snmp:tä. Ilmeisesti ttemplateiden readmeissa on listatu triggerit mitä voidaan käyttää ettei mene arvailuksi?
Tämä taitaa itsellä olla käytössä debianin päivityksiä katselemassa:

Kaapelimodeemin (joku Arris) eri parametrit käyn ihan sen hallintasivulta hakemassa parsimalla suoraan hallintasivun html-koodista eri kanavien tehot, snr-arvot sun muut. Sellainen varmaan noin 200 itemiä tulee dataa pelkästään siitä.

Templateissa tulee yleensä itemit ja triggerit valmiina, senkun tarvittaessa hienosäätää omaan ympäristöön sopivaksi. Jotkut vaativat sitten esim agentin asetuksiin jotain rimpsuja mutta yleensä varsin hyvin noissa on dokumentaatiota mukana ja jos ei ole, niin tuskin itse templatekaan kovin hyvin toimii.

edit:
Nyt tämä kyllä alkaa vähän menemään ohi alkuperäisen aiheen, varmaan jatkossa olisi hyvä tehdä oma ketju tälle zabbix-keskustelulle...
 
Ei mua sinäänsä haittaa. Tuo zabbix vaikuttaa kiinnostavalta. Pitää varmaan itsekkin kokeilla.
 
Tämä taitaa itsellä olla käytössä debianin päivityksiä katselemassa:

Kaapelimodeemin (joku Arris) eri parametrit käyn ihan sen hallintasivulta hakemassa parsimalla suoraan hallintasivun html-koodista eri kanavien tehot, snr-arvot sun muut. Sellainen varmaan noin 200 itemiä tulee dataa pelkästään siitä.

Templateissa tulee yleensä itemit ja triggerit valmiina, senkun tarvittaessa hienosäätää omaan ympäristöön sopivaksi. Jotkut vaativat sitten esim agentin asetuksiin jotain rimpsuja mutta yleensä varsin hyvin noissa on dokumentaatiota mukana ja jos ei ole, niin tuskin itse templatekaan kovin hyvin toimii.

edit:
Nyt tämä kyllä alkaa vähän menemään ohi alkuperäisen aiheen, varmaan jatkossa olisi hyvä tehdä oma ketju tälle zabbix-keskustelulle...
jos ketjun perustajalle on ok niin jatketaan vielä hieman tässä ketjussa. Voinko lisätä zabbixin meilihälytykseen suoraan itemejä vai onko mahdollista lisätä pelkästään triggereitä. Tuota linkkaamasi templatea esimerkkinä käyttäen jos haluaisin päivitysten tarkistamisesta hälytykset meiliin lisäisin itemit non-critical updates sekä security updates jotka ajaisivat niihin liitetyt triggerit. Olenko ihan hakoteillä, pikkuhiljaa tätä zabbixin toimintalogiikkaa rupeaa ehkä ymmärtämään.
 
Itsellä ainakin kiinnostaa tuo telegram implementaatio sillä oman kokemuksen mukaan sähköposti ei aina ole se luotettavin väline jos pitää nopeasti reagoida.
 
Telegramissa on myös se hyvä puoli, että ne notifikaatiot saa mutelle kun tarpeeksi tiukat valvontarajat alkaa ärsyttää... :lol:
 
Niin siis esim tuossa APT-päivitystarkistuksessa on kolme itemiä (ainakin itselläni, en ole varma olenko muokannut tuota itse), eli Securityupdates, Non-critical updates ja Reboot required. Nämä itemit päivittyvät määritellyllä aikavälillä automaattisesti, itselläni taitaa olla kerran vuorokaudessa ja jos päivityksiä on, näiden triggerit liipaistuu. Jos nämä triggerit on määritelty johonkin actioniin niin siinä tapauksessa niistä lähtee tieto halutulla medialla, esimerkiksi sähköpostilla.

Eli actionit ovat niitä jotka hoitavat tuota ilmoittamista ja triggerit taas aktivoivat noita actioneita. Vastavasti triggerit liipaistuvat halutuista itemien arvoista eli jos haluaisin että pitää olla yli 5 päivitystä tarjolla niin se on mahdollista. Tai sitten voi tehdä monimutkaisempia triggereitä joka liipaistuu vaikka jos on yksikin security update tai vähintään 5 tavallista päivitystä.

Itselläni on telegram ollut niin kauan käytössä zabbixissa että silloin siinä ei vielä ollut virallista tukea. Luulisin että se virallinen tuki toimii vähintään yhtä hyvin kuin itse itselleni Telegram APIn ja pythonin avulla rakentelemani joka on käytössä sekä itselläni että duunipaikan zabbixissa. Meillä välillä tulee kymmeniä hälytyksiä pienen ajan sisällä ja ensimmäinenkään hälytys ei ole tietääkseni jäänyt tulematta läpi jos vaan zabbix-serverillä on ollut yhteys internetin suuntaan. Toki kun tulee paljon hälytyksiä joilla on monta vastaanottajaa niin lähetyksessä kestää minuuttikaupalla kun nuo lähetetään yksitellen peräkkäin (en sitten tiedä osaako virallinen telegram-tuki lähettää rinnakkain). Yksittäinen viesti kyllä tulee sekunneissa.
 
Telegramissa on myös se hyvä puoli, että ne notifikaatiot saa mutelle kun tarpeeksi tiukat valvontarajat alkaa ärsyttää... :lol:
Juu, tai kun käy niinkuin duunissa joku aika sitten... Verkot rupesivat heilumaan ja ensin rupesi kaikki palvelut pätkimään yksitellen kunnes yhteydet nousivat ylös, palvelut nousivat ylös jne ja sitten taas kaikki romahti peräjälkeen. Ilmoituksia tuli keskellä yötä meidän tiimille satoja ja puhelin olisi piipannut varmaan toista tuntia yhtämittaa ellei olisi pistänyt noita mutelle :D Oli sen verran hässäkkää ettei paljon zabbixin päästä kerinnyt lisähälytyksiä blokata...
 
Niin siis esim tuossa APT-päivitystarkistuksessa on kolme itemiä (ainakin itselläni, en ole varma olenko muokannut tuota itse), eli Securityupdates, Non-critical updates ja Reboot required. Nämä itemit päivittyvät määritellyllä aikavälillä automaattisesti, itselläni taitaa olla kerran vuorokaudessa ja jos päivityksiä on, näiden triggerit liipaistuu. Jos nämä triggerit on määritelty johonkin actioniin niin siinä tapauksessa niistä lähtee tieto halutulla medialla, esimerkiksi sähköpostilla.

Eli actionit ovat niitä jotka hoitavat tuota ilmoittamista ja triggerit taas aktivoivat noita actioneita. Vastavasti triggerit liipaistuvat halutuista itemien arvoista eli jos haluaisin että pitää olla yli 5 päivitystä tarjolla niin se on mahdollista. Tai sitten voi tehdä monimutkaisempia triggereitä joka liipaistuu vaikka jos on yksikin security update tai vähintään 5 tavallista päivitystä.

Itselläni on telegram ollut niin kauan käytössä zabbixissa että silloin siinä ei vielä ollut virallista tukea. Luulisin että se virallinen tuki toimii vähintään yhtä hyvin kuin itse itselleni Telegram APIn ja pythonin avulla rakentelemani joka on käytössä sekä itselläni että duunipaikan zabbixissa. Meillä välillä tulee kymmeniä hälytyksiä pienen ajan sisällä ja ensimmäinenkään hälytys ei ole tietääkseni jäänyt tulematta läpi jos vaan zabbix-serverillä on ollut yhteys internetin suuntaan. Toki kun tulee paljon hälytyksiä joilla on monta vastaanottajaa niin lähetyksessä kestää minuuttikaupalla kun nuo lähetetään yksitellen peräkkäin (en sitten tiedä osaako virallinen telegram-tuki lähettää rinnakkain). Yksittäinen viesti kyllä tulee sekunneissa.
okei, eli actioneihin liitetään aina itemien triggereitä, ei koskaan itemejä. Ilmeisesti itimet ovat vain helpottamassa trigerien luettelointia, niitä ei siis käytetä esim meilihälytyksissä vaan vedetään aina triggereillä. Alkaa toimintalogiikka selviämään, huomenna voisi vetää ensimmäiset hostit tulille. Onko sinulla käytössä noita zabbixin omia ttemplateja vai käytätkö kolmanne osapuolen templateja pelkästään. Ovatko nuo zabbixin omat templatet mistään kotoisin hieman säädettynä esim virtuaalikoneiden kuormituksen tarkkailuun.
 
Kuten tuossa aiemmin mainitsin, mulla on aika paljon hosteja valvonnassa (ja osa ihan vaan keräämässä dataa esim grafanaa varten, ei ole jaksanut erillistä tietokantaa niille laittaa) ja on tuo zabbix ollut jo pidemmän aikaa ajossa, joten on vähän kaikenlaista templatea käytössä. Aluksi oli paljon noita vakiojuttuja käytössä mutta mitä pidempään tuota on käyttänyt, sen enemmän omaa tulee mukaan.

Paljon on ihan noita vakio-templatejakin pienellä hienosäädöllä, esim jotain ICMP ja SNMP -templateja sekä jotain hallittaviin kytkimiin liittyviä, taitaa se Linux-templatekin olla ihan käyttökelpoinen. Jonkun verran on tuolta Zabbix Sharesta poimittuja, kuten tuo APT-template mutta vilkaisin juuri sitä ja olen näyttää sitäkin hieman muokannut omaan käyttöön paremmin sopivaksi. Sitten kun sattuu olemaan kaikkea vähän eksoottisempaa ja ehkä pikemminkin sellaista rautaa jota välttämättä ei ole edes alunperin ajateltu zabbixilla valvoa niin on paljon templateita joita olen tehnyt alusta asti itse. Tietty jos tiedän että jotain laitetta ei koskaan tule toista kappaletta, en välttämättä edes jaksa tehdä erillistä templatea vaan teen itemit, triggerit sun mut suoraan hostikohtaisesti.

Lisäksi itselläni on aika paljon kaikenlaisia bash- ja python-skriptejä jotka jollakin tavalla liittyvät zabbixiin tulevaan dataan tai vastaavaan.

Duunissa on varmaankin puolet käytössä olevista templateista minun itseni tekemiä, me kun töissä vähän "väärinkäytetään" zabbixia eli meillä muunmuassa tulee kaikenlaista SIA- ja SNAP-protokollien dataa sun muuta jännää zabbixiin. Viimeksi tänään rakentelin etätallentimien kameravikailmoituksille skriptiä joka kääntää tallentimien käyttämän API:n sellaiseen muotoon että sieltä tulevan datan voi työntää zabbixiin. Ja siitä sitten taas edelleenlähetetään vikatikettejä eri puolille suomea asentajille.
 
Tämä on mielestäni kyllä aivan ehdoton sääntö, mikäli vlaneja on laitteella enemmän kuin yksi. Joskus perus SRXiä ja sen vlaneja tutkiessa törmää hirvityksiin kuten "set vlans vlan3 vlan-id 13 l3-interface irb.31", joilla saa kyllä troubleshoottauksessa ärräpäät lentämään samantien.

Hyvä että lähti pelittämään, vaikka kuten itse totesitkin, onhan tuo vähän järeä laite tekemään pelkkää kytkentää.
Mie nyt hieroin tuota konffia hieman oikeaoppisempaan suuntaan ja onnistuin lisäämään jopa untagged interface tuohon bridgeen.

Koodi:
interfaces {
    xe-0/0/0 {
        vlan-tagging;
        encapsulation extended-vlan-bridge;
        unit 42 {
            vlan-id 42;
        }
    }
    ge-1/0/9 {
        encapsulation ethernet-bridge;
        unit 0 {
            family bridge;
        }
    }
    ge-1/1/0 {
        vlan-tagging;
        encapsulation extended-vlan-bridge;
        unit 42 {
            vlan-id 42;
        }
    }
    fxp0 {
        unit 0 {
            family inet {
                address 10.17.35.23/27;
            }
        }
    }
}
routing-options {
    static {
        route 10.17.31.0/27 {
            next-hop 10.17.35.1;
            no-readvertise;
        }
    }
}
bridge-domains {
    YAR {
        domain-type bridge;
        vlan-id 42;
        interface ge-1/1/0.42;
        interface xe-0/0/0.42;
        interface ge-1/0/9.0;
    }
}

Tuo Juniperin konffin tarkistus commitin yhteydessä on ihan fiksusti toimiva kun se näyttää aika selkeästi kertovan mikä konffissa vikana. Ei ole niinkuin joku Allied telesis kytkin jota kerran koitin konffata kun se vain kitisi aina mallia "VMP" eikä help tai ? komento tehnyt mitään muuta kuin listasi käytössä olevat komennot kertomatta mitä ne tekevät.

Ei vaan kovin isoja konffi kokonaisuuksia kerralla kehtaa tehdä kun se paikkaillu SSH yli on vaivalloista. Jos olisi joku editori joka näyttäisi konffin kokonaisuutena niin ei se varmaan sitten olisi paha. En tiedä onko Juniperillä tuollainen niiden jossain omassa hallintasoftassa.
 
Tuo Juniperin konffin tarkistus commitin yhteydessä on ihan fiksusti toimiva kun se näyttää aika selkeästi kertovan mikä konffissa vikana. Ei ole niinkuin joku Allied telesis kytkin jota kerran koitin konffata kun se vain kitisi aina mallia "VMP" eikä help tai ? komento tehnyt mitään muuta kuin listasi käytössä olevat komennot kertomatta mitä ne tekevät.
Heh, nuo laitteet jotka vaan ilmoittavat "Configuration errors!" tms on aina yhtä kivoja. Muutaman kerran on jahdannut jonkun laitteen konfiguraatiosta virhettä varmaan tunnin eikä tuntunut löytyvän ja sitten kun kirjoitti koko konffan vaan alusta uusiksi niin sitten mystisesti toimi. Tuo on nykyään niin luksusta jos joku kertoo että "en ymmärrä tätä riviä", "virhe on jossain rivin 37 lähistöllä", "väärä määrä sulkeita" tai edes jotain vastaavaa. Joku vekotin oli vielä niin hauska että otti virheellisen konffan sisäänsä ja bootin jälkeen vaan päätti olla kokonaan toimimatta. Ja eikun factory reset ja uudestaan...
 
Juniperillä kyllä näyttää olevan varsin hyvät sepostukset esimerkkeineen omilla nettisivuillaan ja tottakai se hinnassa näkyy (tällä MX80 lienee uutena ollu 5 numeroinen hintalappu) mutta se että laitteen ja ohjelmiston toiminnallisuudet on selkeästi saatavilla ja dokumentoitu kielii kyllä minusta valmistajan sitoutumisesta tuotteeseensa.

Tämän MX80 käyttöönotto on aiheuttanut yllättävän ilmiön. Se kun puhaltaa sivulta sivulle niin tuntuu että tuon laitekaapin ilmankierto ei nyt sen takia oikein toimi fiksusti. Kaapissa on ilmareiät etuovessa ja varmaan alkupäinen ajatus on ollut edestä sisään ja takaa/ylhäältä ulos. Nyt tuntuu että tuo Juniper pyörittää tuota lämmintä ilmaa vain kaapin sisällä. Takaovihan tuosta on poistettu. Ei kait se muuten mutta lähtee vain entistä enemmän mökää.
 
Kuten tuossa aiemmin mainitsin, mulla on aika paljon hosteja valvonnassa (ja osa ihan vaan keräämässä dataa esim grafanaa varten, ei ole jaksanut erillistä tietokantaa niille laittaa) ja on tuo zabbix ollut jo pidemmän aikaa ajossa, joten on vähän kaikenlaista templatea käytössä. Aluksi oli paljon noita vakiojuttuja käytössä mutta mitä pidempään tuota on käyttänyt, sen enemmän omaa tulee mukaan.

Paljon on ihan noita vakio-templatejakin pienellä hienosäädöllä, esim jotain ICMP ja SNMP -templateja sekä jotain hallittaviin kytkimiin liittyviä, taitaa se Linux-templatekin olla ihan käyttökelpoinen. Jonkun verran on tuolta Zabbix Sharesta poimittuja, kuten tuo APT-template mutta vilkaisin juuri sitä ja olen näyttää sitäkin hieman muokannut omaan käyttöön paremmin sopivaksi. Sitten kun sattuu olemaan kaikkea vähän eksoottisempaa ja ehkä pikemminkin sellaista rautaa jota välttämättä ei ole edes alunperin ajateltu zabbixilla valvoa niin on paljon templateita joita olen tehnyt alusta asti itse. Tietty jos tiedän että jotain laitetta ei koskaan tule toista kappaletta, en välttämättä edes jaksa tehdä erillistä templatea vaan teen itemit, triggerit sun mut suoraan hostikohtaisesti.

Lisäksi itselläni on aika paljon kaikenlaisia bash- ja python-skriptejä jotka jollakin tavalla liittyvät zabbixiin tulevaan dataan tai vastaavaan.

Duunissa on varmaankin puolet käytössä olevista templateista minun itseni tekemiä, me kun töissä vähän "väärinkäytetään" zabbixia eli meillä muunmuassa tulee kaikenlaista SIA- ja SNAP-protokollien dataa sun muuta jännää zabbixiin. Viimeksi tänään rakentelin etätallentimien kameravikailmoituksille skriptiä joka kääntää tallentimien käyttämän API:n sellaiseen muotoon että sieltä tulevan datan voi työntää zabbixiin. Ja siitä sitten taas edelleenlähetetään vikatikettejä eri puolille suomea asentajille.
Miten muuten valvot AV-laitteita zabbixilla, harvemmin noissa on virallista SNMP-tukea. Pitäisi varmaan luoda zabbixille ja muille monitorointiratkaisuille oma keskustelunsa.
 
Miten muuten valvot AV-laitteita zabbixilla, harvemmin noissa on virallista SNMP-tukea. Pitäisi varmaan luoda zabbixille ja muille monitorointiratkaisuille oma keskustelunsa.
Mulla on aikalailla kaikki jotain käytöstä poistettuja ammattilaitteita, esimerkiksi jostakin koulusta tai kauppakeskuksesta purettua tavaraa tms, niissä on vähän paremmin noita valvontamahdollisuuksia. Pingillä tietty ensisijaisesti valvon että koko laite edes on jotenkin hengissä jos sattuu olemaan IP-liitäntäinen laite ja sitten olen ihan itse koodaillut eri laitteiden protokollille suoraan omia kyselyitä. Sarjaporttilaitteissa vastaavasti ihan sarjaportin kautta olen kysellyt laitteen tilaa ja joistakin laitteista löytyy tila- ja vikakärkiä joita olen sitten RaspberryPi:n kautta lueskellut.

Tähän hommaanhan tietty mulla liittyy myös muunmuassa HomeAssistant ja zabbix juttelee HA:n kanssa edestakaisin joten sitä kautta tulee joiltakin laitteilta vika- ja tilatietoja ja HA taas vastaavasti tekee jotain asioita zabbixista löytyvien tietojen mukaan, muunmuassa zabbixin actioneiden kautta skriptejä ajamalla sekä suoraan zabbixin APIa hyödyntäen.

Toisin sanoen, mulla on pirusti kaikkia pieniä itse tehtyjä protokollasovituksia suuntaan jos toiseen ja ennen kuin otin HomeAssistantin:n käyttöön niin oli vielä enemmän kun koko kotiautomaatio oli itse koodattua.
 
Jos JunOS kirjallisuus kiinnostaa niin multa löytys JunOS Routing Essentials ja JunOS for Security Plattforms sekä labra juttuja noille,
nää majailee Hämeenlinnassa jos kiinnostaa hinta 0€.

Myös joitakin Cisco Reititys/Kytkin manuskoja.
 
Jos JunOS kirjallisuus kiinnostaa niin multa löytys JunOS Routing Essentials ja JunOS for Security Plattforms sekä labra juttuja noille,
nää majailee Hämeenlinnassa jos kiinnostaa hinta 0€.

Myös joitakin Cisco Reititys/Kytkin manuskoja.
Kiitos tarjouksesta. Tuo JunOS routing essentials voisi kiinnostaa. Security platform ei taida omalla kohdalla olla tarpeellinen vaan se taitaa olla muille Juniperin alustoille. Tähän MX laitteeseenkin saa persiiseen jonkun service MIC kortin jolla saisi käyttöön hienostuneemmat palomuuritoiminnot sekä erilaisia VPN muotoja käytettäväksi.



Tuossa kun oli puhetta aikaisemmin siitä konffin tarkistuksesta niin tässä vähän esimerkkiä miten se toimi. Koitin konffailla toista 10G porttia käyttöön toisen serverin rungoksi ja commit vaiheessa tarkistus ilmoitti:

nmc@rvn-ourl-r03# commit
error: extended-vlan encapsulation not allowed on this interface
[edit interfaces xe-0/0/1]
'unit 2'
Only unit 0 is valid for this encapsulation
error: configuration check-out failed

Aloin sitten katsomaan mitäs sinne oikein tuli apinoitua ja näytti tältä, XE-0/0/0 oli aikaisemmin tehty ja XE-0/0/1 uusi:

Koodi:
interfaces {
    xe-0/0/0 {
        vlan-tagging;
        encapsulation extended-vlan-bridge;
        unit 42 {
            vlan-id 42;
        }
    }
    xe-0/0/1 {
        encapsulation extended-vlan-bridge;
        unit 2 {
            vlan-id 2;
            family bridge;
        }
    }

Sitten vähän harsintaa

Koodi:
[edit]
nmc@rvn-ourl-r03# delete interfaces xe-0/0/1 unit 2 family bridge

[edit]
nmc@rvn-ourl-r03# set interfaces xe-0/0/1 vlan-tagging

[edit]
nmc@rvn-ourl-r03# commit
commit complete

Ja lopuksi tuli tämän näköinen tuosta kohdasta

Koodi:
interfaces {
    xe-0/0/0 {
        vlan-tagging;
        encapsulation extended-vlan-bridge;
        unit 42 {
            vlan-id 42;
        }
    }
    xe-0/0/1 {
        vlan-tagging;
        encapsulation extended-vlan-bridge;
        unit 2 {
            vlan-id 2;
        }
    }

Eli tuolla logiikalla toimii tuo konffin tarkistus. Tietenkin sen konffin voi tarkistaa etukäteen vielä ilman että sitä otetaan käyttöön.
En vielä kerennyt testaamaan toimiiko tuo vielä käytännössä sillä pitää palvelimeen vaihtaa verkkortti ja konffia vielä toiseen kohtaan reittiä muutos.
 
mx.jpg

Kaippa tuo MX80 nyt toistaiseksi jää sitten käyttöön kun sain hommattua siihen DC powerin (tosin vain yhden) jotta sen sai akkuvarmennuksen taakse. Hifistelin asennuksen virallisemmaksi ja siirtelin SAS-M laitteesta yhteydet tähän. Pitää vähän miettiä minkälaista roolia tuolle verkossa kehittää.
 
mx.jpg

Kaippa tuo MX80 nyt toistaiseksi jää sitten käyttöön kun sain hommattua siihen DC powerin (tosin vain yhden) jotta sen sai akkuvarmennuksen taakse. Hifistelin asennuksen virallisemmaksi ja siirtelin SAS-M laitteesta yhteydet tähän. Pitää vähän miettiä minkälaista roolia tuolle verkossa kehittää.

Mitkä kuituSFP-moduulit sulla on paikalla tällä hetkellä tuossa Jumpperissa?
 
Äh, nyt tarvitsisi taas ajatuksia.

Koitan värkkäillä proxmoxia toimimaan Dell power edge R210II serverillä mutta vaikka asennus menee läpi niin IP yhteyttä hallintaan ei saa. Fyysinen linkki vaikuttaa nousevan ylös ja kun vertailin tuota toisella koneella olevaan asennukseen niin jostain syystä tuo Dell ei näyttäisi listaavan broadcast osoitetta vmbr0:lle. Se oli oikeastaan ainoa ero mikä pisti silmään

Dell:

1625909996150.png


Toimiva asennus toisessa koneessa:

Koodi:
root@RNS02:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether b4:7a:f1:2d:c4:e4 brd ff:ff:ff:ff:ff:ff
3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
    link/ether b4:7a:f1:2d:c4:e5 brd ff:ff:ff:ff:ff:ff
4: ens2f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr2 state UP group default qlen 1000
    link/ether 90:e2:ba:7f:93:68 brd ff:ff:ff:ff:ff:ff
5: ens2f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 90:e2:ba:7f:93:69 brd ff:ff:ff:ff:ff:ff
6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b4:7a:f1:2d:c4:e4 brd ff:ff:ff:ff:ff:ff
    inet 10.17.35.42/27 brd 10.17.35.63 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::b67a:f1ff:fe2d:c4e4/64 scope link
       valid_lft forever preferred_lft forever
7: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b4:7a:f1:2d:c4:e5 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b67a:f1ff:fe2d:c4e5/64 scope link
       valid_lft forever preferred_lft forever
8: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 90:e2:ba:7f:93:68 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::92e2:baff:fe7f:9368/64 scope link
       valid_lft forever preferred_lft forever
9: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr1 state UNKNOWN group default qlen 1000
    link/ether b2:ba:0c:db:55:4e brd ff:ff:ff:ff:ff:ff
10: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr2 state UNKNOWN group default qlen 1000
    link/ether c6:84:71:20:21:a7 brd ff:ff:ff:ff:ff:ff
root@RNS02:~#

/etc/network/interfaces näytti myöskin ihan yhteneväisiltä.

Reitittimeltä ei siis voi pingata Delliä (RNS02), Dell ei pysty pingaamaan reititintä eikä myöskään samassa aliverkossa olevat laitteet myöskään näe sitä ja toisinpäin. Kytkimen portin statistiikkaa kun kyyläsi, niin pingatessa Delliltä ei paketteja laskuriin tule joten vika lienee Dellin päässä. Kellään ajatuksia miten tätä kannattaisi selvitellä. Googlella löytyi lähinnä tapauksia missä Dellin verkkokortti ei näkynyt ensinnäkään mutta tässä se kuitenkin listassa oli.
 
Viimeksi muokattu:
Mitä ifconfig näyttää osoitteeksi
jos ei toimi niin
Koodi:
apt-get install net-tools
IP asetetaan asennusvaiheessa mutta ainakin minä olen onnistunut sössimään :(
Proxmoxista tuli viime viikolla uusi versio pitäis testata onko helpompi?
 
Mitä ifconfig näyttää osoitteeksi
jos ei toimi niin
Koodi:
apt-get install net-tools
IP asetetaan asennusvaiheessa mutta ainakin minä olen onnistunut sössimään :(
Proxmoxista tuli viime viikolla uusi versio pitäis testata onko helpompi?
Ongelmaa tuottaa se että pitäisi offlinena saada asennettua tuo net-tools koska yhteyttä ulkomaailmaan laite ei verkon kautta saa (nyt pääse VGA terminaaliin kiinni iDrac:in kautta) ja tuo taas ei ole tuttua. Proxmoxin linux pohja näyttää olevan melko pelkistetty mitä tuossa noita koittelin. Kyseessä on proxmoxin version 7.0-1. Voisi muuten tuota aikaisempaa kokeilla ihan piruuttaan että lähteekö se toimimaan. Tuo verkkokortti on kuitenkin aikaisemmin Pfsensen kanssa toiminut ja nyt on tarkoitus virtualisoida tuo että samalle raudalle saa toisen Pfsensen juoksemaan rinnalle.
 
Näyttääkö komento sudo brctl show että bridgeissä yleensäkään on mitään interfacea olemassa ?
Ja noita kahta eri konetta vertamalla näyttäisi tässä dellissä olevan molemmat fyysiset interfacet enp2s0f0 ja enp2s0f1 alhaalla, kun taas toimivassa kokoonpanossa toinen fyysinen interface ens2f0 on ylhäällä.

Mac osoitteen perusteella verkkkokorit ovat Dellin tekemiä, mutta en nyt heti löytänyt muuta kun viitteitä Broadcomin piirisarjaan, voisiko olla niin, että kortit vaativat toimiakseen jonkin firmwaren.
 

Statistiikka

Viestiketjuista
259 113
Viestejä
4 502 326
Jäsenet
74 329
Uusin jäsen
Bopperhopper

Hinta.fi

Back
Ylös Bottom