Majklik píš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ů.
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:
Kód: Vybrat vše
/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í:
Kód: Vybrat vše
/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á:
Kód: Vybrat vše
/routing ripng interface
add interface=wlan1
add interface=bridge-ether1 passive=yes
APčko pak:
Kód: Vybrat vše
/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.
