Zkoušel jste někdo, zda jim to vůbec funguje (ROS 5.13)? Hraju si s tím proti (relativně) čistému linuxu - widedhcp6. A ať dělám, co dělám, linux si PD prostě nevezme. Vidím, že se dotazuje, ale mikrotik mu neodpoví ani "trhni si", prostě ani paket.
Pool definovaný je, IP přiřazenou interfacu také mám (a je v Used prefixes), v ND zapnuto jak Managed, tak Other Configuration.
Vše ostatní funguje, bezestavová konfigurace je ok.
❗️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
Mikrotik IPv6 prefix-delegation
Dalším zkoumáním jsem zjistil, že je zjevně posílán trochu nestandardní DUID. Wide-dhcpd v roli serveru to nevadí, ale mikrotiku jo. Ten je z toho tedy zjevně z obliga.
0 x
Když si hraješ s Prefix Delegation na Mikrotiku, povedlo se ti dostat přidělený prefixy do routovací tabulky? Nevidím pro takovou akci nikde volbu, DHCPv6 server vydá prefix, ale routerboard ho nedokáže naroutovat, protože v routovací tabulce ho nemá...
0 x
Je to jako Static routa. Takže v OSPF musí být redistribute static, sice redistribuce nemám rád, ale v tomhle případě není asi jiná možnost.
0 x
Teď koukám, že mi 5.14 přidala v jednu chvíli routu sama do routovací tabulky taky jako static, při předcházejících testech ale ne (první test byl, že jsem prefix .../64 dal na wlan a širší /56 jako dhcpv6 pool, načež mi dhcpv6 vydalo /62 pro klienta, ale nepřidalo ho do routovací tabulky, protože se překrývalo s tou /64 na wlan rozhraní; druhej test byl, že /56 se s /64 nepřekrýval a při tom se routa do routovací tabulky nainstaluje).
Možná by stálo za to, zkontaktovat vývojáře z Mikrotiku s připomínkou, že by automaticky instalovaná routa měla mít příznak Connected a ne Static, když už má i příznak Dynamic a instaluje/odebírá se automaticky při dhcp vydání/vrácení (při release dojde k automatickýmu odstranění routy).
Možná by stálo za to, zkontaktovat vývojáře z Mikrotiku s připomínkou, že by automaticky instalovaná routa měla mít příznak Connected a ne Static, když už má i příznak Dynamic a instaluje/odebírá se automaticky při dhcp vydání/vrácení (při release dojde k automatickýmu odstranění routy).
0 x
Jestli static, nebo connected asi moc roli nehraje. Mě spíš obecně rozčiluje, že musím mít nějakou redistribuci. Ono mít z poloviny routerů ASBR asi není zrovna ideální.
Kdyby tak šlo ten pool přihodit na rozhraní jako adresu /56, to by řešilo. Jenže to nejde.
Kdyby tak šlo ten pool přihodit na rozhraní jako adresu /56, to by řešilo. Jenže to nejde.
0 x
Pomohla by agregace rout, aby se v OSPFv3 distribuovaly jen celý prefixy... ale nejsem si jistej, jestli to mikrotikácký OSPFv3 umí.
0 x
No jak na co by to pomohlo ...
Podle mě se ale tohle nezměnilo, agregovat můžeš na hranici area. A ani quagga sama neumí zatím arey v OSPFv3.
Podle mě se ale tohle nezměnilo, agregovat můžeš na hranici area. A ani quagga sama neumí zatím arey v OSPFv3.
zajdee píše:Pomohla by agregace rout, aby se v OSPFv3 distribuovaly jen celý prefixy... ale nejsem si jistej, jestli to mikrotikácký OSPFv3 umí.
0 x
Takže z obliga mikrotik rozhodně není. Vypadá to, že si u nich někdo přečetl jenom kousek RFC 3315 a to samozřejmě nestačí.
Z tohoto odstavce vyplývá, že jako DUID může být zjevně naprosto cokoliv. Mikrotik ale vyžaduje striktně formáty uvedené v tomto RFC (zkoušel jsem ovšem jen typ 3) a neakceptuje nic jiného. Kromě toho s tím zjevně ještě pracuje naprosto špatně, protože v Bindings ukáže jen posledních 6 bajtů toho DUID (tedy v případě typu 3 je to MAC), ale musí ukázat i ty 4 bajty před mackou. Je to sice lepší pro člověka, ale je to špatně.
Kód: Vybrat vše
Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT in any
other way interpret DUIDs. Clients and servers MUST NOT restrict
DUIDs to the types defined in this document, as additional DUID types
may be defined in the future.
Z tohoto odstavce vyplývá, že jako DUID může být zjevně naprosto cokoliv. Mikrotik ale vyžaduje striktně formáty uvedené v tomto RFC (zkoušel jsem ovšem jen typ 3) a neakceptuje nic jiného. Kromě toho s tím zjevně ještě pracuje naprosto špatně, protože v Bindings ukáže jen posledních 6 bajtů toho DUID (tedy v případě typu 3 je to MAC), ale musí ukázat i ty 4 bajty před mackou. Je to sice lepší pro člověka, ale je to špatně.
ludvik píše:Dalším zkoumáním jsem zjistil, že je zjevně posílán trochu nestandardní DUID. Wide-dhcpd v roli serveru to nevadí, ale mikrotiku jo. Ten je z toho tedy zjevně z obliga.
0 x
Reakce supportu byla, že mi poslali odkazy na rc verzi 5.15 
Sice už mikrotik sežere (zjevně) libovolný formát DUID, ale stále s tím pracuje špatně. Pokud je to nějaký správný typ, ubere si z toho první 4 bajty. Pokud je to něco jiného, ubere první dva. By mě zajímalo, jestli mají vůbec nějakého fundovaného testera ... kromě nás zákazníků.
Sice už mikrotik sežere (zjevně) libovolný formát DUID, ale stále s tím pracuje špatně. Pokud je to nějaký správný typ, ubere si z toho první 4 bajty. Pokud je to něco jiného, ubere první dva. By mě zajímalo, jestli mají vůbec nějakého fundovaného testera ... kromě nás zákazníků.
0 x
A poslední zprávy:
Hello,
Thank you for information, glad to hear that now it works. The problem when you don't see full DUID will be fixed in one of the future versions.
0 x