IPv6 Routování

[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

Kód: Vybrat vše

/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:

Kód: Vybrat vše

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

[hapi]

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.

tohle se mi líbí až na to ospfko u klienta ale i to se dá překousnout. Ojebat bridgem myslíš jako že vytvořim bridge a do něj hodim lanku? pak by zůstávala aktivní i po odpojení eth což je ok.

Chápu "výhodu" DHCPv6-PD ale takhle u nás síť nefunguje. To bych musel mít nastavení na apčku a mít tam nějaký statiky který se budou přiřazovat klientům a to nejde. APčko se musí vzít, nastavit ipčka a wifina a musí všichni ject a to i když se mění. Nastavení OSPFka je samozřejmostí ale ládovat tam statický tabulky pro dhcp server je u nás na škodu.

To abych teda měl co apčko to area a na poslední v6 verzi. Určitě pak klienti na jiný area nedostanou routy z jiný area? Kdyby to takhle fungovalo tak by stálo za to šašit s areama peer ap. Co když bude backbone a na ní apčka po kabelu a na wifi pod jinou areou ale na každym apčku bude stejná area na wifi části? to asi nepůjde, že?

[ludvik]

Už lze dělat statické DHCP příděly dle MAC, nebo stále jen dle GUID? A obecně: ono jim to už funguje? Před nějakým časem jsem tu dával k dobru zjištění, že je to u MK zatím k ničemu ... nešlo dát /64, muselo se víc. A ještě k tomu jsem nepřišel na to, jak mu říct, na jaké rozhraní to přiřadit. GUID vyžadoval v přesném formátu (na rozdíl od RFC, kde je to vcelku libovolné). Neuměl nakonfigurovat defaultu klientovi (nevzal routu přes RA) a leccos dalšího, kdybych si tak vzpomněl ...

[Majklik]

tohle se mi líbí až na to ospfko u klienta ale i to se dá překousnout. Ojebat bridgem myslíš jako že vytvořim bridge a do něj hodim lanku? pak by zůstávala aktivní i po odpojení eth což je ok.

Nic není dokonalé. Je to o tom, vybrat si menší zlo.
Ano, udělat bridge-ether1, do něj strčit jen ether1. Na bridge je nutno (tradičně) nastavit admin MAC adresu, jinak bude problém, když RBčko nastartuje a nebude ether1 aktivní.

Chápu "výhodu" DHCPv6-PD ale takhle u nás síť nefunguje. To bych musel mít nastavení na apčku a mít tam nějaký statiky který se budou přiřazovat klientům a to nejde. APčko se musí vzít, nastavit ipčka a wifina a musí všichni ject a to i když se mění. Nastavení OSPFka je samozřejmostí ale ládovat tam statický tabulky pro dhcp server je u nás na škodu.

Jo, kdyby se bindingy pro DHCPv6-PD daly načítat z Radiusu, bylo by to hezké, podobně jak IPčka na IPv4 pro DHCP. System 4ISP neumí naplnit '/ipv6 dhcp-server binding'? Pak by možná bylo po problému.

To abych teda měl co apčko to area a na poslední v6 verzi. Určitě pak klienti na jiný area nedostanou routy z jiný area? Kdyby to takhle fungovalo tak by stálo za to šašit s areama peer ap. Co když bude backbone a na ní apčka po kabelu a na wifi pod jinou areou ale na každym apčku bude stejná area na wifi části? to asi nepůjde, že?

Ne, co APčko, ale všechny routery, kde je puštěné OSPFv3, musíš mít na ROS6.2+. Kde bude starší ROS, tak se nedostanou prefixy z těch dalších areí, bohužel.
Ale jinak ano, pokud budeš mít celou síť na ROS6.2+ a uděláš sektory jako další area typu stub, tak to bude u klientů fungovat tak, že budou mít routy na ostatní klienty v dané místní arei (takže dle toho, kolik tam bude klientů), plus pouze default routa ukazující k backbone arei (základní chování stub arei). A opačně, pokud všichni klienti v arei budou mít ty /64 nasekány z jedné /56, tak můžeš zase udělat agregaci směrem do backbone a celé AP se bude dál šířit jako jedna /56 a ne tuna /64 bloků.
To poslední, chápu, že se nechceš s tím srát a všechny AP uděláš jako areu např 0.0.0.1, která bude tím pádem 100x vedle sebe jako nespojitá? Z pohledu kostelního pořádku OSPF je to přípustníá konfigurace a bude fungovat, pokud nedojde k překrývání prefixů (nesmí ti takto vyexportivat stejný prefix ze dvou různých AP). Myslím, že i tohle by ROS mohl ustát. Pro OSPFv2 to zvládá.

[ludvik]

Hele ... Hapi - nebyls to náhodou ty, co tvrdil, že u klientů OSPF máš?

[Majklik]

Už lze dělat statické DHCP příděly dle MAC, nebo stále jen dle GUID? A obecně: ono jim to už funguje? Před nějakým časem jsem tu dával k dobru zjištění, že je to u MK zatím k ničemu ... nešlo dát /64, muselo se víc. A ještě k tomu jsem nepřišel na to, jak mu říct, na jaké rozhraní to přiřadit. GUID vyžadoval v přesném formátu (na rozdíl od RFC, kde je to vcelku libovolné). Neuměl nakonfigurovat defaultu klientovi (nevzal routu přes RA) a leccos dalšího, kdybych si tak vzpomněl ...

DHCPv6 neumí přidělovat v principu dle holé MAC adresy, protože se často provozuje tam, kde MAC vůbec nejsou. Je zobecněné. Takže i ROS server DHCPv6-PD přiděluje na základě DUID+IAID.
DHCPv6-PD klient v ROS si DUID generuje dle MAC adresy na první síťovce v systému (první dle BIOS pohledu) a IAID dává jako index interface na kterém je pak DHCPv6-PD klient puštěn. Dneska už jde aspoň se podívat, jaký DUID si vybral:

Kód: Vybrat vše

/ipv6 dhcp-client print detail
Flags: D - dynamic, X - disabled, I - invalid
 0    interface=pppoe-out1 pool-name="pd6" pool-prefix-length=64 status=bound
      prefix=fd49:2990:4616:4370::/64 expires-after=2d23h20m11s
      duid="00030001000c42345d2a" add-default-route=yes use-peer-dns=yes


A jak vidíš, tak klient už má parametr, že má i nastavit defualt bránu (bude ukazovat na DHCPv6-PD server).
Na serveru pro přidělení segmentu napevno bude:

Kód: Vybrat vše

/ipv6 dhcp-server binding
add address=fd49:2990:4616:4370::/64 disabled=no duid=000c42345d2a iaid=12 life-time=3d


Také si můžeš všimnout, že jde přidělit takto jen jeden /64 blok. Nejde jednomu klientovi naráz přidělit (a ani definovat) víc IPv6 bloků.
Jaký interface v klientu pak ten blok dostane, je dáno tím, kterému iface přidělíš ten pool pd6. DHCPv6-PD klient vytvoří dynamický pool zadaného jména a interfejsům pak říkáš, že z toho poolu si mají vzít blok. Pokud v poolu nebude dost místa, tak se na některé ifaces nedostane.

Kód: Vybrat vše

/ipv6 address
add address=::1 from-pool=pd6 interface=bridge-lan


Výsledek na klientovi:

Kód: Vybrat vše

[admin@MikroTik] > /ipv6 pool print
Flags: D - dynamic
 #   NAME               PREFIX                                      PREFIX-LENGTH
 0 D pd6                fd49:2990:4616:4370::/64                               64
[admin@MikroTik] > /ipv6 pool used print
POOL         PREFIX                                      OWNER        INFO       
pd6          fd49:2990:4616:4370::/64                    Address      bridge-lan
[admin@MikroTik] > /ipv6 address print where interface=bridge-lan
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
 #    ADDRESS                                     FROM-POOL INTERFACE   ADVERTISE
11  G fd49:2990:4616:4370::1/64                   pd6       bridge-lan  yes     
13 DL fe80::ff:fe00:1/64                                    bridge-lan  no       
[admin@MikroTik] > /ipv6 route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 ADS  ::/0                     pppoe-out1                      1
 1  DS  ::/0                     fe80::1f0%pppoe-out1            1
 2 ADC  fd49:2990:4616:4370::/64 bridge-lan                      0
 3  DSU fd49:2990:4616:4370::/64                                 1
[admin@MikroTik] >


Ty dvě default routy jsou následek, že jednu udělá PPPoE klient a druhou DHCPv6-PD.
Jinak ROS6 se nechá dneska i ukecat, že se má zkusit nakonfigurovat dle ohlášení jiného routeru i v případě, že má roli routeru (což dle kostelního pořádku pro IPv6 dělat nemá). Ale funguje to dost vachrlatě a chvílema to selhává:
/ipv6 settings set forward=yes
/ipv6 settings set accept-router-advertisements=yes

[hapi]

Hele ... Hapi - nebyls to náhodou ty, co tvrdil, že u klientů OSPF máš?

měl sem ale táta vůbec nechápal. Síťařině vůbec nerozumí. To je težký když makáš s někym kterej označí každou věc který nerozumí na hovadinu. Říkal sem mu, že to buď pude po dobrém (ipv4 a ospf a pak podobná situace na ipv6 kdy si na to už zvyknem u ipv4) nebo po zlém (rovnou ipv6 takže nátlak jak z ipv6 tak ospf k tomu a celej ten cirkus kolem). Ono to navíc nemělo žádnej efekt. Mě se to celkem líbilo ale co no.

[hapi]

Ano, udělat bridge-ether1, do něj strčit jen ether1. Na bridge je nutno (tradičně) nastavit admin MAC adresu, jinak bude problém, když RBčko nastartuje a nebude ether1 aktivní.

jo tohle chápu, tady obvykle hodim ethernet do bridge a počkám si až bridge dostane macovku ethernetu a pak jí zkopíruju a hodim do administrační macovky. Dělám to tak všude co jsou bridge.

Jo, kdyby se bindingy pro DHCPv6-PD daly načítat z Radiusu, bylo by to hezké, podobně jak IPčka na IPv4 pro DHCP. System 4ISP neumí naplnit '/ipv6 dhcp-server binding'? Pak by možná bylo po problému.

to sice jde ale celí se to zbytečně komplikuje. Ani vlastně neřešíme macovky klientských jednotek a podobně. Celý jsme to vyhodnotili jako zbytečný plýtvání prostředků. Ono jak říkám, apčko musí bejt nastavený pro to, musíš ho mít zanesený v systému, musíš klientskou jednotku mít zanesenou v systemu. Nic nemůžeš jenom tak vyměnit atd.. To se nám prostě nikdy nelíbilo. Přijedu ke klientovy, vytahnu SXT, zjistim si ze systemu jeho IP a ssid na který se napojuje, napíšu to do scriptu, ten spustim na SXT a vyřešeno. Jednotka připravena. APčko odejde, vyměnim ho, nastavím ip, ssid, kanál a jdu domu. Ostatní věci mě netrápí. Všechno ostatní jenom zdržuje opravy atd.. tedy aspoň z našeho pohledu. Nikomu to neberu

No a jak na tom je IPv6 za klientskou jednotkou? zapnu advertise a hotovo? co vim tak dns se stále nepřenáší a vlastně ani nemám šanci zjistit kolik zařízení a jaká jsou připojená u něj doma, že? nebo se pletu?

[ludvik]

Majklik: jo, s tím DUID mě naštvali. Někdy se to hodí, ale většinou ne. Viz např. přeinstalace windows ... Ale tu MAC do RFC už dodělali. Viz třeba přednáška od Satrapy nedávno na konferenci v Srní.

[Majklik]

Majklik: jo, s tím DUID mě naštvali. Někdy se to hodí, ale většinou ne. Viz např. přeinstalace windows ... Ale tu MAC do RFC už dodělali. Viz třeba přednáška od Satrapy nedávno na konferenci v Srní.

Windowsy používají DUID-LLT, čili složení MAC adresy a času instalace systému (DUID začinající 0001). Což je po přeinstalaci nemilá změna (ale jde to v registrech přepsat). ROSy používají DUID-LL (to 0003 na začátku), takže DUID jen dle MAC adresy.
Moment, ale to je jen pro DHCPv6 relay. Relay agent vkládá do relaz zprávy navíc MAC adresu žádosti. Jiná věc je, kolik DHCPv6 serverů se dle toho umí řídit.

[Majklik]

to sice jde ale celí se to zbytečně komplikuje. Ani vlastně neřešíme macovky klientských jednotek a podobně. Celý jsme to vyhodnotili jako zbytečný plýtvání prostředků. Ono jak říkám, apčko musí bejt nastavený pro to, musíš ho mít zanesený v systému, musíš klientskou jednotku mít zanesenou v systemu. Nic nemůžeš jenom tak vyměnit atd.. To se nám prostě nikdy nelíbilo. Přijedu ke klientovy, vytahnu SXT, zjistim si ze systemu jeho IP a ssid na který se napojuje, napíšu to do scriptu, ten spustim na SXT a vyřešeno. Jednotka připravena. APčko odejde, vyměnim ho, nastavím ip, ssid, kanál a jdu domu. Ostatní věci mě netrápí. Všechno ostatní jenom zdržuje opravy atd.. tedy aspoň z našeho pohledu. Nikomu to neberu

Jo, každý má svůj systém. Pro to tvoje je asi nejlepší dotáhnout to OSPFv3 až na koncovou jendotku a skript pro konfiguraci doplnit i o zadání IPv6 prefixu pro LAN.
Někdo jede PPPoE, kde je sojovacím článkem jméno/heslo (nebo se na jméno heslo kašle a jede se dle portu ve switchi, když to je FTTB a podobné), někdo spojuje přes MAC a apk by se hodilu ta možnost DUID/IAIA pro DHCPv6.

No a jak na tom je IPv6 za klientskou jednotkou? zapnu advertise a hotovo? co vim tak dns se stále nepřenáší a vlastně ani nemám šanci zjistit kolik zařízení a jaká jsou připojená u něj doma, že? nebo se pletu?

Ten segment definuješ s advertise=yes, tím se automaticky přidá mezi /ipv6 nd prefix. Paranoidně bych si nastavil zapnutí /ipv6 nd jen pro ten bridge-ether1 a je zajištěna propagace routeru a prefixu pro autokonfiguraci. Tohle musí podporovat každé zařízení s IPv6 podporou.
DNS se dá v ohlášení routeru posílat, zapnout advertise-dns=yes a pokud v /ip dns set servers=... jsou zadány i IPv6 adresy, tak tyto se budou ohlašovat v RA. Bohužel na tento systém Wokna a řada dalších kašle a vyžaduje bezestavové DHCPv6, což ROS neumí (pokud ho tiše nepřidali v posledních verzích). Takže pro okna nejde IPv6 DNS jednoduše nakonfigurovat. Oprvdu ten DHCPv6 server odpovídal jen na PD žádosti a bezestavové odmítal jako neznámé.
Teoreticky by mohlo jít použít DHCPv6 relay agenta, která v ROSu už je, takže pustit si někde klasický DHCPv6 server na linuxu, v klientských krabicích udělat relay na ten server a ten by možná dokázal na ty požadavky odpovídat. Pak se ještě musí zapnout v RA other-configuration=yes, aby okna nebo jiný klient se začal o bezestavové DHCPv6 pokoušet.
A poslední možnost je v síti provbozovat DNS server na site well know DNS adresách. Toto bylo zrušeno, ale řada klientů se to snaží stále používat (na adresách fec0:000:0000:ffff::1, fec0:000:0000:ffff::2, fec0:000:0000:ffff::3), ale je to na vymření.
Výsledek = usilovně řvát na Mikrotiky, ať zapracují na podpoře toho bezestavového DHCPv6, aspoň pro poslání DNS adres.... (v DHCPv6-PD odpovědích ho posílají, opět berou IPv6 adresy z /ip dns).

Ne, rozumně jednoduše nezjistíš, kolik IPv6 fungujících krámů tam zákoš má, když nebudeš čmuchat obsah ND cache na jeho routeru a podobné obskurní postupy.