classic.ISPforum.cz

Když nahraji uloženou konfiguraci z RB133C nebo RB133 například do RB192 nebo RB153. Tak se mě špatně očíslují Ethernety. Třeba když jsem fyzicky v ETH1 tak se mikrotik tváří jako bych byl v ETH3. A ostatní ethernety jsou posunuté. Dá se tomu nějak zabránit?

Dík

Nikdo nenahrává konfiguraci do jiného MT?

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Delal sem tento vikend backup ze 153ky, padala pri vetsim toky jak 3Mbit FD, dal sem to na 133ku a ether1 je ted ether3 na tej 133ce, ale nijak mi to nevadi.
Moji konfiguraci to nevadi, ale chapu, ze jsou jiste situace kde by to vadit mohlo. Wirellesy mi prekopal v poradku.

aj_rade píše:

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Delal sem tento vikend backup ze 153ky, padala pri vetsim toky jak 3Mbit FD, dal sem to na 133ku a ether1 je ted ether3 na tej 133ce, ale nijak mi to nevadi.
Moji konfiguraci to nevadi, ale chapu, ze jsou jiste situace kde by to vadit mohlo. Wirellesy mi prekopal v poradku.

Jo wirellesy jsou vždy v pořádku. Ale ethernety to rozhodí. Dá se s tím něco dělat? Né že by to bylo vyloženě neřešitelné, ale radši bych aby ETH1 byl fakt ETH1 atd...

honzam píše:

aj_rade píše:

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Delal sem tento vikend backup ze 153ky, padala pri vetsim toky jak 3Mbit FD, dal sem to na 133ku a ether1 je ted ether3 na tej 133ce, ale nijak mi to nevadi.
Moji konfiguraci to nevadi, ale chapu, ze jsou jiste situace kde by to vadit mohlo. Wirellesy mi prekopal v poradku.

Jo wirellesy jsou vždy v pořádku. Ale ethernety to rozhodí. Dá se s tím něco dělat? Né že by to bylo vyloženě neřešitelné, ale radši bych aby ETH1 byl fakt ETH1 atd...

obavam se, ze jedine reseni, navic ne jiste, je hodit request na support Mikrotiku.

aj_rade píše:

honzam píše:

aj_rade píše:

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Delal sem tento vikend backup ze 153ky, padala pri vetsim toky jak 3Mbit FD, dal sem to na 133ku a ether1 je ted ether3 na tej 133ce, ale nijak mi to nevadi.
Moji konfiguraci to nevadi, ale chapu, ze jsou jiste situace kde by to vadit mohlo. Wirellesy mi prekopal v poradku.

Jo wirellesy jsou vždy v pořádku. Ale ethernety to rozhodí. Dá se s tím něco dělat? Né že by to bylo vyloženě neřešitelné, ale radši bych aby ETH1 byl fakt ETH1 atd...

obavam se, ze jedine reseni, navic ne jiste, je hodit request na support Mikrotiku.

Cesky asi ne co? Anglicky bych to nenapsal

honzam píše:

aj_rade píše:

honzam píše:

aj_rade píše:

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Delal sem tento vikend backup ze 153ky, padala pri vetsim toky jak 3Mbit FD, dal sem to na 133ku a ether1 je ted ether3 na tej 133ce, ale nijak mi to nevadi.
Moji konfiguraci to nevadi, ale chapu, ze jsou jiste situace kde by to vadit mohlo. Wirellesy mi prekopal v poradku.

Jo wirellesy jsou vždy v pořádku. Ale ethernety to rozhodí. Dá se s tím něco dělat? Né že by to bylo vyloženě neřešitelné, ale radši bych aby ETH1 byl fakt ETH1 atd...

obavam se, ze jedine reseni, navic ne jiste, je hodit request na support Mikrotiku.

Cesky asi ne co? Anglicky bych to nenapsal

lamanou jiste jo, oni to taky nejsou anglani ci amici ?

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Nikdy jsem nepouzival klasickou zalohu pro pouziti v jinem typu RB dle me to je blbost pac muze byt v te zaloze i zazalohovana chyba.
Vzhledem k tomu ze asi na RB133 neni nijak extra slozita konfogurace, je daleko efektivnejsi a bezpecnejsi je pouzit export jednotlivych casti mk do txt souboru a nasledne import scriptem.
třeba podstatny zaklad:

/ip address
/ip firewall
/ip wireless
/ip route
/queue

lze i členit např. /ip firewall nat

Pouzivam to i u vsech RB co mam a bez problemu. Celkem rychlé, nevyzaduje to restart RB pokud je nekde chyba tak se importovací script zastaví před chybujícím řádkem, tak že se chyba lehko dohledá.

honzam píše:

aj_rade píše:

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Delal sem tento vikend backup ze 153ky, padala pri vetsim toky jak 3Mbit FD, dal sem to na 133ku a ether1 je ted ether3 na tej 133ce, ale nijak mi to nevadi.
Moji konfiguraci to nevadi, ale chapu, ze jsou jiste situace kde by to vadit mohlo. Wirellesy mi prekopal v poradku.

Jo wirellesy jsou vždy v pořádku. Ale ethernety to rozhodí. Dá se s tím něco dělat? Né že by to bylo vyloženě neřešitelné, ale radši bych aby ETH1 byl fakt ETH1 atd...

Wirellesy jsou v pořádku pouze tehdy, pouzije-li se ten samý kus co byl na zařízení ze kterého je záloha.
Pokud tam bude jiný kus karty (v podstatě jiná MAC) tak to konfiguraci na wifi neudělá.

Zdeněk.hb píše:

honzam píše:

aj_rade píše:

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Delal sem tento vikend backup ze 153ky, padala pri vetsim toky jak 3Mbit FD, dal sem to na 133ku a ether1 je ted ether3 na tej 133ce, ale nijak mi to nevadi.
Moji konfiguraci to nevadi, ale chapu, ze jsou jiste situace kde by to vadit mohlo. Wirellesy mi prekopal v poradku.

Jo wirellesy jsou vždy v pořádku. Ale ethernety to rozhodí. Dá se s tím něco dělat? Né že by to bylo vyloženě neřešitelné, ale radši bych aby ETH1 byl fakt ETH1 atd...

Wirellesy jsou v pořádku pouze tehdy, pouzije-li se ten samý kus co byl na zařízení ze kterého je záloha.
Pokud tam bude jiný kus karty (v podstatě jiná MAC) tak to konfiguraci na wifi neudělá.

to je sice pravda, ale u ethernetu by to melo byt logicky stejne, kazdej ether interface ma taky jinou MAC apod. tak by to preci taky nemelo nic prenest dle vasi teorie, ze? Pak by ale ten backup byl k nicemu, nemyslite ? Takze to, ze to na cizi wirellesy neprenese, je dle meho nazoru BUG, protoze to pak vlastne neplni vubec dany ucel, tj. restore backup zalohy.

aj_rade píše:

Zdeněk.hb píše:

honzam píše:

aj_rade píše:

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Delal sem tento vikend backup ze 153ky, padala pri vetsim toky jak 3Mbit FD, dal sem to na 133ku a ether1 je ted ether3 na tej 133ce, ale nijak mi to nevadi.
Moji konfiguraci to nevadi, ale chapu, ze jsou jiste situace kde by to vadit mohlo. Wirellesy mi prekopal v poradku.

Jo wirellesy jsou vždy v pořádku. Ale ethernety to rozhodí. Dá se s tím něco dělat? Né že by to bylo vyloženě neřešitelné, ale radši bych aby ETH1 byl fakt ETH1 atd...

Wirellesy jsou v pořádku pouze tehdy, pouzije-li se ten samý kus co byl na zařízení ze kterého je záloha.
Pokud tam bude jiný kus karty (v podstatě jiná MAC) tak to konfiguraci na wifi neudělá.

to je sice pravda, ale u ethernetu by to melo byt logicky stejne, kazdej ether interface ma taky jinou MAC apod. tak by to preci taky nemelo nic prenest dle vasi teorie, ze? Pak by ale ten backup byl k nicemu, nemyslite ? Takze to, ze to na cizi wirellesy neprenese, je dle meho nazoru BUG, protoze to pak vlastne neplni vubec dany ucel, tj. restore backup zalohy.

No ano Ethernety to prenastavi v ramci stejneho zarizeni spravne. Tam se MAC nekontroluje, voditkem muze byt treba nejaka HW znacka pro konfiguraci v ramci RouterOS, jako ze Ether1 na RB532 ma cislo 1 na kazdem jinem RB532, ale uz neni jiste ze treba na RB333 bude ether1 skutecne pod kodem 1. Berte jen jako priklad takhle to asi presne nefunguje. Ale nadruhou stranu je to jako PCI sloty na PC kde bezi linux .. pokud se nenastavi jinak, je brano znaceni ETH0 - ETHX podle toho v jakem je ta sitovka v poradi v PCI. Brano na zakladni desce od grafiky dolu. pokud tam nasazim tri stejne sitovky treba 3com (tzn nerozlisim modul k eth v modules.conf pac bude porad stejny driver) bude mit sitovka u grafiky vzdy eth0 prostreni eth1 a nejspodnejsi eth2.
Proc tomu tak je je veci IRQ. Stejne tak na RB532 jsou 3 sitovky stale ve stejnem poradi takze lze predpokladat v zaloze RB532 ze Oddelena sitovka je proste ether1 a dle IRQ ktere bude stale stejne muze mit nazev treba WAN. Jsou nemennou soucasti RB.

WiFi karty nejsou nemennou soucasti RB a tudiz jsou rozeznavany podle neceho co si nesou s sebou a je jedinecne tedy MAC adresu.

Takze muj nazor. Pokud pouzivat zalohy a obnovy ze zaloh tak ze stejneho typu na stejny typ pokud nemame moc casu. V jinem pripade pouzivat EXPORT at uz z duvodu zajisteni spravne funkcnosti, tak i k eliminaci chyb v puvodni konfiguraci. Muze se stat ze nam RB zlobi .. prehrajeme zalohu do jineho kusu .. jak blbci lezeme buh vi kam (vetsinou se to podela na nejmin pristupnem miste) a pak zjistime ze to na novem kusu blbne taky. A Ejhle chyba v konfiguraci ktere jsme si nevsimli.

je dle meho nazoru BUG, protoze to pak vlastne neplni vubec dany ucel

To mi přijde jako by jsi čekal, že když si PC zazálohuješ třeba s boardem Asus, pak to obnovíš na MSI a všechno bude makat jak má. (Přesnější by asi byl příklad s typem X a s typem Y od stejného výrobce) To je prostě blbost. Byl bych rád, že to obnoví aspoň tak

Zdeněk.hb píše:

honzam píše:Nikdo nenahrává konfiguraci do jiného MT?

Nikdy jsem nepouzival klasickou zalohu pro pouziti v jinem typu RB dle me to je blbost pac muze byt v te zaloze i zazalohovana chyba.
Vzhledem k tomu ze asi na RB133 neni nijak extra slozita konfogurace, je daleko efektivnejsi a bezpecnejsi je pouzit export jednotlivych casti mk do txt souboru a nasledne import scriptem.
třeba podstatny zaklad:

/ip address
/ip firewall
/ip wireless
/ip route
/queue

lze i členit např. /ip firewall nat

Pouzivam to i u vsech RB co mam a bez problemu. Celkem rychlé, nevyzaduje to restart RB pokud je nekde chyba tak se importovací script zastaví před chybujícím řádkem, tak že se chyba lehko dohledá.

A mohl bys ten skript na zálohu a obnovení zveřejnit?

Komlet záloha:

Záloha dílčích nastavení:

Zdeněk.hb píše:Ale nadruhou stranu je to jako PCI sloty na PC kde bezi linux .. pokud se nenastavi jinak, je brano znaceni ETH0 - ETHX podle toho v jakem je ta sitovka v poradi v PCI. Brano na zakladni desce od grafiky dolu. pokud tam nasazim tri stejne sitovky treba 3com (tzn nerozlisim modul k eth v modules.conf pac bude porad stejny driver) bude mit sitovka u grafiky vzdy eth0 prostreni eth1 a nejspodnejsi eth2.

Nechci se hadat, ale distra ktere pouzivaji UDEV a ne obsolete DEVFS, tak v konfigu si muzes nadefinovat napriklad podle MAC ktera sitovka ma byt ktera. Nicmene v pripade pouziti DEVFS plati co jsi napsal.