Hlavní navigace

Je libo IPv6 na přepínačích HP ProCurve ?

Tomáš Podermański 3. 12. 2010

Uvolněním nového firmware pro přepínače HP Procurve dosáhl jejich výrobce plnohodnotné podpory IPv6. Jak implementace funguje a lze ji nasadit v běžných sítích?

Dne 15. listopadu 2010 byla uvolněna nová verze firmware do přepínačů HP Procurve. Tímto krokem výrobce dohnal velký nedostatek, kterým přepínače řady ProCurve dosud trpěly, a to byla chybějící plnohodnotná podpora protokolu IPv6. Částečná podpora IPv6 už byla zavedena v předchozích verzích, nicméně pouze pro potřeby managementu zařízení a podpory filtrace (ACL). Verze K.15 přichází s plnohodnotnou podporou směrování IPv6 v hardware včetně podpory směrovacího protokolu OSPFv3. Firmware byl uvolněn pro L3 přepínače řady 54×x, 81×x, 62×x, 35×x – tj. všechny přepínače, které používají firmware nesoucí v označení znak “K”. Nová verze nese pořadové číslo 15 (K.15). Pojďme se podívat detailněji, jak je podpora IPv6 implementována. Na příkladech si ukážeme, že konfigurace IPv6 nepředstavuje nic složitého. Jelikož je praktické použití IPv6 pro mnohé stále relativně velkou neznámou, budou v následujícím textu některé odlišnosti proti IPv4 popsány detailněji. Ovládání a syntaxe příkazu IPv6 do značné míry kopíruje filozofii ovládání CISCO přepínačů, nicméně jsou zde některé drobné rozdíly. Uvedené postupy rozhodně nepředstavují ucelený obraz možností IPv6 ve firmware K.15 či konfiguračních možností IPv6, nýbrž jsou pouhým návodem, jak snadno a rychle uvést na uvedených řadách přepínačů IPv6 do provozu.

Nastavení adres na rozhraních

První věcí, kterou je potřeba udělat, je nastavení IPv6 adresy. V případě IPv4 bylo běžné, že na každém rozhraní byla nastavena zpravidla právě jedna adresa a jí odpovídající maska podsítě. V případě IPv6 je situace mírně odlišná. Každé rozhraní musí být povinně vybaveno tzv. Link-local adresou. Tato adresa má pouze lokální dosah a musí se na každé IPv6 rozhraní automaticky nastavit ihned po startu zařízení. Z pohledu správce je tento proces zcela automatizovaný. Co se týče konfigurace, mu tedy není nutno věnovat zvláštní pozornost. Druhým běžně používaným typem jsou tz. Globální IPv6 adresy. Tento typ adres víceméně odpovídá adresám, které známe z IPv4 světa. Změna délky adresy (na 128b.) zřejmě nikoho nepřekvapí, nicméně novinkou je nastavování délky masky téměř bezvýhradně na 64 bitů. V terminologii IPv4 jsme tímto výrazem označovali masku podsítě čí délku masky. V případě IPv6 hovoříme o prefixu, respektive o délce prefixu.

Jak již bylo uvedeno výše, Link-Local adresa je nastavena zcela automaticky. Konfigurace globální adresy se provádí v kontextu rozhraní (interface). Zde máme opět dvě možnosti. Buď lze nastavit celou adresu staticky, tj. síťovou i hostitelskou část (host ID), nebo můžeme nastavit pouze síťovou část a část hostitelskou necháme vytvořit algoritmem EUI64 na základě MAC adresy zařízení.

hp-test# configure
hp-test(config)# vlan 224
hp-test(vlan-224)# ipv6 address 2001:718:802:224::1/64
hp-test(vlan-224)# exit
hp-test(config)#vlan 225
hp-test(vlan-224)#ipv6 address 2001:718:802:225::0/64 eui-64

A můžeme ještě pro jistotu zkontrolovat konfiguraci

hp-test(vlan-225)# show ipv6
Internet (IPv6) Service

IPv6 Routing : Enabled
ND DAD       : Enabled
DAD Attempts : 3

Vlan Name    : DEFAULT_VLAN
IPv6 Status  : Disabled

Vlan Name    : VLAN224
IPv6 Status  : Enabled

Address    |                                               Address
Origin     | IPv6 Address/Prefix Length                    Status
-----------+-------------------------------------------- -----------
manual     | 2001:718:802:224::1/64                       tentative
autoconfig | fe80::21d:b3ff:fe01:a700/64                  tentative

Vlan Name   : VLAN225
IPv6 Status : Enabled

Address    |                                               Address
Origin     | IPv6 Address/Prefix Length                    Status
---------- + ------------------------------------------- -----------
manual     | 2001:718:802:225:21d:b3ff:fe01:a700/64        tentative
autoconfig | fe80::21d:b3ff:fe01:a700/64                   tentative

Jak lze vidět z výpisu, na dvou rozhraních (VLAN) jsou celkově nastaveny 3 různé IPv6 adresy. První z nich představuje námi nastavenou adresu v síti 2001:718:802:224. Použita je první dostupná adresa v příslušné síti (s číslem 1 v hostitelské části). Druhou adresu jsme nechali vytvořit algoritmem EUI64. Adresa sítě je v tomto případě 2001:718:802:225 a hostitelská část 21d:b3ff:fe01:a700. Třetí adresa, kterou lze ve výpisu vidět (fe80::21d:b3­ff:fe01:a700) je Link-Local adresa. Všimněte si, že Link-Local adresa má na všech rozhraních stejnou hodnotu. Z toho důvodu při práci s takovou adresou musíme vždy adresu doplňovat za symbolem % rozhraní, ke kterému příslušná Link-Local adresa náleží (např. fe80::21d:b3f­f:fe01:a700%VLAN224).

IPv6 management

Management aktivních prvků po IPv6 bude zřejmě ještě nějakou dobu spíše okrajovou záležitostí. Je to dáno zejména snahou primárně poskytnout nativní IPv6 (resp. dual stackovou) konektivitu pro servery a klientské stanice. Podpora v přepínačích pro management byla uvolněna už s nástupem firmware K.14, nicméně tato vlastnost zřejmě nikdy nebyla masově využívána.

Pokud se rozhodneme pro potřeby managementu zůstat pouze u protokolu IPv4, nesmíme zapomenout, že každá nakonfigurovaná IPv6 adresa se automaticky stává adresou, kterou je možné provádět správu aktivního prvku. Tuto nepříjemnost můžeme částečně omezit použitím volby mgmt-vlan. Tento postup si ovšem nemůžeme dovolit vždy. Při konfiguraci první IPv6 adresy na aktivním prvku bychom vždy měli nastavit omezení pro přístup k managementu prvku. Omezení pro vybrané sítě provedeme následujícím příkazem:

hp-test(config)# ipv6 authorized-managers 2001:718:802:228::0 ffff:ffff:ffff:ffff:: access manager

Obdobným způsobem je možné omezit management po IPv6 celkově:

hp-test(config)# ipv6 authorized-managers 0:: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

Všimněte si, že maska adresy sítě se vkládá v poněkud neobvyklém tvaru. Bohužel zatím neexistuje možnost, jak vložit masku sítě například prostřednictvím délky prefixu.

Pokud bychom přece jen zatoužili převést management prvků pouze pod IPv6, je možné se vydat i touto cestou. S většinou nastavení nebude závažnější problém – tj. přístup SNMP protokolem k MIBu přepínače, zasílání vzdáleného logování prostřednictvím syslogu, časové servery atd. Jediným zádrhelem je definice vlastních radius serverů, kde zatím není možné zadat IPv6 adresy. Pokud tedy využíváte autentizaci uživatelů prostřednictvím 802.1X a nebo přístupy k managementu aktivního prvku ověřujete vůči radiu serveru, budete muset nadále zachovat na prvku alespoň jednu IPv4 adresu pro potřeby managementu.

Konfigurace klientů

V předchozím kroku jsme provedli první nezbytný krok pro zprovoznění IPv6 v příslušné sítí. Nyní se podíváme, jak zajistit, aby se příslušná informace promítla do nastavení koncových stanic. Vynecháme statickou konfiguraci adres (která je samozřejmě také možná) a zaměříme se na prostředky, které nám tuto práci zjednoduší.

Protokol IPv6 zavádí nové prostředky pro konfigurací adres na koncových stanicích. Jedním z těchto prostředků je router advertisment (RA) protokol, který je jednou z části Neigbor Discovery (RFC 4861). Každý směrovač v pravidelných intervalech nebo na vyžádání (Router Solicitation) zašle informace o adresách sítí, které jsou konfigurovány na rozhraní směrovače. Tyto údaje použije koncová stanice nebo zařízení pro nastavení vlastní IPv6 adresy. Je to zcela jiný přístup než na který jsme byli zvyklí v prostředí IPv4, kde se ke konfiguraci koncových stanic používá výhradně DHCP protokol.

Pokud je přepínač konfigurován jako směrovač, je Router Advertisment generován automaticky a jsou do něj zahrnuty všechny sítě nakonfigurované na rozhraní. V některých případech však můžete žádoucí šíření RA potlačit. To je možné provést jednak globálně na úrovní celého přepínače

hp-test(config)# ipv6 nd suppress-ra

nebo v rámci konfigurace příslušného rozhraní

hp-test(vlan-224)# ipv6 nd ra suppress

V praxi tyto příkazy použijeme spíše ojediněle. Daleko důležitějším prvkem v nastavení RA jsou příznaky MANAGED a OTHER. Příznak managed informuje, že IPv6 adresa zařízení a další parametry mohou být v příslušné síti získány DHCPv6 protokolem. Příznak OTHER informuje klienta, že prostřednictvím DHCPv6 lze získat pouze další parametry jakými jsou adresy DNS serverů, DNS sufix atd. Nastavení příznaku MANAGED má automaticky věší prioritu. V případě, že je nastaven příznak MANAGED, nemá nastavení OTHER další význam. Ve výchozím stavu je nastavení obou příznaků vypnuto. Zapnout se dají prostřednictvím následujících příkazů.

hp-test(vlan-224)# ipv6 nd ra managed-config-flag
hp-test(vlan-224)# ipv6 nd ra other-config-flag

Použití těchto voleb, zejména nastavení příznaku MANAGED, bude zřejmě v praxi velice časté.

DHCPv6

Jak již bylo řečeno výše, podpora DHCP protokolu sítí není nezbytnou nutností pro automatickou konfiguraci zařízení v IPv6 světě, jak jsme tomu byli zvyklí v IPv4. O předání údajů nezbytných pro vytvoření základní síťové konektivity se postará dříve popsaný mechanizmus inzerce směrovačů (RA). V rámci RA ovšem není možné předat další nezbytné údaje, jakými jsou například adresy DNS serverů nebo sufixy prohledávaných domén. Tyto údaje můžeme získat prostřednictvím DHCP po IPv4 (v rámci podpory dualstacku) anebo prostřednictvím DHCPv6. Pokud v  příslušné síti není nakonfigurován DHCPv6 server a budete chtít využívat služeb vzdáleného DHCPv6 serveru, bude potřeba zprovoznění podpory předávání DHCPv6 požadavků (DHCPv6 relay). Nastavení adres DHCPv6 serverů se provede obdobně jak v IPv4. Konfigurace na straně směrovače bude stejná pro stavovou i bezstavovou konfiguraci

hp-test(vlan-224)# ipv6 helper-address unicast 2001:718:802:4::93e5:394
hp-test(vlan-224)# ipv6 helper-address unicast 2001:718:802:3::93e5:318

a zapnutí podpory DHCPv6 relaye na globální úrovni:

hp-test(config)# dhcpv6-relay

Cache sousedů

Pozorný čtenář si jistě všiml, že přidělování adres koncovým zařízením již není řízeno centrálně, jak jsme tomu byli zvyklí v případě IPv4, kde tuto službu zpravidla zajišťoval DHCP server. V případě IPv6 jsou adresy koncových zařízení mnohdy generovány náhodně (RFC 4941) bez vlivu jakékoliv vnější autority. V mnohých případech bude při praktickém provozu potřeba znát vztah mezi komunikující IPv6 adresou a adresou linkové vrstvy (MAC adresou). V IPv4 protokolu byly tyto informace uloženy v  ARP tabulce. U IPv6 odpovídající struktuře říkáme neigbor cache. Význam a použití jsou v principu obdobné jako u ARP tabulky. Její obsah můžeme vypsat následujícím příkazem:

hp-test# show ipv6 neighbors

IPv6 ND Cache Entries

IPv6 Address                            MAC Address   State  Type   Port
--------------------------------------- ------------- ----- ------- ----
...
2001:718:802:3:223:32ff:fe31:50d4       002332-3150d4 STALE dynamic 2
2001:718:802:3:81f3:b2e7:f738:3bd8      000423-c915c4 STALE dynamic 2
2001:718:802:3:915a:50d3:f16e:919a      000423-c915c4 STALE dynamic 2
fe80::214:22ff:fe7b:8673%vlan223        001422-7b8673 STALE dynamic 23
2001:718:802:80::1                      001ec1-daab81 STALE dynamic 4
fe80::21e:c1ff:feda:ab81%vlan224        001ec1-daab81 STALE dynamic 4
...

Jak vidíme, neighbor cache obsahuje záznamy pro všechny typy adres, tj. jak Link-local, tak globální adresy. Procházení záznamů v cache je zatím poněkud nekomfortní s možností filtrace pouze na VLAN. Pro pokročilejší filtraci nebo třídění tedy musíme použít nějaký externí nástroj. Záznamy neigbor cache jsou rovněž dostupné prostřednictvím MIB stromu – dle definice RFC 4293 v tabulce ipNetToPhysical­Table.

Unicast Routing

Pokud jsme překonali všechny strasti konfigurace koncové sítě, můžeme přistoupit ke konfiguraci směrování. Aktivace podpory směrování je věcí pouhého jednoho příkazu:

hp-test(config)# ipv6 unicast-routing

Z příkazu je na první pohled zřejmé, že jeho prostřednictvím se aktivuje pouze unicastové směrování. Příkaz pro aktivaci multicastového směrování byste zatím hledali marně. Musíme doufat, že podpora multicastového směrování na síťové vrstvě včetně podpory souvisejících protokolů (PIM-SM, PIM-DM) se objeví v některé z dalších verzí.

Obdobně jednoduchá je konfigurace statického směrování. Zápis záznamů do směrovací tabulky se v principu nijak neliší od způsobu zápisu běžného v IPv4 světě. Následující příkazy zřejmě nepotřebují další komentář.

hp-test(config)# ipv6 route 2001:718:802:228::/64 2001:718:802:224::10

Směrovací protokol – OSPFv3

Trošku odlišná situace je v případě konfigurace směrovacího protokolu. Na prvcích je podporován OSPF protokol, resp. jeho ekvivalent pro IPv6 svět – tj. OSPFv3 (RFC 2740, 5340). Princip fungování protokolu je v mnoha ohledech obdobný, jak jej známe z OSPF. Mezi klíčové změny patří zejména fakt, že komunikace mezi směrovači a výměna směrovacích informací probíhá výhradně na Link-Local adresách. V praxi to znamená, že není nezbytně nutné konfigurovat globální IPv6 adresy na spojovacích sítích mezi směrovači. Konfigurace OSPFv3 rozhraní se tedy prakticky omezuje na povolení IPv6 na příslušném rozhraní a přiřazení OSPFv3 oblasti (area). Absence globální IPv6 adresy na rozhraní sebou přináší jistý nedostatek. Případné servisní informace (ICMPv6) předávané ze směrovačů se nemají jak dostat k příjemci. Tento problém je možné řešit pomocí spojovacích sítí na jednotlivých směrovačích. V tomto případě není podstatné, zda je síť mezi směrovači totožná, nezbytná je pouze libovolná globální adresa dostupná ze zbytku sítě. Další možností, dle mého názoru velice elegantní, je konfigurace jedné globální IPv6 adresy na loopback rozhraní L3 switche.

Pro OSPFv3 je nutné ještě nastavit další parametry. Nikoho zřejmě nepřekvapí nastavení oblasti (area). Ta se nastavuje stejně jako v případě OSPF – prostřednictvím 32b. identifikátoru zapisovaného ve formátu čtyř jednobajtových čísel oddělených tečkami. Pro označení páteřní oblasti (backbone area) se stejně jako v OSPF používá hodnota 0.0.0.0. V pří­padě OSPFv3 budeme zcela jistě častěji nuceni ručně nastavit parametr router ID. Jedná se o unikátní identifikátor směrovače, jehož hodnota se za normálních okolností odvodí z nejvyšší nakonfigurované IPv4 adresy. V IPv4 jsme se jeho konfigurací nemuseli nějak zvlášť zabývat. Pokud ovšem hodláme na směrovači provozovat pouze podporu IPv6 protokolu, bude nutné tento parametr nastavit ručně. Nastavení se provádí jedním příkazem společně pro oba OSPFOSPFv3 směrovací procesy.

hp-test(config)# ip router-id 147.229.240.123

Hrátky s multicastem

Podporu multicastu je nutno rozdělit na dvě části. Podpora na linkové vrstvě (optimalizace šíření multicastu) a podpora na síťové vrstvě (směrování multicastu). V prvním případě jde o mechanizmy podporující efektivní šíření multicastových dat. Ve světě IPv4 byl tento mechanizmus znám pod termínem IGMP SNOOPING. Náhrada protokolu IGMP je řešena protokolem MLD (RFC2710 – Multicast Listener Discovery (MLD) for IPv6). Fungováni protokolu je v principu shodné s mechanizmy známými z IGMPv2 a IGMPv3 (RFC 2236, RFC 3376). Na úrovní přepínače je protokol MLD aktivován automaticky. Při konfiguraci typicky budeme muset aktivovat MLD na úrovni IPv6 rozhraní, tedy VLAN:

hp-test(vlan-224)# ipv6 mld

Následně si můžeme prohlédnout stav připojení do jednotlivých skupin příkazem:

hp-test(config)# show ipv6 mld vlan 224

MLD Service Protocol Info

VLAN ID : 310
VLAN NAME : list
Querier Address : ::
Querier Up Time : 0h:0m:0s
Querier Expiry Time : 0h:0m:0s
Ports with multicast routers :

Active Group Addresses           Type ExpiryTime Ports


---- --------- ------
ff02::c                          FILT 0h:4m:20s 1
ff02::1:3                        FILT 0h:4m:20s 1
ff02::1:ff57:e0b2                FILT 0h:4m:20s 1
ff02::1:ffb5:2df1                FILT 0h:4m:20s 1
ff02::1:ffda:768d                FILT 0h:4m:20s 1 

Nastaveni podpory MLD snoopingu lze doporučit jako automatickou volbu na všech VLAN.

Uvedeným nastavením zaručíme efektivní distribuci IPv6 multicastového provozu v rámci lokální sítě. Logicky by měl následovat krok, ve kterém aktivujeme podporu IPv6 multicastového směrování a odpovídajícího multicastového směrovacího protokolu. Bohužel v současné verzi bychom tuto podporu zatím hledali marně. Podpora multicastu na síťové vrstvě je plánována až pro některou z dalších verzí.

Filtrace – aneb paketový filtr

Pokud začneme provozovat IPv6 síť, jistě zatoužíme po jejím vhodném zabezpečení. Na přepínačích HP můžeme k tomuto účelu použít paketový filtr implementovaný v podobě access listů. Podpora pro vytváření IPv6 access listů již byla uvolněna ve verzích firmware K.14. S novou verzí přichází podpora filtrace na úrovní VLAN a směrování. Logika ovládaní je shodná s vyvářením access listů v prostředí IPv4.

Nejdříve si musíme vytvořit odpovídající access list, ve kterém popíšeme vlastní filtrační pravidla:

hp-test(config)# ipv6 access-list "acl_1"
hp-test(config-ipv6-acl)# permit tcp any host 2001:718:802:4::93e5:394 eq 25
hp-test(config-ipv6-acl)# permit tcp host 2001:718:802:4::93e5:394 eq 25 any
hp-test(config-ipv6-acl)# deny tcp any any eq 25
hp-test(config-ipv6-acl)# permit ipv6 any any

Uvedený příklad popisuje jednoduchý access list, který blokuje veškerý provoz SMTP s výjimkou adresy 2001:718:802:­4::93e5:394, kde je umístěn SMTP server. Následně je takto vytvořený access list nutno navázat buď na interface (port):

hp-test(config-ipv6-acl)# interface a1
hp-test(eth-A1)# ipv6 access-group acl_1 in

a nebo VLAN:

hp-test(vlan-223)# ipv6 access-group acl_1 in
hp-test(vlan-223)# ipv6 access-group acl_1 out

CIF16

Závěr

Podpora IPv6 v prvcích řady ProCurve byla uvolněna poněkud později než u jiných výrobců. Na plnohodnotnou podporu včetně multicastového provozu a nejrůznější ochranné mechanizmy bude nutno ještě nějaký čas počkat. I přes drobné nedostatky lze implementaci považovat za funkční a bez větších problému nasaditelnou do běžných sítí.

Podrobnější informace, ukázkové konfigurace a další dokumenty lze najít, a v budoucnu budou aktualizovány, na stránkách aktivity „Campus Best Practice“, která je provozována pod záštitou projektu GEANT3.

Našli jste v článku chybu?
Vitalia.cz: Antibakteriální mýdla nepomáhají, spíš škodí

Antibakteriální mýdla nepomáhají, spíš škodí

Vitalia.cz: Voda z Vltavy před a po úpravě na pitnou

Voda z Vltavy před a po úpravě na pitnou

Lupa.cz: Poučný příběh jednoho rozšíření pro Chrome

Poučný příběh jednoho rozšíření pro Chrome

DigiZone.cz: Parlamentní listy: kde končí PR...

Parlamentní listy: kde končí PR...

Měšec.cz: TEST: Vyzkoušeli jsme pražské taxikáře

TEST: Vyzkoušeli jsme pražské taxikáře

DigiZone.cz: Nova opět stahuje „milionáře“

Nova opět stahuje „milionáře“

Podnikatel.cz: Letáky? Lidi zuří, ale ony stále fungují

Letáky? Lidi zuří, ale ony stále fungují

DigiZone.cz: DVB-T2 ověřeno: seznam TV zveřejněn

DVB-T2 ověřeno: seznam TV zveřejněn

Vitalia.cz: 7 příčin neplodnosti u žen: pravda a mýty

7 příčin neplodnosti u žen: pravda a mýty

DigiZone.cz: LG OLED65E6: první pohled

LG OLED65E6: první pohled

Vitalia.cz: Muž, který miluje příliš. Ženám neimponuje

Muž, který miluje příliš. Ženám neimponuje

Lupa.cz: Patička e-mailu závazná jako vlastnoruční podpis?

Patička e-mailu závazná jako vlastnoruční podpis?

Vitalia.cz: Když bílkoviny, tak jíme ty nekvalitní

Když bílkoviny, tak jíme ty nekvalitní

DigiZone.cz: Nejnovější špičkové TV ve videu

Nejnovější špičkové TV ve videu

Vitalia.cz: dTest odhalil ten nejlepší kečup

dTest odhalil ten nejlepší kečup

Root.cz: Prvních 700 routerů Omnia je hotových

Prvních 700 routerů Omnia je hotových

Vitalia.cz: Test dětských svačinek: Tyhle ne!

Test dětských svačinek: Tyhle ne!

Podnikatel.cz: 5 věcí, které o EET ještě nevíte

5 věcí, které o EET ještě nevíte

Podnikatel.cz: ČSSZ posílá přehled o důchodovém kontě

ČSSZ posílá přehled o důchodovém kontě

120na80.cz: Co je padesátkrát sladší než cukr?

Co je padesátkrát sladší než cukr?