Verze 6.0rc8

[honzam]

What's new in 6.0rc8 (2013-Feb-04 13:25):

*) ppp,pppoe,pptp,l2tp,sstp - only 2 change mss mangle rules are created for all ppp interfaces;
*) wireless - fixed AES encryption speed issues (upgrade suggested);
*) dhcpv6 server - handle info requests;
*) webfig - compressed all html resource files, speeds up opening of webfig page;
*) console - reduced width of address column in '/user print';
*) simple queues requires target arg to be specified when adding;
*) do not count packets for unknown protocols as rx_dropped;
*) snmp - provide POE info;
*) improved cpu usage reporting on CCR boards;
*) improved interface reading performance;
*) changed CLI interface order - first are ethernets, second wireless, third everything else.
Within group interfaces are ordered by name;
*) interfaces are deleted much faster, could be bottleneck on systems with many ppp sessions;
*) pptp,l2tp,6to4 tunnel encapsulation/decapsulation now resets packet marks to
have consistent behavior across tunnels;
*) fix simple queue interface matching when doing encapsulation in some tunnel,
could result in double accounted packets;
*) ip/ipv6 firewall has all-ether,all-wireless,all-vlan,all-ppp interface matchers
*) queue limits could be inaccurate for large limits (100M or more);
*) added initial OpenFlow support

[hapi]

hmm, zdá se že už s v6 zkončili. Žádný podstatný vylepšení dlouho nebyly, jenom samí "dodělávky"

[honzam]

A chybí ti tam něco konkrétního? Podle mě kdyby vychytali chyby tak to bude super. Optimalizace pro CCR tam mají ještě hodně co dělat..

-Currently routing tables are not optimized for multicore
- firewall není vyladěný pro CCR atd...

[hapi]

chybí mi tam ta stabilita u všeho. Jako na v5.22 si nemůžu stěžovat ale co si budeme říkat, něco totálně stabilního bylo naposledy ve v3.30. I v4.17 se jevila jako "psychologicky" "použitelnější". U v5 jsem byl ochotnej jít na RC verzi v raných časech v5 globálně u všech klientů ale u v6 ten pocit nemám. Mám sice v6rc6 na dvou spojích abych viděl co to dělá ale jako moc šťastnej nejsem.

No zajímala by mě ta optimalizace routování pro multicore. Mám to chápat tak že se to aktuálně nepoužívá ani u x86 verze? to samí firewall? tak nějak těžko trávim, že mikrotik si udělá svojí featuru pro rozklad na více jader sám a není to nativně v kernelu a nabízí se další otázky na toto téma.

[ppp76]

Nahozeno na CCR , nabehlo , uvidime jak rebooty

[rado3105]

rc6, rc7 nahodne mrzlo, bolo potrebne vytahovat z elektriny.... uvidime ako rc8...
v6 ma od stability este velmi velmi daleko....

[ppp76]

Me nezamrzlo ani na jednom bordu jen dealo nahodne rebooty nekdy jednou nekdy i 3 x za den

[Pintero]

nahnal jsem ji do RB2011L, co mam na stole a rebooti se stale

[Majklik]

hmm, zdá se že už s v6 zkončili. Žádný podstatný vylepšení dlouho nebyly, jenom samí "dodělávky"

Také se obávám. Nějak jsem doufal, že když je to řada 6, tka se konečně opřou do IPv6 a bude použitelné. Evidentně mají plnou hlavu CCR a budou se snažit to dokopat do plně funčního stavu (což je velmi žádoucí) a ne přidávat vlastnosti.
Nafasoval jsem několik lokalit (pár tisíc km na východ) a ty jsou už IPv6 only připojeny, žádné IPv4 a při pokusu použít RouterOS velice rychle člověk zjišťuje, že v ROSu je IPv6 hezký doplněk k IPv4 síti, ale ne pro čistě IPv6 síť...

chybí mi tam ta stabilita u všeho. Jako na v5.22 si nemůžu stěžovat ale co si budeme říkat, něco totálně stabilního bylo naposledy ve v3.30. I v4.17 se jevila jako "psychologicky" "použitelnější". U v5 jsem byl ochotnej jít na RC verzi v raných časech v5 globálně u všech klientů ale u v6 ten pocit nemám. Mám sice v6rc6 na dvou spojích abych viděl co to dělá ale jako moc šťastnej nejsem.

No zajímala by mě ta optimalizace routování pro multicore. Mám to chápat tak že se to aktuálně nepoužívá ani u x86 verze? to samí firewall? tak nějak těžko trávim, že mikrotik si udělá svojí featuru pro rozklad na více jader sám a není to nativně v kernelu a nabízí se další otázky na toto téma.

Tak nějak, je to celkem nestabilní. Typické chování V6RC7 verze po cca 12 hodinách běhu:
[admin@MDPSKRB2] > ping 8.8.8.8
HOST SIZE TTL TIME STATUS
132 (No buffer space available)
CPU, pamět, .. hlášeno, že vše OK (ping na IPv6 dopadne podobně). A to stačí, aby na tom běželo pár používaných věcí naráz (OSPFv2, OSPFv3, IPsec, VRRPv2, VRRPv3, GRE, SIT, ...).

Add optimalizace, myslím, že hovoří hlavně o CCR. Na x86 platformě asi multicpu už zvládají a i 1100AHx2 asi ty jádra využívá celkem OK. U CCR je dosti odlišná architeltura a struktura a pro ni vychytak rozkládání zátěže mezí jádra a i s ohledme na vnitřní spojovací trasy bude podstatně horší magie.

Inu, nezbývá si připomenout staré dobré - čím míň ma dané zařízení funkcí, tím lépe je splňuje...

A chybí ti tam něco konkrétního?

Třeba s ohledme na to hanění IPv6 o odstavec víše, tak aktulně celkem fatálně podpora pro nastavení preference dafaultní routy, která se ohlašuje v RA, jde jen o 2 blbé bity, kterými router klientům říká, jak je daný router důležitý (kupodivu to podporují i blbé XPčka). Potřeba pro síť, kde je víc jak jeden router v LAN proti normálním klientům a je používán multihoming nebo stavový firewall. Čili to, co v ciscu nastavuje ipv6 nd router-preference {high | medium | low} . Potřebuji to proto, abych ojebal další věc, co ROS pro IPv6 neumí - policy routing. Opět narazím, jakmile mám víc jak jednu linku. Tento odstavec se dá v síto s only ROS routery částečně ojebat pomocí VRRPv3, ale za cenu, že u multihomingu využívám aktivně jen jendu linku, pokud mám požaqdavke na diverzitu routerů a používání všech tras, tak problém.
Pokud vezmu ROS jako router, který má jít proti koncovým klientům, tak začne rychle chybět podpora pro DHCPv6 bezestavový server (čili nemožnost poslat nastavneí DNS klientům). JE hezké, že ROS podporuje RRDNS volbu v RA, ale majoritní Windows to nepodporují a trvají na DHCPv6.
IPv6 firewall má také některé slabiny, občas nejsou korektně identifikovány ICMPv6 zprávy se vracející jako related. Detail, že to ve firewallu používá blbě překlad na kódy (bere číslování dle IPv4 a ne IPv6). A další drobnosit by s eobjevily.
Nicméně si myslím, že budeme rádi, když letos se dostane CCR do stavu - bez problému nasaditelný s rozumným uptime.

[hapi]

no právě, IPv6. Mám tu na jednu stranu sítě ospfkový ipv6 ale pouze mezi body abych viděl jak to funguje ale dál se mi to moc dávat nechce. Jako nevim co tam řešeji. Mě by stačilo aby to mělo klasický DHCPv6 abych tam viděl kdo si vzal IP. DNSko se s nimi řeší už dlouho a nějak to odmítají.

[Majklik]

K nepodpoře klasického DHCPv6 se ani nedivím, že se jim do toho nechce. Jednak autoři specifikace museli dlouho dostávat hodně podřadné zboží od svých dealerů, že jim pěkně vyžralo mozek, takže to naimplementovat v plné podobě je pakárna. A potom beru to pragmaticky - v IPv6 je povinná autokonfigurace, tu umí vše. K tomu ale přibejvá, že většina věcí, pokud podporuje DHCPv6, tak jen bezestavově pro získání DNS, proto aspoň toto považuji za nutné, abych měl odvahu to dát zákošovi domů jako home router. V případě krabičky na straně ISP bych se spokojil minimálně s podporou LDRA (DHCPv6 relay agent), že si zkrátka požadavky přepošlu z RBček do centra, tam nahodím dva plnohodnotné DHCPv6 na linuchách a obsloužím přes toto. A také při přidělování adres pomocí DHCPv6 nejde použít podvod s off-link adresama, který při autokonfiguraci umožňuje nasimulovat v RBčku ND proxy, což v kombinaci s DHCPv6 nefunguje (alespoň ne pro Windowsy - a máme tu další chybějící funkci ND proxy, která by se pro ISP nasazení celkem hodila).
S OSPFv3 jsem vážnější problém neměl. Trošku podivná je multiarea funkčnost a pak celková nestabilita V6. Na 5.2x to jede celkem OK, nebál bych se ho.
Jsem zastáncem řešení, že zákoš má doma svůj router, na WAN straně je jen link local adresa, přes DHCPv6 PD dostane /60, z kterého si přehodí na LAN /64 co chce. Proti tomu na ISP straně je RBčlo, co proti klientům jede DHCPv6-PD server (a dělá jim i default routu) a nahazuje si přidělené bloky do OSPF a dál dovnitřku už jede OSPFv3.
Ale když mi podpoříš tu defualt routa prioritu (RFC4191), tak ti podpořím to DHCPv6. Asi bude třeba jim poslat zase vřelý dopis s dotazem, co znamenají ty došlé bufry (je to na RB433UAH)... a proč mi právě za zádmi zapípala RB800 v rebootu, což dělá celkem pravidelně, od dob nasazení V6...
Ale to DHCPv6 a spol je už spíše na jinou rubriku, ať nezasíráme téma nesplnitelných očekávání.

[ppp76]

CCR zatim dva dny bez rebootu

[Majklik]

Takže dle support v RC8 verzi má DHCPv6 server podporovat posílání nastavení DNS klientům. Ale dle letmého pokusu se nějak RBčko neobtěžuje odpovídat na výzvy.

[honzam]

The latest RouterOS v6rc8 build is now available in your account. Please note that in addition to fixes/improvements mentioned in the Changelog, this version also adds an alpha version package for OpenFlow support. If possible, please test it, and send us your suggestions and observations.

Documentation link: http://wiki.mikrotik.com/wiki/Manual:OpenFlow

For information about OpenFlow see https://www.opennetworking.org/

Currently RouterOS implements OpenFlow version 1.0.0 required features. Support for newer versions, optional features and switching hardware acceleration are to be added. Current implementation should be considered experimental - NOT production ready and is available for evaluation purposes. Please contact support with feature requests and bug reports.

OpenFlow support is available as standalone openflow package.

OpenFlow feature overrides regular packet processing functionality - packets that are received on interfaces that are OpenFlow switch ports, will not pass through the regular networking stack unless OpenFlow controller sets up flows that enable this. Due to this care must be taken to not disable access to the device when configuring OpenFlow.

Currently only unencrypted TCP is available as the communications channel between RouterOS OpenFlow switch and controller.

The OpenFlow package can be found in the "all_files_6.0rc8.zip" archive.

[rado3105]

vyuzitie toho openflow? akosi ma nic nenapada