What's new in 6.10 (2014-Feb-12 13:46):
**KNOWN ISSUE: IPsec AES-CBC 256 Bit encryption algorithm doesn't work in some cases. Use 128 bit AES, or hold on for v6.11**
*) fix autosupout.rif generation after kernel panic;
*) ovpn - make it work again;
*) ovpn client - remove cipher=any & auth=any options,
protocol does not support them;
*) pptp - fixed where Windows & MacOS clients were disconnecting all the time;
*) sstp - make it work with Windows client with AES encryption;
*) ipv6 pool - fix dynamic prefix disappearing which may influence large
VPNs with IPv6;
*) ssh client - fix key agreement when sometimes wrong DH algorithm was selected;
*) bgp - multipath eBGP now does not propagate BGP nexthop unless
forced in configuration;
*) removed 10/100 half duplex from autonegotiation advertisement on CCR;
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Verze 6.10
Klasika je pátek a máme tu novou verzi 
Sxt lite5 upgrade ok včetně biosu
Sxt lite5 upgrade ok včetně biosu
0 x
hele ma cenu abych se s tim rozciloval ? jedu porad na 5.24, obcas se to posere,
nektere stare spoje jedou jeste na 4.17 .....
kterou verzi z 6.xx mam zkouset kdyz se kazda sere??
na bezdraty si netroufam to zatim nasadit, nechci v zime jezdit a prenastavovat ...
nicmene potrebuju nejakou 6.xx na 2011 v bridge modu - vsechny porty v bridge pres CPU, na switchchip seru, learned macs ~3000 ...
nektere stare spoje jedou jeste na 4.17 .....
kterou verzi z 6.xx mam zkouset kdyz se kazda sere??
na bezdraty si netroufam to zatim nasadit, nechci v zime jezdit a prenastavovat ...
nicmene potrebuju nejakou 6.xx na 2011 v bridge modu - vsechny porty v bridge pres CPU, na switchchip seru, learned macs ~3000 ...
0 x
Pokud ti to s 5.x funguje, tak se na to nešahá. Ale ta 6.7 vypadá celkem, že nani vyšší moc trochu dohlédla...
Na těch 3000 MAC adres bych si fakt raději dal normální switch než RB2011 v soft bridge.
Jinak ROS6.10 nějak jede (RB4xx/800/1100/AH/AHx2). Něco poladili i v multicastu, co v 6.5~6.7 blbnulo, tak blbne o něco méně.
Kde mi to umírá na vyčerpání route cache (/ip route cache) v ROS6.7 v řádu dní, tak ROS6.10 nepřekročí uptime 12 hodin do zhroucení (naštestí stále celkem OK odchytí a rebootem napraví /system watchdog set watch-address=X).
S tím SSTP serverem polaborovali asi až moc. Kde mám jako klienty Mikrotik krabičky na ROS6.3~6.6, tak to proti ROS6.10 serveru funguje, pokud je obou stranách force-aes=yes. Když AES vynucen není, tak po uprade serveru se už klienti nepřipojí (nějak se na té staré RC4 šifře už neshodnou) aneb jak jedním upgradem přijít o spojení k stovce lokalit. SSTP server binbing stále zapomíná ukončit aktivní spojení na timeout, když klient nečekaně odpadne.
Ale ta 6.7 vypadá celkem, že nani vyšší moc trochu dohlédla... Na těch 3000 MAC adres bych si fakt raději dal normální switch než RB2011 v soft bridge.
Jinak ROS6.10 nějak jede (RB4xx/800/1100/AH/AHx2). Něco poladili i v multicastu, co v 6.5~6.7 blbnulo, tak blbne o něco méně.
Kde mi to umírá na vyčerpání route cache (/ip route cache) v ROS6.7 v řádu dní, tak ROS6.10 nepřekročí uptime 12 hodin do zhroucení (naštestí stále celkem OK odchytí a rebootem napraví /system watchdog set watch-address=X).
S tím SSTP serverem polaborovali asi až moc. Kde mám jako klienty Mikrotik krabičky na ROS6.3~6.6, tak to proti ROS6.10 serveru funguje, pokud je obou stranách force-aes=yes. Když AES vynucen není, tak po uprade serveru se už klienti nepřipojí (nějak se na té staré RC4 šifře už neshodnou) aneb jak jedním upgradem přijít o spojení k stovce lokalit.
SSTP server binbing stále zapomíná ukončit aktivní spojení na timeout, když klient nečekaně odpadne.
0 x
Jsem hloupý já, nebo opět mikrotik?
Konfigurace:
dva porty switche, jeden VLANy, druhý access. Zapojeno do dvou portů RB1100Hx2 (11 a 12, tedy mimo switch čip). Jedna z VLAN je v bridge na mikrotiku (a je tam momentálně jediná). Zapnu-li na bridgi RSTP, port na switchi s VLANy padne do discarding stavu ... Vypadá to, že BPDU chodí i tam, kde nemají.
Konfigurace:
dva porty switche, jeden VLANy, druhý access. Zapojeno do dvou portů RB1100Hx2 (11 a 12, tedy mimo switch čip). Jedna z VLAN je v bridge na mikrotiku (a je tam momentálně jediná). Zapnu-li na bridgi RSTP, port na switchi s VLANy padne do discarding stavu ... Vypadá to, že BPDU chodí i tam, kde nemají.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Na pohled to zní, že to chodí jak má. Maximálně má ROS úchylku, že ti nacpe BPDU do VLANy (což pro normální STP/RSTP/MSTP se nedělá), když je do bridge přidaná VLANa. Takže se to tváří to jak PVST+, ale nesestavuje ho správně a ve VLANě je normální RSTP BPDU. Zkrátka jak zapneš RSTP na bridge, tak defaultně do všech portů tlačí BPDU a neřeší typ portu. Sousední switch si toho asi všiml a zareagoval (možná BPDU prohlásí za nevalidní a port zavřel).
Teoretiky, můžeš na ten vlan port v bridge zkusit nastavit edge=yes. Pak ROS minimálně ignoruje příchozí BPDU a bere, že tam další switch není, možná přestane BPDUčka i vysílat.
Teoretiky, můžeš na ten vlan port v bridge zkusit nastavit edge=yes. Pak ROS minimálně ignoruje příchozí BPDU a bere, že tam další switch není, možná přestane BPDUčka i vysílat.
0 x
edge-port znamená trochu něco jiného, přeci. Forwarduje ihned, nečeká na sestavení komplet stromečku. Ale pokud přijde BPDU, stává se normálním ne-edge ... ROS to má zase jinak? Ale to jsem taky zkoušel, nepomohlo to ničemu.
V každém případě to divné je. Např. pokud na mikrotiku dám starý 802.1d, switch port nezablokuje. Ale mikrotik je rootem, i když by neměl.
Já to tam naštěstí nepotřebuji. Jenže zjevně od nových verzích je na bridge RSTP zapnuté defaultně, takže to hrozí způsobit pěkné problémy.
V každém případě to divné je. Např. pokud na mikrotiku dám starý 802.1d, switch port nezablokuje. Ale mikrotik je rootem, i když by neměl.
Já to tam naštěstí nepotřebuji. Jenže zjevně od nových verzích je na bridge RSTP zapnuté defaultně, takže to hrozí způsobit pěkné problémy.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Samozřejmě, ROS to má jinak. Jak jinak, že?
edge=yes - otevře port hned a nevysílá/nepřijímá BPDU, zkrátka neřeší, co se na portu děje.
edge=yes-discover - port otevře hned a jakmile přijme BPDU, přechází na ne-edge port.
A tak nějak od pohledu se to tak i chová. Když to člověk chvíli kliká, tka to vypadá, že se občas sekne a je ochoten vysílat BPDU i s edge=yes nad VLANou.
Když máš switch v RSTP a Mikrotika v STP, tak Mikrotik ignoruje ten RSTP provoz (nerozumí RSTP provozu). Reagovat by měl ten switch, že jak uslyší STP, tak by měl provést fallback z RSTP na STP (někdy jde nastavit, zda má/nemá dělat).
edge=yes - otevře port hned a nevysílá/nepřijímá BPDU, zkrátka neřeší, co se na portu děje.
edge=yes-discover - port otevře hned a jakmile přijme BPDU, přechází na ne-edge port.
A tak nějak od pohledu se to tak i chová. Když to člověk chvíli kliká, tka to vypadá, že se občas sekne a je ochoten vysílat BPDU i s edge=yes nad VLANou.
Když máš switch v RSTP a Mikrotika v STP, tak Mikrotik ignoruje ten RSTP provoz (nerozumí RSTP provozu). Reagovat by měl ten switch, že jak uslyší STP, tak by měl provést fallback z RSTP na STP (někdy jde nastavit, zda má/nemá dělat).
0 x
V6.10 je na RB1000 nestabilní, uptime je max. 1den. U v6.9 jsem měl uptime 45 dní. Už jsem to reportoval.
0 x
ok2slc píše:V6.10 je na RB1000 nestabilní, uptime je max. 1den. U v6.9 jsem měl uptime 45 dní. Už jsem to reportoval.
RB1000 ROS v6.10 (fw 2.30) uptime 12dni (NAT, DHCP, IPsec (GRE-tunnel , EOIP-tunnel), PPtP, IPv6, atd.) OK.
0 x
Hmm, tak tam asi používám něco jiného, protože se odpojovaly i porty v bondigu. Vrátil jsem tam v6.9 a uptime 5d. Uvidíme zda mě něco pošlou ze supportu kromě linku na novou rc11 .
.
0 x
Jestli-že používáš bonding v režimu active-backup, a to podpořený pomocí ARP monitoringu, tak ten je v ROSu zprasen (včetně ROS6.11rc1). A pokud ho musím dát nad VLANy, tak kraví totálně. Zrovna jsem je za to drbal místo předkrmu.
Pánové totiž testovací ARP dotazy tlačí do všech portů se stejnou zdrojovou MAC adresou, ale přijímají na tu MAC provoz jen na master portu, takže to jakž tak funguje jen v specifické konfiguraci nastavení:
/interface bonding add arp-interval=500ms arp-ip-targets=192.168.88.1,192.168.88.2 down-delay=300ms up-delay=300ms \
link-monitoring=arp mode=active-backup name=bonding1 primary=ether1 slaves=ether2,ether1
Jde o tu sekvenci primary=ether1 slaves=ether2,ether1 - jakákoliv jiná, nebo bez master portu, vede ke značné ztreátovosti. I tato ztrátuje něco málo při intenzivním provozu do routeru. Pomíjím, že u paranoidněji nastavených switchů vede k zablokování portů pro přeskakování MAC z portu na port (a přitom RB stejně poslouchá jen na jednom). Totálně i kašlou na to, jakým portem se jim ty testovací ARP odpovědi vrací...
Edit - takže pokud se dá bond až nad VLANu, něco jako:
/interface vlan
add interface=ether1 l2mtu=1596 name=e1.vlan1 vlan-id=1
add interface=ether2 l2mtu=1596 name=e2.vlan1 vlan-id=1
/interface bonding
add arp-interval=500ms arp-ip-targets=192.168.88.1,192.168.88.2 down-delay=300ms link-monitoring=arp mode=active-backup name=bonding1
primary=e1.vlan1 slaves=e2.vlan1,e1.vlan1 up-delay=300ms
tak ROS dělá to, že neustále přehazuje, která linka v bondu je aktivní. A to tak, že primární je aktivní trojnásobek arp-interval a sekundární po dobu arp-interval. A dělá to bez ohledu na to, zda ty linky pod tím fyzicky ne/fungují. V kombinaci s tím, že neposílá při změně aktivní linky gratuitous ARP na právě vybranou linku, tak to pak v podstatě nefunguje, ať linky ne/jsou funkční.
Pánové totiž testovací ARP dotazy tlačí do všech portů se stejnou zdrojovou MAC adresou, ale přijímají na tu MAC provoz jen na master portu, takže to jakž tak funguje jen v specifické konfiguraci nastavení:
/interface bonding add arp-interval=500ms arp-ip-targets=192.168.88.1,192.168.88.2 down-delay=300ms up-delay=300ms \
link-monitoring=arp mode=active-backup name=bonding1 primary=ether1 slaves=ether2,ether1
Jde o tu sekvenci primary=ether1 slaves=ether2,ether1 - jakákoliv jiná, nebo bez master portu, vede ke značné ztreátovosti. I tato ztrátuje něco málo při intenzivním provozu do routeru. Pomíjím, že u paranoidněji nastavených switchů vede k zablokování portů pro přeskakování MAC z portu na port (a přitom RB stejně poslouchá jen na jednom). Totálně i kašlou na to, jakým portem se jim ty testovací ARP odpovědi vrací...
Edit - takže pokud se dá bond až nad VLANu, něco jako:
/interface vlan
add interface=ether1 l2mtu=1596 name=e1.vlan1 vlan-id=1
add interface=ether2 l2mtu=1596 name=e2.vlan1 vlan-id=1
/interface bonding
add arp-interval=500ms arp-ip-targets=192.168.88.1,192.168.88.2 down-delay=300ms link-monitoring=arp mode=active-backup name=bonding1
primary=e1.vlan1 slaves=e2.vlan1,e1.vlan1 up-delay=300ms
tak ROS dělá to, že neustále přehazuje, která linka v bondu je aktivní. A to tak, že primární je aktivní trojnásobek arp-interval a sekundární po dobu arp-interval. A dělá to bez ohledu na to, zda ty linky pod tím fyzicky ne/fungují. V kombinaci s tím, že neposílá při změně aktivní linky gratuitous ARP na právě vybranou linku, tak to pak v podstatě nefunguje, ať linky ne/jsou funkční.
0 x
Já požívám bonding na 2xFCX1600 kde mám ip 192.168.254.252 na VRRP:
name="bonding_et3_et4" mtu=1500 mac-address=00:0C:42:20:86:9E
arp=enabled slaves=ether3,ether4 mode=active-backup primary=ether3
link-monitoring=mii arp-interval=100ms arp-ip-targets=192.168.254.252
mii-interval=100ms down-delay=0ms up-delay=0ms lacp-rate=30secs
transmit-hash-policy=layer-2
A ve žádné předchozí verzi nebyly na FCX1600 pozorovány výpadky a doufám, že to fungovalo. Výpadky portů na straně FCX1600 nastaly až po upgrade v6.10.
name="bonding_et3_et4" mtu=1500 mac-address=00:0C:42:20:86:9E
arp=enabled slaves=ether3,ether4 mode=active-backup primary=ether3
link-monitoring=mii arp-interval=100ms arp-ip-targets=192.168.254.252
mii-interval=100ms down-delay=0ms up-delay=0ms lacp-rate=30secs
transmit-hash-policy=layer-2
A ve žádné předchozí verzi nebyly na FCX1600 pozorovány výpadky a doufám, že to fungovalo. Výpadky portů na straně FCX1600 nastaly až po upgrade v6.10.
0 x