classic.ISPforum.cz

Navazuji na diskuzi vzniklou u chyby ve verzi RouterOS 6.3
https://ispforum.cz/viewtopic.php?f=43&t=12852

Jakým způsobem dostáváte nativně IPv6 adresy ke klientovy na přípojce. Každému klientovi je potřeba přidělit minimálně jednu /64. Toto musím nasměrovat. Děláte to staticky nebo dynamicky?

Záleží pro koho. Předpokldádm, že se ptáš na ten poslední spojovací článek k zákošovi. To předtím řeší dynamický routing.
SOHO segment - domácnost/minikancl s jedním routerkem a segmentem dvěma za tím - DHCPv6-PD, segment cca /60 - takže dynamika.
Firemní zákazník - má vstastní IT, víc segmentů, routerů - statická routa, segment nejméně /56 - takže statika.

Máme to podobně. Krom poslední routy ke koncákovy to mám na BGP. Ale ten poslední skok je na statice. Padl tady názor že routa nemá být na gateway na global adresu ale na local. Jak to máš prosím tě ty, konkrétně tu statickou routu.

BGP uvnitř sítě? Kolik set-tisíc routerů tam máš, že nestačilo klasické OSPFv3? Když nepočítám, že v ROS cca 4.10 až 6.1 je chyba v OSPFv3, kdy nešlo používat víc areí, od 6.2 to už opět funguje.

Jinak ani to DHCPv6-PD se nedá doslova brát za dynamický způsob - musím to ručně namlátit do routeru, neumí brát konfiguraci z Radiusu (což je trošku smutné) nebo si to naskriptovat ve vlastní režii. Ani PPPoE na tom není o moc lépe, sice IPv6 prefix jde poslat z Radiusu, PPPoE nahodí IPv6 routu a záznam pro ohlašování routeru na PPPoE tunel, ale autokonfiguračně pro klienta to funguje jen v případě, že konec PPPoE tunelu u zákoše je koncový host a ne router. Takže na straně klienta se to musí konfigurovat ručně, což je naprd. Samozřejmě můžu poslat DHCPv6-PD skrz PPPoE (a pro router, pokud ho tam nechci nastavovat ručně, musím). To funguje, ale ta konfigurace PD serveru je zase staticky na PPPoE serveru... Z Radiusu můžu poslat jen jméno IPv6 poolu, který se má klientovi poslat, ale ten musím dopředu vytvořit ručně. Takže i ta "dynamika" má do pohodlosti daleko - soudruzi by mělo na RouterOS ještě kapánek zapracoval, co se IPv6 týče.

To jsem psal já. A vzhledem k tomu, že většina routerů vůbec nemá na linkách globální adresy, jen link local, tak výběr je jasný. I to DHCPv6-PD, když klientovi přidělí segment, tak udělá na něj routu na jeho link local adresu, takže zákoš ani nemusí mít na WAN straně svého routeru globální adresu. Stejně tak zákošův router (obvkyle něco z řady RB75x/95x), když jede DHCPv6-PD klienta a má nastaveno vytvořit automaticky defualt routu, tak ji udělá na link local adresu DHCPv6-PD serveru. Takže i zde není potřeba globálních adres.
U firemního sektoru je to na domluvě. Asi často jede také link local spojovačka s tím, že default routa zákoše míří na VRRP.

Jinak jsme si všiml, že DHCPv6-PD klient v ROSu, když narazí na klasický DHCPv6 server (ne přidělování prefixů), tak si z něj vytáhne ten segmnet, co server přiděluje po hostech a napere si ho celý. Vtipné...

Sice odbočujeme. Jakou výhodu má OSPF proti BGP? A ano na BGP mám několik set routerů.
Jinak je to jasné, statickou routu pro klienty musím vytvořit tak jako tak. Jestli je na Global nebo Lokal adresu je v podstatě jedno, nepochopil jsem že by v tom měl být nějaký jiný smysl co se týče funkčnosti.

S OSPFv3 je mnohme méně práce, jen naházím seznam interfejsů a už se s okolím na všem domluví. Je také rychlejší v reakci na změny (u BGP jde dohnat dnes použitím BFD, minimálně reakce na výpadek spoje). Nemusím se párat s nastavováním peerů, kdo s kým nebo při takovém počtu předpokládám, že to máš jako konfederace nebo router reflektory, případně mix toho. BGP používám jen mezi logicky samostatnými sítěmi a pak samozřejmě na k dalším AS.

Jo, se zákazíkem se obvykle dynamicky nebavíš, pomiňme velké, kdy připadá v úvahu BGP, těch co by to chtěli/byli toho schopni moc není. Je to statická routa, jen ji buď mlátíš ručně nebo ji za tebe nastaví PPPoE nebo DHCPv6-PD. Proč upřednosťnuji link local jsme psal, při použití globální adresy se trošku liší proces NDP a v některých situacích na linuxu (a derivátech, včetně ROSu) nedopadne dobře. Použití link local sítí je třeba i strategie doporučovaná pány z Cisca. Sami také uvádí, že nepříjemnost vzniká v případě výměny HW. Zde má Mikrotik další mínus, protože na rozdíl od jiných platforem (a fakticky i linuxu) nedovoluje MAC a případně i link local adresu nastavit administrativně, takže bych si dal vždy hlavní router v segmentu na fe80::1 a nastavení brány na všech zákaznických routerech je úplně stejné, ať je v síti kdekoliv (v praxi pro většinu správně vyřeší to PPPoE/DHCPv6-PD oboustranně). Tohle jde ojebávat jen pomocí admin-mac adres na bridge:
/interface bridge add name=bridge-ether1 admin-mac=02:00:00:00:00:01 auto-mac=no
/interface bridge port add interface=ether1 bridge=bridge-ether1
atd.
Mít možnost nastavit přímo LL adresu i bez této opičky by bylo ideální. Apropo, toto nefunguje korektně v ROS5.25, v předchozích OK a v 6 už také zase OK. Verze 5.25 zapomíná po rebootu občas vygenerovat a přiřadit link local adresu na bridge nebo bonding iface. Na VRRP je třeba vygeneruje, ale občas nefungují dokud se nezmění status master/slave. Stačí disable/enable a jede to.

jak se pak dostanu na routery co nemaji globální adresu? a co pak vlastně ukazuje tracert? To už ani neni ftipný jak mi OSPFv3 routuje po lokálních adresách. Takhle sem si dal pěkně traceroute a věděl sem podle ip kde je problem a nebo i trasu kruhu po který jedu což asi teď nepoznám co?

Na router bez globální adresy se dostaneš jen z přímo připojených linek přes link local adresu. Což tě asi vždy neuspokojí, tak se to řeší tak, že router má jen jednu globální adresu pro vše na loopbacku. V případě ROSu, konstrukce takto:
/interface bridge add name=bridge-routerid admin-mac=02:00:00:00:00:01 auto-mac=no
/ipv6 address add interface=bridge-routerid address=2001:DB8::<id oruteru>/128
/routing ospf-v3 interface add interface=bridge-routerid passive=yes area=backbone hello-interval=1 dead-interval=4 cost=1

A normálně přistupuju na tu 2001:DB8::<id oruteru>. Router ji i sám inteligentně používá všude tam, kde potřebuje globální adresu bez ohledu na to, jakým interfejsme se komunikuje (čili pro ICMPv6, v traceroute výpisech, ...). Výhoda je, že vlastní infrastruktura mi nesežere z IPv6 víc, než jeden blok /64, který mi stačí na hodně velkou síť s tímto přístupem. Nemusím vyrábět tuny spojovacích segmentů na linky a ty mít v routovacích tabulkách atd.
Při selhání OSPFv3 tam musíš samozřejmě dojít přes sousední router a z něj ssh/telnet na link local. Ale to s emi už dlouho nestalo, spíše v řadě ROS6 funguje OK IPv6 a IPv4 zkolabuje.

Jinka OSPFv3 funguje jen na link local adresách. Pokud interfae nemá link local adresu, tak na něm OSPFv3 nefunguje. Proto u toho bridge-routerid se natvrdo nastavuje ta mac, dokud bridg enemá mac, nemá ani link local adresu a nejde tak vypropagovat do OSPFv3.
Stejnou techniku s jednou IPv4 adresou an celý router podporují i slušnější platformy.

chápu, to si vyzkoušim. Ono když zdechne OSPFv2 tak se taky musim připojit přes sousední router.

proč nahazuješ na bridge ospf v pasivu?... aha chápu, ostatní dáš all na jeden řádek a posekáno.

Dobrá a co udělat s routou od dodavatele. Mám jí routovat na globální nebo na lokální? Vím že na globální mi to sem tam nechce ject a ani to na ní pingnout.

Když je u OSPF interface jako pasivní, začne se s ním spojený segment (v tomto případě IP) propagovat ihned dál a nečeká se na časování, zda tam není další router.
Uplně stejně to dělám i pro OSPFv2, kdy na ten bridge-routerid dávám IPv4/32, která zároveň slouží jako Router ID do OSPFv2/3 a slouží ta i jako kontrolní IP pro pingy, SNMP, LDP/VPLS, ...

Kde mám dynamické interfejsy dávám all, obvkyle interfejsy vyjmenovávám ručně, protože jim dle nějakých pravidel dávám costy.

Majklik píše:Když je u OSPF interface jako pasivní, začne se s ním spojený segment (v tomto případě IP) propagovat ihned dál a nečeká se na časování, zda tam není další router.

tohle nechápu, přece když dám passive tak na tom iface přestane ospfko pracovat ne?

hapi píše:Dobrá a co udělat s routou od dodavatele. Mám jí routovat na globální nebo na lokální? Vím že na globální mi to sem tam nechce ject a ani to na ní pingnout.

Že by tské jsi narazil na tím blbnouím NDP? Ale to se chová tak, že routing selže, ale přímý ping z toho routeru na globální adresu protistrany se hned chytne. Co mám vyzkoušeno, tak tento problém eliminuje, když máš tu routu definovánu s check-gateway=ping.
Ale pokud ti nefunguje ani samotný ping, tak bude zrada ještě nějaká jiná. Může jím být firewall, pokud je hodně restriktivně napsán ohledně míchání link-local a global adres.
Ve chvíli, kdy ti to nejde, koukal bych prvně do /ipv6 neighbor print detail, zda uvidíš adresu brány s příznakem R (router) ve stavu reachable, když ne, zkusit ping, měla by naskočit bez R jako node a pak hned přeadnout na R, když se zkusí routovat.
Pokud ti tvůj uplink řekne link local k použití, tak ji použij, když ne, nech globální s tím ping testem (nebo netwatch pingající na IP brány přímo z tvého hraničního routeru).
Problém nebývá, kde je s uplinkme BGP sešna, ta nakopávání mrznoucí ND cache zajišťuje v rámci BGP komunikace.

hapi píše:

Majklik píše:Když je u OSPF interface jako pasivní, začne se s ním spojený segment (v tomto případě IP) propagovat ihned dál a nečeká se na časování, zda tam není další router.

tohle nechápu, přece když dám passive tak na tom iface přestane ospfko pracovat ne?

Ne, když dáš iface jako pasivní, tak na daném iface se fyzicky nevysílá a neposlouchá OSPF komunikace, ale IPčka/sítě s tímto ifacem spojené se propagují dál do OSPF.
Či-li typicky spojovací blok k zákazníkovi. Ten iface definuji jako pasivní, tím se mi spojovací blok posílá dál do sítě, ale nevysílám pro a neposlouchám případné OSPF routery na tom segmentu (aby mi tam nestrčil někdo něco škaredáho, co by mi mohlo nabořit moje OSPF, což případně může řešit autorizace na portu). Tímto způsobem můžu eliminovat používání exportování connected rout, které by se propagovaly jako externí routy. Segmenty spojené s pasivním iface se porpagují jako patřící vnitřně do příslušné arei spojené s portem (platí shodně pro OSPFv2/3).

Terminologicky je to tka - že na pasivním interface se nespustí proces OSPF - vysilač/přijmač OSPF komunikace s okolím, ostatní funguje normálně (čili se to pošle dál do sítě, pokud nedám všechny interfejsy jako pasivní ).

tak sem to myslel

A vedlejší efekt toho pasivní je, že neběží čas detekce na další routery na tom segmentu a začne se ten blok propagovat hned ven. Proto paranoidně všude tam, kde to nechci nebo další routery určit nebudou, tak to mlátím jako pasiv.