IPv6 Routování

[hapi]

ano, všechno toto mám a ipconfig hlásí stále defaultní dns servery od microsoftu. ipv4 nemám nahozený. Testuju to přes wifi mkčka.

[Majklik]

Tak zkus jako admin do toho kopnout přes:
netsh interface ipv6 reset
a reboot woken.
Jinyk, pokud v tom ohlášení routeru zapneš managed-address-configuration=yes místo other-configuration=yes, tak DNS adresu nedostaneš. Ale i tak by měla být snaha vidět pokus o kontaktování DHCPv6 serveru.

[hapi]

snaha tam je, je tam dhcp recv packet ale send už tam neni
zkusim to ještě wireshark co to bude říkat.

[Majklik]

A co je komplet v logu k tomu u MKčka?
Jinka verzi mám: 6.5rc1 build-time: Sep/26/2013 13:52:06 na RB1100AH
Do logu to hodí:

Kód: Vybrat vše

0:01:15 dhcp,debug,packet recv server: server1 fe80::64bd:abf6:eba7:2e3a -> ff02::1:2
00:01:15 dhcp,debug,packet type: info_req
00:01:15 dhcp,debug,packet transaction-id: 5162b6
00:01:15 dhcp,debug,packet  -> clientid:  00010001 15b23dfe 5c9ad8e0 406f
00:01:15 dhcp,debug,packet  -> oro: 17 23 24 32 
00:01:15 dhcp,debug,packet  -> elapsed_time: 0
00:01:15 dhcp,debug,packet  -> vendor_class:  00000137 00084d53 46542035 2e30
00:01:15 dhcp,debug,packet send server1 -> fe80::64bd:abf6:eba7:2e3a%24
00:01:15 dhcp,debug,packet type: reply
00:01:15 dhcp,debug,packet transaction-id: 5162b6
00:01:15 dhcp,debug,packet  -> clientid:  00010001 15b23dfe 5c9ad8e0 406f
00:01:15 dhcp,debug,packet  -> serverid:  00030001 000c42eb 2eec
00:01:15 dhcp,debug,packet  -> dns_servers: 
00:01:15 dhcp,debug,packet    fd49:2990:4616:1001::254
00:01:15 dhcp,debug,packet    fd49:2990:4616:2001::254
00:01:15 dhcp,debug,packet    fd49:2990:4616:3001::254


[hapi]

no nekecej, po tom nakopnutí a restartu už to dostalo DNS servery, hurááá. Díky.

[hapi]

ha, takže, nechám to chvíli ustát a dnska zmizí

[Majklik]

Jestli jsem pochopil, tak jsi se stal obětí jedné z "vlastností" Windows 8, kdy zapomenou posílat DHCPv6 requesty. Příslušná nadávka v kombinaci s resetem je zase na nějakouu dobu má umravnit...
Inu, příliš horká a nevyzrálá novinka...

A snaží se pak ptát znova? Respektive, fungují ty DNS a zkusí se na ně položit nějaký dotaz? Aspoň Win7 si ty servery nějak tesutje a když nefungují, tak je po čase ignoruje.

[hapi]

tahle rc verze je teda krutě nedodělaná. Normálně mi to napíše do logu že se router resetnul z důvodu napájení a přitom jede dál
ono tam je teda hoodně věci nedodělaných.

[Majklik]

Jo, má to do vydání daleko, ale je třeba sledovat, co provádí a usměrńovat. Za co další je budeme prudit?

Ještě mě napadlo, že ti to zmizí, teoreticky by to mohlo být tím, že v odpovědi není vložen timelife? Možná, jeslti můžeš, zkusit si přidělit z ISC DHCP, zda to udrží, ten tam timelife vkládá, když je v cfg uveden (option dhcp6.info-refresh-time 86400;). Ale do MKáček je vhodné kopnout, ať to tam dodělají a dávají čas asi dle lease time...

[hapi]

hmm, nemám dhcpv6 server v linuxu a sem trochu daleko od domova. Sem rád že sem si doma uzurpnul RBčko a šmudlim to tu na notebooku zapíchnutý v ethernetu

jinak ty časy nevim. Nejsem takovej odborník. Hmm ale jasně, asi by to mělo bejt podle lease time v dhcp serveru. Mohly by tam taky přidat, když už máme timeout, seznam s tím kdy to komu co dalo s odpočtem timeoutu od posledního dotazu. To by bylo hodně cool.

Máš nějaký vysvětlení na ty ostatní časy v ND?to RA Lifetime atd... něco sem o tom čet ale nějak moudrej z toho nejsem. Defakto to znamená že když to nechám v defaultu tak je to ok.

[hapi]

Jo, má to do vydání daleko, ale je třeba sledovat, co provádí a usměrńovat. Za co další je budeme prudit?

Cisco NEL
pak jak tak koukám opravit discovery na ipv6
autoupdate biosu
opravit NV2 při malích tocích
pořešit něco na ptp spoje když NV2 je tak nemožná.

[Majklik]

hmm, nemám dhcpv6 server v linuxu a sem trochu daleko od domova. Sem rád že sem si doma uzurpnul RBčko a šmudlim to tu na notebooku zapíchnutý v ethernetu

Pokud jsi někde na cestách, tak se máš věnovat milence/menželce/sudu/... a ne nějakých pochybným RC od MKček.

jinak ty časy nevim. Nejsem takovej odborník. Hmm ale jasně, asi by to mělo bejt podle lease time v dhcp serveru. Mohly by tam taky přidat, když už máme timeout, seznam s tím kdy to komu co dalo s odpočtem timeoutu od posledního dotazu. To by bylo hodně cool.

Tohle asi neprojde. Zkrátka bezestavové DHCP bylo určeno pro co nejjednodušší implementaci v krabicích, kdy nic si pamatovat nemusí a je na klientovi, aby v daných intervalech se dotazoval znovu... Myslím, že MK neimplmentuje důležitější věci, jak toto sledovátko IPv6 adres...
Jinak Win7, když jepolžka lifetime v DHCPv6 informační odpovědi přítomna, tak se v daných časech ptá znova, čili po přidání této položky a zapnutém logu máš problém také řešen.
To s tím win8, že to zahodí, pokud tam není timeout, je jen spekulace. Druhá možnost je, že si ty DNS otesutje a když nejedou, kašle na ně.

Máš nějaký vysvětlení na ty ostatní časy v ND?to RA Lifetime atd... něco sem o tom čet ale nějak moudrej z toho nejsem. Defakto to znamená že když to nechám v defaultu tak je to ok.

Některé jsou celkem zajimavé a některé věci tam i chybí...
Defualt hodonoty OK, na co se hodí šahat:
ra-interval - v jakém intervalu (volí náhodně) opakuje ohlášení routeru, pokud to jde přes wifinu, tak dávám kratší časy (10-60), kdyby se něco ztratilo.
ra-delay - minimální čas mezi dvěma vyslanýma RA, pokud o něj klient žádá, 3 sec asi v pohod,ě pokud na LAN není stovky klientů.
ra-lifetime - mělo by platit, že ra-interval-max<=ra-lifetime, bezpečnější (a doporučneo je) ra-interval-max<=3*ra-lifetime. Tohle říká, jak dlouho od slyšeného RA může klient tento router používat jako default bránu. Takže pokud se RA ztrácí a lifetime je malý, vypadává routing. Existuje krásná věc, pokud dáš lifetime na 0, tak se klient konfiguruje dle ohlášení RA, ale neroutuje přes tento router. Např se dá použít, že v netwatch hlídám dostupnost IPv6, když vypadne, skript shodí lifetime na 0 a klienti zahodí defualt routu na IPv6. IPv6 pak jede v rámci LAN sgmentu, ale řada implementací pro spojení mimo lokál přejde okamžitě na IPv4, takže ztráza IPv6 neznamená, že to chcípne kompletně.
reachable/retransmit time - přikazuje klientům, jak dlouho mají mít záznamy o sousedech v discovery jako aktivní/v jakém intervalu opakovat při neodpovědi detekci. Asi není důvod nastavovat.

Potom máš timeouty u volby prefixů, je tam default nebo můžeš pro každý přidaný prefix nastavit. Pokud v definici IPv6 adresy škrtneš advertise, přidá se do /ipv6 nd prefix s default hodnotama.
valid-lifetime - jak dlouho od poslendího RA může klient mít tuto adresu přidělenu (a přijímat příchozí spojení)), pak ji zahodí (pokud na ni nemá aktuálně otevřené spojení).
preferred-lifetime - jak dlouho od poslendího RA má klient používat adresu z toho prefixu při navazování nových spojení.
Asi nemá smysl měnit v jendoduchých aplikacích. Časy by měly být výrazně vtěí, než ra-interval-max
Já s tím čaruji tam, kde mám víc konektivit pro dynamické přečíslování. Mám linku A a B, každá linka má svůj prefix. V IPv6 mám adresy dány bez advertise a v /ipv6 nd prefix je mám uvedeny ručně. netwatch hlídá, zda jede linka A, když ano, v advertise prefix A propaguji s časy 1m:2m a prefix B s 0:0 (klient prefix ignoruje). Když linka A chcípne, tak netwatch přehodí defualt routu na linku B a /ipv6 nd prefix prohodí časy prefix A 0:0, prefix B 1m:2m. Klienti se přečíslují a jedou hned s novými adresami přes správbou linku. Aby loklní IPv6 komunkace jela bez přerušování, kleinti mají ještě prefix v ULA segmentu, který se nemění.

[Majklik]

Jo, má to do vydání daleko, ale je třeba sledovat, co provádí a usměrńovat. Za co další je budeme prudit?

Cisco NEL
pak jak tak koukám opravit discovery na ipv6
autoupdate biosu
opravit NV2 při malích tocích
pořešit něco na ptp spoje když NV2 je tak nemožná.

Já to myslel z pohledu IPv6.
S NEL souhlasím. Discovery je nemocné, tkatéž IPv6 nad bridge a VRRP má některé slabiny.

S NV2 jsi idealista, IMHO problém přesáhl schopnosti vývojářů, stejně jako problémy virtual linku v OSPF (a než člověk připravil názorné jendoduché demo s třemi routery, tak mu vn něm vypluje další nehezký bug v OSPFv2).

[Majklik]

Jen tak mezi řečí.
Při obnovení konfigurace (backup) na jiném zařízení (jina MAC) mi zůstane DUID pro IPv6 z původního a nelze ho změnit.
Jak resetnu DUID nebo MK donutím k opětovnému výpočtu z MAC adresy? Nechci všechny MK co už mám nastavené
resetovat.

Jsem to zkusil supportu podsunout, co s tím, když jsem se dohadoval o něčem kolem DUID, že by mohlo jít po backup a restore na jiný RB vyvolat reset DUID, když reset MAC adres na fyzické jde snadno udělat (/interface ethernet reset-mac-address etherX) a support, že backup/restore je určen jen pro jeden RB a ne přenášení dál, takže problém neexistuje a má se to vyresetovat komplet celé.

[hapi]

přesně tak. Backup je pouze na zálohu konkrétního stroje. Pokud někdo chce zálohy zařízek tak používejte "/export compact". To je lehce odlišnej export a exportuje pouze to co se líší od defaultní konfigurace.