IPv6 Routování

ef

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?

majklik

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.

ef

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.

majklik

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é...

ef

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.

majklik

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: 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 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. :-(

hapi

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?

majklik

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 auto-mac=no

/ipv6 address add interface=bridge-routerid address=2001::<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::<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. :-)

hapi

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.

majklik

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.

hapi

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?

majklik

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.

majklik

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í :-) ).

hapi

tak sem to myslel

majklik

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. :-)

hapi

zrovna skouším to s tou jednou /128 a nic. Defaultní routa se propaguje ale ta jedna globální se neproroutuje.

update: přepnul sem redistribute connected routes na type1 a už prošla. Je to správně? u OSPFv2 sem tohle dělat nemusel.

majklik

Máš přidán ten iface s tou /128 mezi interfaces v ospfv interfaces? Máš na tom nastavneu tu admin mac adresu a je na tom interface link local adresa aktivní? Do jaké arei máš to přidáno? Jestli máš ROS6.2 níže a namícháno víc areí, tak to nejede.

Redistributed connected ti to vypropaguje, ale není důvod to zapínat.

majklik

Pokud vykradu cfg z nějakého routeru o kus dál v síti (RB1100AHx2, ROS5.25), exportováno jako comapct, ty IPv6 adresy jsou ULA

/interface bridge

add admin-mac=02:00:00:00:00:21 auto-mac=no comment=\

"loopback pro routerid IP" name=bridge-routerid

/ip address

add address=10.84.255.21/32 comment="routerid IP" interface=bridge-routerid \

network=10.84.255.21

/ipv6 address

add address=fd49:2990:4616::21/128 advertise=no interface=bridge-routerid

/routing ospf-v3 instance

set [ find default=yes ] router-id=10.84.255.21

/routing ospf-v3 interface

add area=backbone cost=1 dead-interval=4s hello-interval=1s interface=\

bridge-routerid network-type=point-to-point passive=yes

add area=backbone cost=5 dead-interval=4s hello-interval=1s interface=\

bond-area0 network-type=point-to-point use-bfd=yes

/* tuna dalších ifaces */

A podívám se o kus dále na jiném oruteru:

[admin@MDPSKRB1] > /routing ospf-v3 route print where dst-address=fd49:2990:4616::21

# DST-ADDRESS STATE COST GATEWAY I

0 fd49:2990:4616::21/128 intra-area 1251 fe80::596f:4227 s

[admin@MDPSKRB1] > /ipv6 route print detail where dst-address=fd49:2990:4616::21

Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable

0 ADo dst-address=fd49:2990:4616::21/128 gateway=fe80::596f:4227%sit-edu1-mdpsk2

gateway-status=fe80::596f:4227%sit-edu1-mdpsk2 reachable distance=110 scope=20 target-scope=10

ospf-metric=1251

Toť vše.

hapi

tak odzkoušeno. Je to tak jak říkáš. Na ten bridge se musí hodit macovka jinak se nezaktivuje i když tak vypadá a ip adresa se nezpropaguje. Dál je nutný jak píšeš hodit ospfko na ten bridge v pasivu. Bez toho to nenastartuje po rebootech. Předpokládám že na klientský anténě už stačí jenom hodit globální IPčko na lanku a nastavit ospfko jako všude jinde a je posekáno, že?

ještě mohly udělat to, že když nějaký routy směřují na stejnej router jako defaultní routa tak se nebudou do routovací tabulky přidávat. U klientských zařízeních defakto nic jinýho ani nebude.

majklik

Heh, musíš si vždy ověřit, že lít vodu do koncentrované kyseliny sírové je blbost, že? :-) Ale aspon jsi ověřil, že to tak je. :-)

Add router u klioše. To předpokládám konfig typu SXT/Sextant, wlan1 uplink do tvé sítě, ether1 už domácí segment, přímo koncové komply přes switch, pro IPv4 to SXT dělá NAT, pro IPv6 routing? V tom případě, pokud chceš tahat OSPFv3 až na něj, tak řešení jednoduché - bezdrát na link local adresách, globální adresa/64 na ether1 a ether1 jako pasivní interface v OSPFv3, ať se ti to pošle ven bez nutnosti redistribute-connected. Ptákovinu s bridge-routerid bych na tom nedělal, ať ti zbytečně zase v route tabulkách nepluje tuny /128. Jen když zákoš odpojí ether1 a port spadne z run stavu dolů, tak se ten segment přestane propagovat do OSPF (kdyby jsi chtěl dělat ping testy proti té globálce na ether1). Pokud má zůstat up trvale, možno ojebat bridgem.

Doufám, že v tomto případě nemá koncák přístup do toho SXT, jinak aktivní blbec může s pár kliky sejmout ti celé IPv6... A správně znalý paranoidní jedinec bude mít v tom SXT v IPv6 firewallu ve forwardu bloklé forwardování multicastu, minimálně toho se scope menší jak global.

Povzdech k těm routám. OSPF nedělá automatickou sumarizaci (což je jen dobře). Uvnitř jedné arei se vždy šíří plná routovací tabulka dané arei, plus případně co přijde odjinud. Takže na to SXT, při jedné arei, přijde tuny zbytečných rout.. Eliminovat možno více areama s agregací na hranicích, ale pro OSPFv3 to znaměná, že vše na čem je OSPFv3 puštěn, tak je ROS6.2+.

Jiná možnost je použít to napsané na úvodu s DHCPv6-PD:

Na APčku pustíš DHCPv6-PD server, OSPFv3 končí na něm se zapnutou propagací statických rout. Koncové SXT konfigruvoat jako DHCPv6-PD klient. SXT si vezme IPv6 příděl od AP, nahodí ho na LAN, vytvoří jen jednu default routu mířící na AP. Na AP ti server po přidělení segmentu udělá statickou routu na klienta a přes to redistribute static routes se to pošle dál do OSPFv3. Plusem řešení je, když budeš mít klienta trvající na svém vlastním routeru, tak routery umící IPv6 umí i to DHCPv6-PD, tak mu dáš SXT v bridge wlan1-ether1, za to si zákoš dá toho svého pazneka a také se mu to OK nakonfiguruje.

Další stránka »