Pitääs kattoa tuo komento kun pääsee kotia takaisin. Dellissä enp-interfacet on 10G liitäntöjä jotka tulee palveluyhteyksille kun taas emolevyn integroitu 2x1G (eno1) tulee olemaan hallinnalle. jos ei muuta niin voisi kokeilla konffata hallinan kokeeksi tuon 10G kautta mutta se menee fyysisesti tällä hetkellä sellaiseen paikkaan josta yhteys pitää kytkennällisesti viedä hallintaverkon kytkimeen.
root@pve1:/etc/network# brctl show
bridge name bridge id STP enabled interfaces
fwbr104i0 8000.7af528474d10 no fwln104i0
tap104i0
vmbr0 8000.2c44fd2840d0 no eno1
fwpr104p0
vmbr1 8000.503eaa106606 no enp3s0
vmbr2 8000.001b213a72a7 no enp1s0Onko tuo OpenDCIM todella näin kämy näiden kaapelointien suhteen?
Hurraa pienellä nopeudella 24/7. Siinä on siis integroituna termari+säädin johdolla.
# stop corosync and pmxcfs on all nodes
$ systemctl stop corosync pve-cluster
# start pmxcfs in local mode on all nodes
$ pmxcfs -l
# put correct corosync config into local pmxcfs and corosync config dir (make sure to bump the 'config_version' inside the config file)
$ cp correct_corosync.conf /etc/pve/corosync.conf
$ cp correct_corosync.conf /etc/corosync/corosync.conf
# kill local pmxcfs
$ killall pmxcfs
# start corosync and pmxcfs again
$ systemctl start pve-cluster corosync
# check status
$ journalctl --since '-5min' -u pve-cluster -u corosync
$ pvecm statusNäin minäkin luin ja kun tuota jotkut kyseenalaistivat että tarviiko se todella sen 50% niin kovasti siellä ammattilaiset heti väitti että ottaa suurta damagea suorituskyvyssä jos laittaa vähemmän. Pitää jossain kohtaa ruuvata pienemmälle. Käyttö ei kuitenkaan ole kirjoitus intensiivistä.
Itsellä alkaa kohta olemaan oma kotiverkko iskussa, vielä kun saisi jonkun 16/24-porttisen hallittavan kytkimen vähintään gigaisilla porteilla ilman tuulettimia niin saisi kaikki VLANit sun muut lopulliseen kuntoon... Fanless sen takia että tuo kytkin olisi asuintiloissa joten en välttämättä kaipaisi yhtään enempää pöhinää kämppään
Tuo ajoittainen akkutesti olisi siinäkin mielessä hyvä että se parantaa akun käyttöikää kun akustolle tulee myös purkaus syklejä eikä pelkästään vuodesta toiseen kellu ylläpitölatauksessa. Kaupunkialueilla tahtoo sähkökatkot olla vähissä ja nekin mitä on ovat yleensä melko nopeita.Enpä ole minäkään kuullut PowerStarista aikaisemmin. Toivottavasti ei ole samanlainen valmistaja mitä osui aikanaan duunissa kohdalle että valmistajan alihankkija oli päättänyt säästää ja itsekin kerkisin noin 40-50 paskaa akkua vaihtamaan pitkin Uuttamaata rikkareihin ja sitten parin kuukauden päästä pääsi tekemään saman rundin uusiksi kun osa akuista oli viallisia. Vialliset tosin tunsi heti painosta kun tajusi verrata kunnolliseen mutta kun kiireessä noita vaihteli niin eipä tuohon painoon silloin kiinnittänyt huomiota.
Itselläni on 2 kpl 1,5kVA wanhoja Rittalin UPSeja. Akkujen vaihtovälinä olen pitänyt noin 4v, eli joka toinen vuosi toisesta pistän akut vaihtoon. Hyvin on toiminut tuo järjestely tähän asti mutta tajusin juuri pari viikkoa sitten että nuo ovat niin vanhoja UPSeja että eivät tajua edes mitata akuston kuntoa ellei erikseen käske mittaamaan, joten pitää varmaan jossain vaiheessa rakentaa joku skripti joka sarjaportin kautta komentaa vaikka kerran kuukaudessa akkutestin.
Edellisessä akkujen vaihdossa olikin itseasiassa yksi akku porsinut ja syövyttänyt toisen johdoistaan käytännössä poikki, ei ollut kuin pari ehjää säiettä johdossa. Testissä tuo johto olisi todenäköisesti palanut poikki ja olisi ilmoittanut ongelmasta.
Itsellä alkaa kohta olemaan oma kotiverkko iskussa, vielä kun saisi jonkun 16/24-porttisen hallittavan kytkimen vähintään gigaisilla porteilla ilman tuulettimia niin saisi kaikki VLANit sun muut lopulliseen kuntoon... Fanless sen takia että tuo kytkin olisi asuintiloissa joten en välttämättä kaipaisi yhtään enempää pöhinää kämppään
Laatu maksaa... itse olen ollut mukana akkuja vaihtaa järjestelmään jossa niitä on 3 numeroinen määrä eli ei ihan pikkurahalla vaihdeta niitä uusiin. Pelkästään kun painoa vertaa perus halppisakun ja ammattikäyttöön tarkoitetun akun välillä niin huomaa aika rajun painoeron. Ammattiakuissa ei ole säästelty sieltä täältä kuten halvemmissa on tehty vaan laadussa ei ole säästelty. Myös se että akut on oikeasti tehty niiden speksien mukaan että toimii vähintään niillä spekseillä mitä tehdas lupaa eikä vähäsen sinneppäin tyyliin.
Noille tuskin second hand kauppaa hirveästi on jos ei nyt omalle tai jonkun tutun mökille aurinkopaneeliin mutta romunakin noista maksetaan n. 500€/tn ja jos katsoo esim Enersys Powersafe 12V190 niin ne painaa 57kg kappale. Nykyään kun noissa tukiasemakopeissakin noita akkuja alkaa olla jo useampia kymmeniä akkuja joissain paikoissa.
Tuo toimisi ainoastaan console yhteyksien + palvelimien remote desktoppien kanssa. Ei välttämättä sulje pois mutta itsellä oli mielessä hallintatavasta riippumaton tunnushallinta.
Jos muistelen oikein niin Acteliksen hallinta näytti pituusarvioksi jotain 100m paikkeilla ja välissä yksi kerrosjakamo ja veto asuntoon nelikierrettä. Latenssissa ethernet pesisikin mutta näillä Acteliksillä saa sen 150Mbps läpi kahdella parilla. Pitäisi joskus vielä kattoa jos jostain löytyisi järkevät G.fast purkit tilalle.
Kerberos ja ldap tulille, tai jos haluat helpottaa säätämistä suoraan freeipa. Itse joskus testailin freeipaa ja vaikutti ihan lupaavalta
www.freeipa.org
Äkkiseltään ruokatunnilla lukastuna nuo olisi enemmän OS tason käyttäjähallintaan kun nyt siis haettaisiin ratkaisua erilaisten verkkolaitteiden kirjautumisen hallintaan.Kerberos ja ldap tulille, tai jos haluat helpottaa säätämistä suoraan freeipa. Itse joskus testailin freeipaa ja vaikutti ihan lupaavalta
FreeIPA - Identity, Policy, Audit — FreeIPA documentation
AInakin sonicwallin palomuurit tukevat keskitettyä kirjautumista ldap:n kautta, mutta voipi olla hieman liian järkeä ratkaisu käyttöösi. Itse lähtisin toteuttamaan kirjautumista freeradiuksella.
ge-0/1/1 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ MGMT-OURI UNIFI ];
}
}
}
}vlans {
MGMT-OURI {
vlan-id 12;
interface {
ge-0/0/1.0;
}
}Joo, kattelin noita jo aikaisemmin ja totesin että on ylihintaisia netsys purkkeja:
ge-0/0/15 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members inside;
}
}root@RVN-OURI-SW1> show configuration
## Last commit: 2023-02-13 21:29:51 EET by root
version 11.4R5.7;
system {
host-name RVN-OURI-SW1;
time-zone Europe/Helsinki;
root-authentication {
encrypted-password
}
services {
ssh {
root-login allow;
protocol-version v2;
}
netconf {
ssh;
}
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members YAR;
}
}
}
}
ge-0/0/1 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members UNIFI;
}
}
}
}
ge-0/0/2 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members MGMT-OURI;
}
}
}
}
ge-0/0/3 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ UNIFI IOT OFFICE ];
}
}
}
}
ge-0/0/4 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members IOT;
}
}
}
}
ge-0/0/5 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ OFFICE MGMT-OURI YAR ];
}
}
}
}
ge-0/0/6 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members OFFICE;
}
}
}
}
ge-0/0/7 {
unit 0 {
family ethernet-switching {
vlan {
members OFFICE;
}
}
}
}
ge-0/0/8 {
unit 0 {
family ethernet-switching {
vlan {
members OFFICE;
}
}
}
}
ge-0/0/9 {
unit 0 {
family ethernet-switching {
vlan {
members OFFICE;
}
}
}
}
ge-0/0/10 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/11 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/12 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/13 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/14 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/15 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/16 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/17 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/18 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/19 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/20 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/21 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/22 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/23 {
unit 0 {
family ethernet-switching;
}
}
ge-0/1/0 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ OFFICE IOT ];
}
}
}
}
ge-0/1/1 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ MGMT-OURI UNIFI ];
}
}
}
}
ge-0/1/2 {
unit 0 {
family ethernet-switching;
}
}
ge-0/1/3 {
unit 0 {
family ethernet-switching;
}
}
me0 {
unit 0 {
family inet {
address 10.17.31.7/27;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 10.17.31.1;
}
}
protocols {
igmp-snooping {
vlan all;
}
rstp;
lldp {
interface all;
}
lldp-med {
interface all;
}
}
ethernet-switching-options {
storm-control {
interface all;
}
}
vlans {
IOT {
vlan-id 8;
}
MGMT-OURI {
vlan-id 12;
}
OFFICE {
vlan-id 2;
}
UNIFI {
vlan-id 31;
}
YAR {
vlan-id 42;
}
}
poe {
interface all {
disable;
}
interface ge-0/0/5;
interface ge-0/0/1;
interface ge-0/0/3;
}Ei ole, tuo kuvaa loogista topologiaa, ei fyysistä.Vilasin kanssa noi sun verkkokuvat, onko sulla siis 10 kytkintä ja 5 reitittävää laitetta? Melkonen viritys
Kannattaa L3 kuvat VLANeineen piirtää esim. putkilla, nuo kytkinikonit kun implikoi uniikkeja fyysisiä laitteita. Toki kuvat on tekijänsä näkösiä, How to Draw Clear L3 Logical Network Diagrams - Packet Pushers tuossa on joku esimerkki minkä tyylisiä L3 kuvat usein on. Eli VLANit ikäänkuin "putkia". Itsekkään en ihan linkin tapaisia kuvia tee, mutta ehkä saat ajatuksesta kiinni. Tuossa on annettu L2 kuva, ja sen pohjalta ikäänkuin tehdään L3 kuva.
Jos nyt oikein ymmärsin niin noinhan se menee että tagged ja untagged on mentävä erillään. untagged voit määrätä käyttämään esim täysin kuvitteellisesti vaikka VLAN10 ja toiseen porttiin sama niin silloin olet tehnyt yhden "tavallisen" kytkimen jossa on vain kaksi porttia jotka ovat vaan VLAN10 alaisuudessa mutta tuo täggäys ei siirry portista laitteille. Tagged taas tekee niin että se VLAN tunniste jatkuu kyseisestä portista eteenpäin eikä tunniste tipu kyseisen portin kohdalla pois (taggedia ei järkeä käyttää sellaisen laitteen kohdalla joka ei tue/käytä VLAN id:tä jolloin se id kulkeutuminen laitteelle asti aiheuttaisi turhaa liikennettä id:n rummuttaessa laitteen verkkokorttia vaikkei laite sillä id tiedolla mitään tekisi. untagged järkevämpi laittaa tuollaisessa tapauksessa käyttöön jolloin kytkin hoitaa tarvittaessa sen untagged liikenteen tietyn VLAN id alaisuuteen tarvittaessa.
Ei siinä sinäänsä muuta epäselvää ollut kuin että miten nuo konffitaan juuri Juniperiin kun sen konffimistyyli on..... erilainen.
Joo, ensimmäinen kytkin jonka olen aina vaivautunut sammuttamaan hallitusti. Omasta mielestä tuo on aivan käsittämätön suunnittelun kukkanen kytkimiin. Jossain yli 10K€ reitittimessä tuon voi ymmärtääkkin kun sellaiset lähes poikkeuksetta on hyvien varmistusten takana mutta varmaan tuo on vaihtokauppa siihen että samaa softaa voidaan käyttää kummassakin. Monesti kytkimien virransyötön varmistus on mitä on.
Vastausta ei ole, mutta aloita uusi proxmox ketju ohjelmisto puolelle (sielä taitaa olla joku läheltä liippaava)
