IPv6 Routování

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:

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

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

/ipv6 address

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

Výsledek na klientovi:

[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:, fec0:, fec0:), 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.

majklik

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

K tomu mě ještě napadlo, že se do udělat i jinak. Předpokládám, že idea hromadného upgradu celé sítě na ROS6.2+ je děsivá. :-) Takže místo vícero areí, jde použít dvě instance OSPFv3. To bude fungovat i v případě, že dál v síti budeš mít stále ROS5. V tomto případě nejde jen udělat agregace rout klientů dohromady do jedné sumární.

Na APčku budou dvě instance OSPF, jedna jako default, ta bude komunikovat přes uplinky se zbytkem sítě a druhá např jméno sektory, ta bude komunkovat jen s klienty. Povolíš redistribuci rout z instance sektory do instance default a máš vystaráno. V celé síti budeš mít naimportované routy na klienty (jako externí) a v rámci sektoru budou mít klienti jen defualt routu a seznam přímých rout na sousední klienty na tom AP.

Takže cca na AP:

/routing ospf-v3 instance

set name=default redistribute-other-ospf=as-type-1 router-id=6.6.6.6

add name=ospf-sektory distribute-default=always-as-type-1 router-id=6.6.6.6

/routing ospf-v3 area

add instance=ospf-sektory name=sektory

/routing ospf-v3 interface

add area=backbone interface=wlan1-uplink

add area=backbone interface=wlan2-uplink

add area=sektory interface=wlan3-sektorA

add area=sektory interface=wlan4-sektorB

add area=sektory interface=wlan5-sektorC

Na klientovi se nic nemění:

/routing ospf-v3 instance

set name=defualt router-id=6.7.8.9

/routing ospf-v3 interface

add area=backbone interface=wlan1

add area=backbone interface=bridge-ether1 passive=yes

Technicky místo druhé instance OSPF jde použít třeba i RIPng. Jen se pak na APčku musí říci, že místo z other OSPF má ta defualt instalce importovat routy z RIPu... Možná by byl RIPng i v tomto případě vhodnější a na téposlední míli pro pár oruterů na AP nbych s eho nebál. I s ohledme na tvoji oblíbenou strategii sekat SXT jedno jako druhé. Konfigurace klienta je všude stejná a nemusíš se ani srát s router ID. Konfigurace klienta pekelná:

/routing ripng interface

add interface=wlan1

add interface=bridge-ether1 passive=yes

APčko pak:

/routing ospf-v3 instance

set name=default redistribute-rip=as-type-1 router-id=6.6.6.6

add area=backbone interface=wlan1-uplink

add area=backbone interface=wlan2-uplink

/routing ripng

set distribute-default=if-installed

/routing ripng interface

add interface=wlan3-sektorA

add interface=wlan4-sektorB

add interface=wlan5-sektorC

Jinak, proč jsi zkoušel tahat až na klientské jednotky OSPFv2? Přijde mi to zbytečné. Předpokládám, že klientské SXTčko dělá NAT na IPčko na wlan1 iface, takže stačí OSPF končící na AP, kde interfejsy sektorů dám do OSPF jako pasivní a nemusím mít tuny dalších routerů motajících se v OSPF. Chápal bych tam, kde su u klientů neNATuje, ale jen routuje (ať už proto, že mají veřejky na LAN nebo děláš jen jeden CGN aq nechceš mít řetězené NATy).

Trošku jsme to, chudáku EFovi, tady zaspamovali. :-)

majklik

Hapi - ještě k tomu jak dostat ke klientovi DNS IPv6 adresy:

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.

ROS6.4 stále neumí odpovědět na statelesss DHCPv6 info dotaz, takže smolík.

DHCPv6 relay použít jde, jsem si to před chvíli zkusil.

Takže v tom SXTtéčku je třeba zapnot to other-config a nastavit relay agenta:

/ipv6 nd

add interface=bridge-ether1 other-configuration=yes

/ipv6 dhcp-relay

add dhcp-server=fd49:2990:4616:1001::9 interface=bridge-ether1 name=DR1

A na komplu s IP fd49: se pustí ISC DHCP server verze 4.1 s konfigurací v dhcp.conf:

authoritative;

option dhcp6.name-servers 2001:1488:800:400::130, 2001:678:1::206;

#option dhcp6.domain-search "bla.com","neco.porn";

option dhcp6.info-refresh-time 21600;

subnet6 fd49:2990:4616:1001::/64 {

}

subnet6 ff02::1:2/128 {

}

subnet6 fd49:2990:4616::/48 {

}

A šlape to, Wokna7 za tím klientem dostanou patřičné IPv6 pro DNS.

Ten subnet6 fd49::/64 odpovídá tomu, jaký subnet je na síťovce, kde má DHCP server poslouchat. Druhý subnet6 ff02:/128 je úlitba pro ROS6.3 a nižší, kde se chybně vkládá link address do relay zprávy. ROS6.4 to dělá také blbě, ale chytí se to pod tu první definici. Poslední subnet6 fd49::/48 představuje zápis pro korektní DHCPv6 relay agenty, ať odpovíme svým klientům, to se třeba ROS časem naučí správně vkládat. :-(

Takže tímto se dá dosáhnout plná IPv6 konfigurace klienta a nabízet IPv6 only linky. :-)

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

Tak jsem se díval na to, jak je to s tím DUID, co jde zadat do MKčka. Takže už je to relaitvně "volné". Zrada je, že nejde změnit velikost DUID už zadaného záznamu. U nového jde dát cokoliv. A funguje to s určitou úlitbou Mikrotiku. Zadávaný DUID se udává bez prvních dvou bajtů (tam je normálně typ DUIDu). Dále pro DUID-LLT (0001) a DUID-LL (0003) se nedávají aní další dva bajty, které udávají hardwarový typ MAC adresy (pro Ethernet 0001). Sežere jinak už cokoliv jako hardwarový typ (dřívě tupě bral jen Ethernet), včetněnapř. Arcnetu.

Nevadí mu ani DUID-UUID (0004). Takže se dá říci, že tam může být už cokoliv, ani délku neřeší, jen vyhazuje první 2, ve dvou případech 4 bajty.

Také jsem se díval na ISC DHCP, jak třeba funguje u něj to přidělování IPv6 ná základě MAC adresy, takže je to tak, že na MAC na linkové vrstvě kašle. Vezme DUID, když je typu DUID-LLT nebo DUID-LL, tak z něj zpětně vypreparuje vecpanou MAC a přiděluje dle ní (takže ignoruje timestamp u DUID-LLT).

hapi

takže abychom to shrnuly.

aktuální stav na ipv4 je ten, že na klientský jednotce běží DHCP server pro klienta a dává mu ip adresu, dns do jeho počítačů. Důležitý je abych viděl kdy, komu a jaká se přidělila adresa. To v ipv4 neni problém. V dhcp server se kouknu na záložku leases a pořešeno. Je možné toto udělat na ipv6? zaráží mě že takovej základ nejspíš nejde.

majklik

Proč potřebuješ vědět adresu koncového zařízen zákazníkaí?Zákazníka ti identifikuje jendoznačně prefix /64, který jsi přidělil na ten ether1. Kolik tam toho je, ti může být ukradeno. Samozřejmě za předpokladu, že na tom ether1 je jedna koncová přípojka-jeden zákazník. Pokud tam máš switch a celý barák, tak jsi v rejží.

Klasické DHCPv6 v ROSu není. Možno ojebat použitím DHCPv6 relay, přeposlat to na třeba ISC DHCP server na linux a tam přidělovat. Ale aktuální stav je takový, že pro chybu v relay nerozlišíš odkud to příchází. Další stav je takový, že velká část zřízení s podporou IPv6 nepodporuje stavové DHCPv6 a nebudeou fungovat. Podporují pouze bezestavovou autokonfiguraci, jak vyžaduje IPv6 specifikace (plus bezestavové DHCPv6 pro získání seznamu DNS serverů případně - tohl ejde nyní obsloužit i s tím chybným relay v MK).

hapi

klientská jednotka je SXT u klienta. Je za tim jeden klient. Kvůli servisu potřebuju prostě vidět jestli se přidělili ipčka nebo ne. To je základ. Ve většině případů nepotřebuju ke klientova ject, dokážu zjistit spoustu věcí pomocí mkčka. Jednou z nich je jestli si jeho pc vzalo adresu. Dá se tím i poznat jestli se na SXT neodpálilo TX. Pokud nevim kolik počítačů si u něj vzalo ip adresu tak třeba nepoznám při servisu že je něco v nepořádku nebo jestli se třeba nepřipojujou u něj na wifi nějaký černoši atd.. prostě to považujeme za hlavní nástroj při servisu. Což u ipv6 jak tak koukám neni možné což teda vůbec nechápu. To budu totálně slepej protože v ND po chvíli adresy zmizí. Je sice pěkný že zákazník má /64 ale k čemu mi to je když nezjistim jestli si vůbec nějakou adresu z toho vzal? To je docela na hlavu.

No nicméně i kdyby jsme jeli pouze advertise tak předpokládám že dns nepošle... je to problem mkčka nebo windowsu? koho mám jebat?

ludvik

... je to problem mkčka nebo windowsu? koho mám jebat?

Manželku, to ti alespoň pomůže.

majklik

Manželku, to ti alespoň pomůže.

Manželka se zásadně nejede, ale chválí! :-) Jinak člověk za pár minut může mt nějaký dobrej lektvar v kafi a telefonát s okresním patologem, že to bude v papírech infarkt, to jistí. :-(

klientská jednotka je SXT u klienta. Je za tim jeden klient. Kvůli servisu potřebuju prostě vidět jestli se přidělili ipčka nebo ne. To je základ. Ve většině případů nepotřebuju ke klientova ject, dokážu zjistit spoustu věcí pomocí mkčka. Jednou z nich je jestli si jeho pc vzalo adresu. Dá se tím i poznat jestli se na SXT neodpálilo TX. Pokud nevim kolik počítačů si u něj vzalo ip adresu tak třeba nepoznám při servisu že je něco v nepořádku nebo jestli se třeba nepřipojujou u něj na wifi nějaký černoši atd.. prostě to považujeme za hlavní nástroj při servisu. Což u ipv6 jak tak koukám neni možné což teda vůbec nechápu. To budu totálně slepej protože v ND po chvíli adresy zmizí. Je sice pěkný že zákazník má /64 ale k čemu mi to je když nezjistim jestli si vůbec nějakou adresu z toho vzal? To je docela na hlavu.

No nicméně i kdyby jsme jeli pouze advertise tak předpokládám že dns nepošle... je to problem mkčka nebo windowsu? koho mám jebat?

OK, varianta telefonát, co vám ukazuje ipconfig je neprůchozí. :-)

Takže odzadu. Advertise umí DNS servery poslat - ale 99% zařízení to neumí přijmout (moc horká novinka):

/ip dns set servers=8.8.8.8,8.8.4.4,2001:,2001:

/ipv6 nd add advertise-dns=yes interface=bridge-ether1

Toto zajistí, že v advertise na tne bridge bude posílat RRDNS položka s IPčkama 2001:,2001:.

Pokud chceš vědět, zda zákošovi se kompl konfiguruje IPv6 a zároveň mu dodat IPv6 DNS (což je hodně podstatné, bez toho bude problém, pokud zákoš bude mít noťas s kterým poleze i jinam, kde by bylo IPv6), tak použit ten DHCP relay spolu s ISC DHCP pro posílání adres DNS serverů. Zabijš tím 2 mouchy jednou ranou:

a) lidi dostanou IPv6 adresy pro DNS,

b) v logu na serveur budeš mít záznam, že si šáhli pro DNS, z troho záznamu budeš vědět i jakou IPv6 autokonfigurvoanou adresu mají, dáš jim platnost 1 den a pěkně budou čmuchat opakovaně.

Jen v asdvertise s emusí nastavit, že si mají šahnout na bezestavové DHCPv6:

/ipv6 nd add advertise-dns=yes other-configuration=yes interface=bridge-ether1

Samotřejmě musí koncové zařízneí to bezestavové DHCPv6 podporovat. Ale Windows Visa až 8 to umí, takže od nich info mít budeš.

hapi

hmm, koukám že si člověk nevybere.

jak krássné by bylo kdyby to uměl dhcp server na mikrotiku. Takže předpokládám že dotlačení mikrotiků k tomu aby jejich bezestavové DHCPv6 posílalo DNS by problem řešilo, že?

tohle sem u sebe na mkčku nenašel (aha, je to pouze v MKv6)

/ipv6 dhcp-relay

add dhcp-server=fd49:2990:4616:1001::9 interface=bridge-ether1 name=DR1

majklik

Ano, na půl. Vyřeší to předání DNS serverů klientovému krámu. Ale bezestavové znamená, že si nic nepamatuje a neukládá - nebudeš mít záznam, že se něco děje, pokud si nezapneš debug log pro DHCP, pak to bude apoň v logu MKčka.

Po implementaci úplného stavového DHCPv6 serveru, pak by jsi měl leasy i tam. Ale opět, stavové DHCPv6 umí ještě míň věcí, než bezestavové (Windows Vista a výše to umí, nové linuxy obvykle také, Apple od 10.7 žere DHCPv6 i RRDNS v RA).

Aktuálně nejde korektně udělat stavové DHCPv6 jednoduše ani s použitím toho dhcpv6 relay v MKčku plus externího serveru, ale to snad opraví v dohledné verzi.

Nicméně prskání na MKčka v daném duchu (prvně bezestavovém), by byla velmi záslužná práce. Naposledy jsem jim to připomínal v sobotu, když jsem reklamoval chyby v tom relay.

Jo, relay je až v ROS6.

« Předchozí stránka Další stránka »