PT
NB_ITN - PT gyakorlati készségfelmérés
Routing and Switching Essentials (Version 5.0) - NB_ITN Practice Skills Assessment - PT
Forgalomirányítási és kapcsolási alapok - PT gyakorlati készségfelmérés
=====================
https://www.youtube.com/watch?v=Dz9ex249TG0#t=15.218299
---------------------------------------------------
https://www.youtube.com/watch?v=0rOyYNs0Cdo#t=26.252653
---------------------------------------------------------------------
https://www.youtube.com/watch?v=NrYPSycyw3o
=======================
http://www.ccna5.net/ccna1-v5-0-introduction-to-networks-practice-final-cli-command-answers/1257
ipv6 unicast-routing
interface g0/0
ipv6 address 2001:db8:acad:A::1/64
ipv6 address FE80::1 link-local
no shutdown
exit
interface g0/1
ipv6 address 2001:db8:acad:B::1/64
ipv6 address FE80::1 link-local
no shutdown
exit
...
Conf lab 214 switch
_________________________________________________
conf t
ip default-gateway 192.168.1.158
int vlan 1
ip address 192.168.1.157 255.255.255.240
no shutdown
line vty 0 4
password class
login
end
copy running-config startup-config
...
Middle(config)#ip domain-name ccna5.net===========================
7. fejezet
R1:
- Frissítést küld a 10.1.0.0 hálózatról a Serial 0/0/0 interfészen.
- Frissítést küld a 10.2.0.0 és 10.3.0.0 hálózatokról a FastEthernet 0/0 interfészen.
- Frissítést kap R2-től a 10.4.0.0 hálózatról és egyel növeli az ugrásszámot.
- Eltárolja a 10.4.0.0 hálózatot az irányítótáblában 2-es mértékkel.
- Ugyanaz a frissítés R2-től a 10.3.0.0 hálózatról 1-es
mértékkel tartalmaz információkat. Nincs változás, így az irányítási
információk ugyanazok maradnak.
R2:
- Frissítést küld a 10.3.0.0 és a 10.4.0.0 hálózatokról a Serial 0/0/0 interfészen.
- Frissítést küld a 10.1.0.0 és a 10.2.0.0. hálózatokról a Serial 0/0/1 interfészen.
- Frissítést kap R1-től a 10.1.0.0 hálózatról. Nincs változás, így az irányítási információk ugyanazok maradnak.
- Frissítést kap R3-tól a 10.4.0.0 hálózatról. Nincs változás, így az irányítási információk ugyanazok maradnak.
A távolságvektor alapú forgalomirányító protokollok általában egy
látóhatár-megosztás nevű technikát alkalmaznak az irányítási hurkok
elkerülése érdekében. A látóhatár-megosztás megakadályozza, hogy
ugyanazon az interfészen lehessen információkat kiküldeni, mint amelyen
azok beérkeztek.
A különböző forgalomirányító protokollok eltérő módszerek alapján határozzák meg a legjobb útvonalat.
-------------------------------------------
A RIP engedélyezéséhez a router rip parancsot
kell használni a 3. ábrán látható módon. Ez a parancs még nem indítja
el közvetlenül a RIP-folyamatot, csak hozzáférést biztosít a
forgalomirányító-konfigurációs módhoz, ahol elvégezhetők a RIP
beállításai.
7.3.1.2 Hálózatok hirdetése
Használjuk a network hálózati-cím forgalomirányító-konfigurációs
módbeli parancsot. Adjuk meg az osztály alapú hálózatot minden
közvetlenül csatlakozó hálózathoz. Ez a parancs:
- Engedélyezi a RIP-et minden olyan interfészen, amelyik
egy adott hálózathoz tartozik. A hozzárendelt interfészek ezután már
küldik és fogadják a RIP-frissítéseket.
- A megadott hálózatot a többi forgalomirányítónak 30 másodpercenként küldött RIP útvonalfrissítésekben hirdeti.
MEGJEGYZÉS: Alhálózati cím megadása esetén az IOS
automatikusan átalakítja azt a megfelelő
osztály alapú hálózati címmé.
Ne feledjük, hogy a RIPv1 osztály alapú irányító protokoll IPv4 alatt.
Például a
network 192.168.1.32 parancs automatikusan a
network 192.168.1.0 paranccsá alakul át az aktív konfigurációs fájlban.
A show ip protocols parancs a
forgalomirányító aktuális beállításait mutatja - RIP-információt
A show ip route parancs az irányítótáblába felvett RIP-útvonalakat jeleníti meg.
Használjuk a
version 2 forgalomirányító-konfigurációs módbeli parancsot a RIPv2 engedélyezéséhez a 2. ábrán látható módon. Figyeljük meg, hogy a
show ip protocols parancs
kimenete azt mutatja, hogy R2 most már kizárólag 2-es verziójú üzenetek
küldését és fogadását végzi. A RIP folyamat most már tartalmazza az
alhálózati maszkot a frissítésekben, osztály nélküli protokollá téve
ezzel a RIPv2-t.
Enable RIP version 2 on R2 and return to privileged EXEC mode.
R2(config)# router rip
R2(config-router)# version 2
Verify the RIP protocol settings on R2.
R2# show ip protocols
Default version control: send version 2, receive version 2
.................
Az
automatikus útvonal összegzés letiltásakor a RIPv2 nem vonja össze a
hálózatokat az osztály alapú határokon. Az útvonalfrissítések így az
összes alhálózatot és a megfelelő maszkokat tartalmazzák. A
show ip protocols kimenetében most ez látható
automatic network summarization
is not in effect.
MEGJEGYZÉS: Az automatikus útvonal összegzés letiltása előtt
engedélyezni kell a RIPv2-t.
Disable automatic summarization on R2 and return to privileged EXEC mode.
R2(config)#
router rip
R2(config-router)#
no auto-summary
R2(config-router)#
end
Verify the RIP protocol settings on R2.
R2#
show ip protocols
Routing Protocol is "rip"
Automatic network summarization is not in effect
Routing for Networks:
192.168.2.0
192.168.3.0
192.168.4.0
Routing Information Sources:
Gateway Distance Last Update
192.168.2.1 120 00:00:09
192.168.4.1 120 00:00:01
...
Packet Tracer 7.1.3.6
A feladat az irányítótáblában található fontos információk
azonosításában és a hálózati konvergencia nyomon követésében nyújt
segítséget.
7.1.3.6 PDF Completed
7.1.3.6 PKT Completed
PDF PKA
Lássuk R1 közvetlen connected hálózatait
#
show ip route connected
R1-en mely routing protocol van használatban? RIP
Nézzük az R1 RIP-pel tanult network-eit:
R1#
show ip route rip
Nézzük mely hálózatokat tartalmaz R1 routing táblája:
R1#
show ip route
Listázzuk R1 interface státuszát.(Hány interfésznek van hozzárendelt címe):
R1#
show ip interface brief
R1#
router rip
R1#
network 64.0.0.0
Engedélyezzük debug-olást R2-n:
R2#
debug ip rip
R2#
debug ip routing
------------------------------------------
Az internet is az
autonóm rendszereken alapul, emiatt két típusú forgalomirányító protokollra van szükség:
-
Belső irányító protokollok (IGP) - Egy autonóm
rendszeren belüli forgalom irányítására használják. AS-en belüli
forgalomirányítás (intra-AS routing) néven is hivatkoznak rá.
Vállalatok, szervezetek sőt még szolgáltatók is használnak IGP-t a belső
hálózataikban. Az IGP protokollok közé tartozik a RIP, az EIGRP, az
OSPF és az IS-IS.
-
Külső irányító protokollok (EGP) - Autonóm
rendszerek közötti forgalom irányítására használják. AS-ek közötti
forgalomirányítás (inter-AS routing) néven is hivatkoznak rá. EGP
használatával szolgáltatók és nagyvállalatok összekapcsolása lehetséges.
Jelenleg az egyetlen életképes EGP a határátjáró-protokoll (Border
Gateway Protocol, BGP), amely az internet hivatalos irányító
protokollja.
MEGJEGYZÉS: Mivel a BGP az egyetlen elérhető külső
protokoll (EGP), ezért az EGP kifejezést ritkán használják, helyette
egyszerűen csak BGP-t mondanak.
A távolságvektor alapú azt jelenti, hogy az útvonalak hirdetése az alábbi két jellemzővel történik:
-
Távolság - Azonosítja, hogy a célhálózat milyen
messze található. A távolság mértéke lehet az ugrások száma, a költség, a
sávszélesség, a késleltetés és így tovább.
-
Vektor (irány) - A cél eléréséhez szükséges következő ugrás forgalomirányítót vagy a kimenő interfészt határozza meg.
Egy távolságvektor alapú irányító protokollt használó
forgalomirányítónak nincsenek ismeretei a célhálózat felé vezető teljes
útvonalról. A távolságvektor alapú protokollok útjelzőnek használják a
forgalomirányítókat a cél felé vezető útvonalon. Egy távoli hálózatról a
forgalomirányító csak annyi információval rendelkezik, hogy mekkora a
hálózat eléréséhez szükséges távolság vagy mérték és, hogy melyik
útvonalat vagy interfészt használja az odajutáshoz. A távolságvektor
alapú protokollok nem rendelkeznek egy tényleges térképpel a hálózat
topológiájáról.
Négy távolságvektor alapú IPv4 belső protokoll (IGP) létezik:
-
RIPv1 - Hagyományos első generációs protokoll.
-
RIPv2 - Egyszerű távolságvektor alapú forgalomirányító protokoll.
-
IGRP - A Cisco első generációs, saját fejlesztésű protokollja (elavult és helyét az EIGRP váltotta fel).
-
EIGRP - Továbbfejlesztett távolságvektor alapú protokoll.
A távolságvektor alapú irányító protokollok központi eleme a
forgalomirányító algoritmus. Az algoritmust arra használják, hogy
meghatározzák vele a legjobb útvonalakat, majd ezt az információt
továbbküldjék a szomszédoknak.
Az irányító protokollokhoz használt algoritmus az alábbi folyamatokat határozza meg:
- Az irányítási információk küldéséhez és fogadásához használt eljárás.
- A legjobb útvonalak meghatározásához és az útvonalak irányítótáblába történő felvételéhez használt eljárás.
- A topológiában történő változások észlelését és a változtatást végrehajtó műveletek.
Az ábrán lévő animációban az R1 és R2 forgalomirányítókon
RIP irányító protokoll van beállítva. Az algoritmus küldi és fogadja a
frissítéseket. R1 és R2 is új információkhoz jutnak a frissítésekből.
Ebben az esetben mindkét forgalomirányító egy-egy új hálózatról szerzett
tudomást. A két forgalomirányítón futó algoritmus egymástól függetlenül
végzi a számításait és frissíti az irányítótábláját az új információk
alapján. Ha az R2 helyi hálózata meghibásodik akkor az algoritmus egy
eseményvezérelt (triggerelt) frissítést állít össze és elküldi azt
R1-nek. R1 ezután eltávolítja a hálózatot az irányítótáblájából.
Az egyes irányító protokollok eltérő algoritmusokat
használnak az útvonalak bejegyzéséhez az irányítótáblába, a frissítések
szomszédoknak küldéséhez és az útvonalak meghatározásához. Például:
- A RIP a Bellman-Ford algoritmust használja
forgalomirányító algoritmusként. Ez két olyan algoritmusra épül,
amelyeket Richard Bellmann és Lester Ford, Jr. fejlesztettek ki 1956-ban
és 1958-ban.
- Az IGRP és az EIGRP az ún. szétszóró frissítő
algoritmust (Diffusing Update Algorithm, DUAL) használja, amelyet Dr.
J.J. Garcia-Luna-Aceves fejlesztett ki az SRI International kutató
intézetnél.
A forgalomirányítási információs protokoll (
Routing
Information Protocol, RIP) egy első generációs protokoll, amelyet
eredetileg IPv4-re terveztek az RFC 1058 dokumentumban. Könnyen
konfigurálható, így kisebb méretű hálózatok esetében lehet jó választás.
A RIPv1 legfontosabb jellemzői a következők:
- Az útvonalfrissítéseket szórással (255.255.255.255 címre) küldi minden 30. másodpercben.
- Az útválasztás mértékeként az ugrásszámot veszi figyelembe.
- A 15-nél nagyobb ugrásszámot végtelennek (túl messze
lévőnek) tekinti. Ezt a 15. ugrást a forgalomirányító már nem hirdeti
tovább a frissítéseiben a következő szomszédos forgalomirányítónak.
A RIPv1 1993-ban RIP 2-es változat (RIPv2) néven ismert
osztály nélküli protokollá fejlődött. A RIPv2 a következő fejlesztéseket
tartalmazza:
-
Osztály nélküli irányító protokoll - Támogatja a VLSM-et és a CIDR-t, mivel az útvonalfrissítések tartalmazzák az alhálózati maszkot is.
-
Megnövekedett hatékonyság - Nem a szórásos 255.255.255.255 címre küldi a frissítéseket, hanem a 224.0.0.9 csoportos címre.
-
Csökkentett útvonal bejegyzések - Bármely interfészen támogatja a manuális útvonal összevonást.
-
Biztonság - A szomszédok közötti irányítótábla frissítések biztonsága érdekében hitelesítési eljárást is támogat.
Az ábrán lévő táblázat a RIPv1 és RIPv2 közötti különbségeket foglalja össze.
A RIP-frissítések UDP-szegmensbe vannak beágyazva, amelynek forrás- és célportja egyaránt az UDP 520-as portra van beállítva.
A RIP IPv6-ot támogató változatát 1997-ben adták ki. A
RIPng a RIPv2 alapjaira épül. Az ugrásszám itt is 15-re van korlátozva,
az adminisztratív távolság értéke pedig 120.
A belső átjáró irányító protokoll (
Interior Gateway Routing Protocol,
IGRP) volt 1984-ben a Cisco első, IPv4 alapú irányító protokollja. A
következő jellemzőkkel rendelkezett:
- A sávszélesség, a terhelés, a késleltetés és a megbízhatóság alapján határozza meg az összetett mértéket.
- Alapértelmezés szerint az útvonalfrissítéseket 90 másodpercenként küldi szórásos üzenetként.
1992-ben az IGRP-t a továbbfejlesztett IGRP (Enhanced IGRP,
EIGRP) váltotta fel. Ahogy a RIPv2, az EIGRP is támogatja a VLSM-et és a
CIDR-t. Ezen felül a megnövelt hatékonyság, a csökkentett
útvonalfrissítések és a biztonságos üzenetváltás jellemzi.
Az ábrán lévő táblázat az IGRP és EIGRP közötti különbségeket foglalja össze.
Az EIGRP-ben vezették be a következőket:
-
Korlátozottan eseményvezérelt frissítések - Nem
küld rendszeres időközönként frissítéseket. Topológiaváltozásokat
követően csak az irányítótábla megváltozott részeit hirdetik tovább. Ez
csökkenti az irányító protokoll által a hálózatra gyakorolt terhelést. A
korlátozott eseményvezérelt frissítések azt jelentik, hogy az EIGRP
csak annak a szomszédjának küld frissítést, amelyiknek szüksége van rá.
Így kevesebb sávszélességet használ, különösen akkor, ha nagyméretű és
sok útvonallal rendelkező hálózatokról van szó.
-
Ébrenléti hello üzenet - A szomszédos
forgalomirányítók a szomszédsági viszony fenntartása érdekében
rendszeres időközönként kisméretű hello üzeneteket küldenek egymásnak.
A normál működés során ez a hálózati erőforrások csak egy nagyon
kismértékű kihasználását eredményezi a rendszeres frissítésekkel
ellentétben.
-
Topológiatábla fenntartása - A topológiatábla a
szomszédoktól érkezett összes útvonalat (nem csak a legjobbakat)
tartalmazza. A DUAL algoritmus tartalék útvonalakat szúrhat be az EIGRP
topológiatáblába.
-
Gyors konvergencia - Általában ez a leggyorsabb
konvergenciájú belső protokoll, mivel a tartalék útvonalak
nyilvántartása révén szinte azonnali konvergenciát képes biztosítani. Ha
egy elsődleges útvonal kiesik, a forgalomirányító a tartalékként
azonosított útvonalat tudja használni. A tartalék útvonalra történő
átállás azonnali, és nem jár további forgalomirányítók bevonásával.
-
Több hálózati rétegbeli protokoll támogatása - Az
EIGRP protokollfüggő modulokat (Protocol Dependent Modules, PDM)
használ. Ez azt jelenti, hogy az EIGRP az egyetlen olyan protokoll,
amely az IPv4 és IPv6 protokollon kívül például az IPX és AppleTalk
támogatását is tartalmazza.
Packet Tracer 7.2.2.4
Completed Packet Tracer 7.2.2.4
Completed PDF Document 7.2.2.4
PDF PKA
PCA és
PCB kommunikálni szeretne egymással. Ezen végberendezések közötti útvonalon az adatok az
R1,
R2és
R3, vagy az
R4 és
R5 forgalomirányítókon keresztül utazhatnak..
Az, hogy a legjobb útvonalat melyik forgalomirányítók határozzák meg az
irányító protokolltól függ. Két távolságvektor alapú irányító protokoll
viselkedését fogjuk megvizsgálni. Az egyik a továbbfejlesztett belső
átjáró irányító protokoll (EIGRP), a másik a forgalomirányítási
információs protokoll 2-es változata (RIPv2).
#
show ip route
PC>
tracert 64.103.0.1
1 0 ms 0 ms 0 ms 64.100.0.254
2 0 ms 0 ms 0 ms 64.101.0.2
3 2 ms 1 ms 1 ms 64.101.0.6
4 2 ms 1 ms 1 ms 64.101.0.10
5 2 ms 2 ms 1 ms 64.101.0.14
RA(config)#
router rip
RA(config-router)#
distance 89
RA(config-router)#
do show ip route
tracert 64.103.0.1
Tracing route to 64.103.0.1 over a maximum of 30 hops:
Öszzehasonlítva az előző trace-route-tel, the #4 and #5 címek eltérnek.
------------------------------------------------------
Packet Tracer 7.3.1.8
PDF PKA
Annak ellenére, hogy a modern hálózatokban ritkán használnak RIP-et, a
hálózati forgalomirányítás alapjainak megértéséhez hasznos alapot nyújt.
Ebben a feladatban egy alapértelmezett útvonalat, egy megfelelő
hálózatokkal megadott RIPv2 protokollt, valamint passzív interfészeket
állítunk be, majd ellenőrizzük a kapcsolatokat.
Packet Tracer 7.3.2.3
Packet Tracer 7.3.2.3
PDF PKA
A RIPng (RIP Next Generation) egy távolságvektor alapú irányító
protokoll IPv6 környezetben. Mivel a RIPv2 alapjaira épül, így
adminisztratív távolságuk megegyezik és mindkét protokoll ugrásszám
korlátja 15. Ez a feladat segítséget nyújt a RIPng-protokoll jobb
megismeréséhez.
-----------------
Ahogy az IPv4-es RIP protokollt, úgy a RIPng-t is ritkán használják a
modern hálózatokban. A hálózati forgalomirányítás alapjainak
megértéséhez viszont ez a protokoll is hasznos alapot nyújt. Éppen
ezért ez a rész tartalmaz egy rövid áttekintést a RIPng alapvető
beállításairól.
Nézzük meg az ábrán látható minta topológiát. A példában
szereplő forgalomirányítók mindegyikén a működéshez szükséges alapvető
funkciók beállítása és a referencia topológián feltüntetett minden
interfész konfigurálása és engedélyezése el lett végezve. Statikus
útvonalak nincsenek beállítva, és irányító protokollok nincsenek
engedélyezve, emiatt a távoli hálózati hozzáférés jelenleg nem
lehetséges.
Egy IPv6-forgalomirányítón az
ipv6 unicast-routing paranccsal engedélyezhető az IPv6-csomagtovábbítás.
A RIPv2-vel ellentétben a RIPng-t nem forgalomirányító-konfigurációs módban engedélyezzük, hanem egy interfészen. Valójában a
network hálózati_cím parancs RIPng-ben nem is elérhető. Ehelyett az
ipv6 rip tartománynév enable interfész konfigurációs parancsot használjuk.
Az 1. ábrán az látható, hogy az IPv6-csomagtovábbítás be
van állítva, a Gigabit Ethernet 0/0 és a Serial 0/0/0 interfészeken
pedig engedélyezett a RIPng a RIP-AS tartománynév használatával.
A 2. ábrán található parancsszimulátorban az R2 és R3 forgalomirányítókon állítsunk össze hasonló konfigurációt!
RIPng esetében az alapértelmezett útvonal hirdetésének
folyamata megegyezik a RIPv2-vel azzal a különbséggel, hogy egy IPv6
alapértelmezett statikus útvonal beállítása szükséges. Tegyük fel
például, hogy R1 internetkapcsolata a Serial 0/0/1 interfészen található
a 2001:DB8:FEED:1::1/64 IP-cím felé. Az alapértelmezett útvonal
hirdetéséhez a következőket kell elvégezni az R3 forgalomirányítón:
- Egy alapértelmezett statikus útvonal létrehozása az ipv6 route 0::/0 2001:DB8:FEED:1::1 globális konfigurációs paranccsal.
- Az ipv6 rip tartománynév default-information originate interfész
konfigurációs parancs kiadása. Ez arra utasítja R3-at, hogy az
alapértelmezett útvonal információk forrása legyen, és RIPng
frissítésekben hirdesse az alapértelmezett statikus útvonalat a
konfigurált interfészeken.
----------------------------------
if konfigurálása egy RIP-AS NEVŰ RIPng processzel.
(config-if)#ipv6 rip RIP-AS enable
no sh
R1 Commands
R1>
en
R1#
conf t
R1(config)#
ipv6 unicast-routing
R1(config)#
ipv6 router rip cisco
R1(config-rtr)#
int g0/0
R1(config-if)#
ipv6 rip CISCO en
R1(config-if)#
int s0/0/0
R1(config-if)#
ipv6 rip CISCO en
R1(config-if)#
end
R1#
R2 Commands
R2#
en
R2#
conf t
R2(config)#
ipv6 unicast-routing
R2(config)#
ipv6 router rip CISCO
R2(config-rtr)#
int g0/0
R2(config-if)#
ipv6 rip CISCO en
R2(config-if)#
int s0/0/0
R2(config-if)#
ipv6 rip CISCO en
R2(config-if)#
int s0/0/1
R2(config-if)#
ipv6 rip CISCO en
R2(config-if)#
end
R2#
R3 Commands
R3>
en
R3#
conf t
R3(configure)#
ipv6 unicast-routing
R3(configure)#
ipv6 router rip CISCO
R3(config-rtr)#
int g0/0
R3(config-if)#
ipv6 rip CISCO en
R3(config-if)#
interface s0/0/1
R3(config-if)#
ipv6 rip CISCO en
R3(config-if)#
end
R3#
----------------------------------------
7.6.1.1 -
Packet Tracer 7.6.1.1
Completed PDF/DOC 7.6.1.1 - IPv6 Details
IPv6 - Részletek, részletek ...
A fejezetben bemutatott, IPv6-hoz kapcsolódó fogalmak megtanulása után képesnek kell lennünk az irányítótábla tanulmányozására és a benne szereplő IPv6 útvonal-információk értelmezésére.
Használjuk egy partnerrel együttműködve az IPv6-irányítótábla ábráját és a feladathoz mellékelt pdf fájlt.
Jegyezzük fel a gondolkodtató kérdésekre adott válaszainkat.
Ezt követően hasonlítsuk össze a válaszainkat az osztály legalább egy másik csoportjával.
R3#
show ipv6 route
...
R 2001:DB8:CAFE:1::/64 [120/3]
via FE80::FE99:47FF:FE71:78A0, Serial0/0/1
R 2001:DB8:CAFE:2::/64 [120/2]
via FE80::FE99:47FF:FE71:78A0, Serial0/0/1
C 2001:DB8:CAFE:3::/64 [0/0]
via GigabitEthernet0/0, directly connect
...
-----------------------
A távolságvektor alapú irányító protokollok működésével ellentétben,
egy
kapcsolatállapot alapú irányító protokollal konfigurált
forgalomirányító a többi forgalomirányítótól gyűjtött információk
alapján egy teljes képet tud összeállítani a hálózat topológiájáról.
Folytatva az útjelzők analógiát, a kapcsolatállapot alapú
irányító protokollok használata olyan, mintha egy teljes térképünk lenne
a hálózat topológiájáról. A forrástól a célig vezető úton felesleges
az útjelzők használata, mivel minden kapcsolatállapot alapú
forgalomirányító ugyanolyan hálózati térképet használ. Ezek a
forgalomirányítók a kapcsolatállapot-információkat használják fel a
topológia térkép létrehozásához, és a topológia célhálózataihoz vezető
legjobb útvonalak kiválasztásához.
A RIP-et futtató forgalomirányítók az irányítási
információikat tartalmazó, periodikus frissítéseket küldenek a
szomszédaiknak. A kapcsolatállapot alapú protokollok nem használnak
periodikus frissítéseket. A hálózat konvergálása után
kapcsolatállapot-frissítés már csak a topológia megváltozásakor kerül
kiküldésre.
A kapcsolatállapot alapú protokollok olyan helyzetekben működnek a legjobban, ahol:
- A hálózat hierarchikus kialakítású, ez általában nagyméretű hálózatoknál fordul elő.
- A hálózat gyors konvergenciája döntő fontosságú.
- A rendszergazdák jó ismeretekkel rendelkeznek a kialakított kapcsolatállapot alapú protokollról.
Két kapcsolatállapot alapú IPv4 belső (IGP) protokoll létezik:
-
OSPF - Népszerű szabványokon alapuló forgalomirányító protokoll.
-
IS-IS - Jellemzően a szolgáltatói hálózatokban használják.
A kapcsolatállapot alapú protokollok legrövidebb út protokollként is
ismertek, és Edsger Dijkstra legrövidebb út (shortest path first, SPF)
algoritmusára épülnek. Az SPF-algoritmust egy későbbi fejezetben
részletesebben is tárgyaljuk.
Az ábrán az IPv4-es kapcsolatállapot alapú protokollok láthatóak:
- Legrövidebb út protokoll (Open Shortest Path First, OSPF)
- Közbülső rendszerből közbülső rendszerbe protokoll (Intermediate System-to-Intermediate System, IS-IS)
A kapcsolatállapot alapú protokolloknak az a hírük, hogy
jóval bonyolultabbak, mint a távolságvektor alapú társaik. Viszont ha az
alapvető funkciókat és a konfigurálást tekintjük, a kapcsolatállapot
alapú protokollok ugyanolyan egyszerűek.
A RIP-hez és az EIGRP-hez hasonlóan az OSPF alapvető működését is a következő parancsokkal lehet beállítani:
-
router ospf
folyamat-azonosító
globális konfigurációs parancs
-
network
parancs a hálózatok hirdetésére
Minden kapcsolatállapot alapú protokoll a Dijkstra
algoritmust használja a legjobb útvonal kiszámításához. Az algoritmus
ismertebb neve a legrövidebb utat kereső (SPF) algoritmus. Az útvonal
teljes költségének meghatározásához az algoritmus a forrás és cél
közötti utak költségeit összesíti.
Az ábrán minden egyes úthoz egy tetszőleges költség érték
van hozzárendelve. R2-től az R3 helyi hálózatába tartó csomagok számára a
legrövidebb útvonal költsége 27. Minden forgalomirányító saját
költséget határoz meg a topológia összes célhálózata felé. Más szóval, a
forgalomirányítók mindegyike lefuttatja az SPF-algoritmust, majd a
saját szemszögéből meghatározza a költségeket.
MEGJEGYZÉS: A fejezet középpontjában a SPF-fa által
meghatározott költség áll. Az ábrák emiatt az SPF-fa kapcsolatait
mutatják és nem a topológiát. A kapcsolatokat folytonos fekete vonalak
jelölik.
Ahogy az ábrán is látható, a kapcsolatállapot alapú irányító
protokollok számos előnnyel rendelkeznek a távolságvektor alapú
protokollokhoz képest.
-
Topológia térkép felépítése - A kapcsolatállapot
alapú protokollok egy topológia térképet vagy SPF-fát hoznak létre a
hálózatról. Az SPF-algoritmus a kapcsolatállapot protokollok közt zajló
kapcsolatállapot-információ csere alapján tudja a hálózat SPF-fáját
felépíteni. A forgalomirányítók az SPF-fa segítségével egymástól
függetlenül határozzák meg minden hálózat felé a legrövidebb útvonalat.
-
Gyors konvergencia - Amikor egy kapcsolatállapot
alapú irányító protokoll egy LSP-t kap, akkor azonnal továbbküldi azt
minden interfészén, kivéve azon, amelyiken az LSP érkezett. A RIP ezzel
szemben minden egyes útvonalfrissítést feldolgoz, és csak az
irányítótábla frissítése után küldi tovább a többi interfészén.
-
Eseményvezérelt frissítések - Az LSP-k kezdeti
elárasztása után a kapcsolatállapot alapú protokollok csak
topológiaváltozás esetén küldenek ki újra LSP-t. Ez az LSP csak az
érintett kapcsolatra vonatkozó információkat tartalmazza. Néhány
távolságvektor alapú protokollal ellentétben a kapcsolatállapot alapú
protokollok nem küldenek rendszeres frissítéseket.
-
Hierarchikus tervezés - A kapcsolatállapot alapú
protokollok területi alapon működnek. Több terület használata
hierarchikus hálózattervezést tesz lehetővé, és így hatékonyabb
útvonal-összevonásra és az irányítási feladatok egyetlen területre
szűkítésére van lehetőség.
A kapcsolatállapot alapú protokollok néhány hátránnyal is rendelkeznek a távolságvektor alapú protokollokhoz képest:
-
Memóriakövetelmények - A kapcsolatállapot alapú
protokollok több memóriát igényelnek a kapcsolatállapot-adatbázis és az
SPF-fa létrehozásához és karbantartásához.
-
Feldolgozási követelmények - A kapcsolatállapot
alapú protokolloknak nagyobb processzor teljesítményre van szükségük,
mint a távolságvektor alapúaknak. Az SPF-algoritmus több CPU-időt
igényel, mint a távolságvektor alapú algoritmusok, például a
Bellman-Ford, mivel a kapcsolatállapot alapú protokollok a teljes
topológiáról készítenek térképet.
-
Sávszélességigény - A kapcsolatállapot-csomagok
elárasztása negatív hatással lehet a rendelkezésre álló hálózati
sávszélességre. Ez csak a forgalomirányítók első indításakor vagy
instabil hálózatokban fordulhat elő.
8. fejezet
Ugyanakkor az, hogy a RIP legjobb út meghatározásában egyedül az ugrásszámra támaszkodik, viszonylag korán problémássá vált.
A RIP-el szemben az OSPF lényeges előnye, hogy a nagyobb hálózatok esetében gyorsabb konvergenciát és méretezhetőséget biztosít.
Az OSPF egy osztály nélküli forgalomirányító protokoll, amely a skálázhatóság érdekében bevezeti a terület fogalmát.
Az OSPF jellemzői, az alábbiak:
- Osztály nélküli - Tervezéséből eredően osztály nélküli, azaz támogatja a VLSM-et és CIDR-t.
- Hatékony - A forgalomirányítás változásai váltják ki a forgalomirányítás frissítéseket (nincsenek periodikus frissítések). A legjobb útvonal kiválasztásához az SPF-algoritmust használja.
- Gyors konvergencia - A hálózat változásai gyorsan elterjednek.
- Skálázhatóság - Egyaránt jól működik kis - és nagy hálózatok esetében is. Hierarchikus rendszerek kialakításának érdekében a forgalomirányítók csoportokba szervezhetők.
- Biztonságos - Támogatja a Message Digest 5 (MD5) alapú azonosítást. Ha az engedélyezve van, akkor az OSPF forgalomirányítók a társaiktól csak olyan kódolt irányítási frissítéseket fogadnak el, ahol megegyezik az osztott kulcs.
Az adminisztratív távolság (Administrative Distance, AD) a forgalomirányítási adatok forrásának megbízhatóságát (vagy prioritását) jelöli. Az OSPF alapértelmezett adminisztratív távolsága 110.
Az OSPF három adatbázist hoz létre és tart karban (lásd 1. ábra):
- Szomszédsági adatbázis (Adjacency database) – ez alkotja a szomszédsági táblát (neighbor table).
- Kapcsolatállapot adatbázis (Link-state database, LSDB) - ez alkotja topológia táblát (topology table).
- Továbbítási adatbázis (Forwarding database) – ez pedig az irányítótábla (routing table).
Az OSPF öt csomagtípust használ a forgalomirányítási adatok megosztásánál. Ezen csomagok, ahogy azt a 2. ábra is mutatja, az alábbiak:
- Kapcsolatállapot kérés csomag
- Kapcsolatállapot frissítés csomag
- Kapcsolatállapot nyugtázás csomag
Ezen csomagok szolgálnak a szomszédos forgalomirányítók felderítésére, valamint az aktuális hálózati információk karbantartása okán a forgalomirányítási adatok cseréjére.
Az algoritmus
A CPU a szomszédsági és topológiai táblákat Dijkstra SPF-algoritmusával dolgozza fel. Az SPF-algoritmus meghatározza az egyes célok elérésének teljes költségét.
Az SPF-algoritmus felépít egy SPF-fát (Shortest Path First, "legrövidebb utat először"), amely a forgalomirányítótól - mint a fa gyökerétől - kiindulva minden más csomópontohz kiszámítja a hozzá vezető legrövidebb útvonalat. Ezek után az SPF-fa szolgál a legjobb útvonalak meghatározására. Az OSPF a legjobb utakat behelyezi a forgalomirányító adatbázisba, amelyet az irányítótábla felépítéséhez használ.
A forgalomirányítási információk karbantartására, a konvergencia elérése érdekében az OSPF forgalomirányítók az alábbi általános kapcsolatállapot alapú forgalomirányítási folyamatot hajtják végre:
1. Szomszédsági kapcsolatok létrehozása – az adatok megosztása előtt az OSPF forgalomirányítóknak fel kell deríteniük egymást a hálózaton. Ennek érdekében egy OSPF forgalomirányító valamennyi OSPF által használt interfészén Hello csomagokat küld ki annak kiderítésére, hogy vannak-e szomszédok ezeken a kapcsolatokon. Ha talál egy szomszédot, akkor azzal az OSPF forgalomirányító megpróbál ezzel a szomszéddal egy szomszédsági kapcsolatot kialakítani.
2. Kapcsolatállapot hirdetések (Link-State Advertisements, LSA) cseréje – A szomszédségi kapcsolatok létrehozását követően a forgalomirányítók kapcsolatállapot hirdetéseket (LSA) váltanak. Az LSA valamennyi közvetlenül kapcsolódó kapcsolat állapotát és költségét tartalmazza. A forgalomirányítók az LSA-kkal elárasztják a kapcsolódó szomszédjaikat. Ha egy kapcsolódó szomszéd LSA-üzenetet kap, akkor azonnal továbbítja azt a saját kapcsolódó szomszédjai felé, mígnem a terület összes forgalomirányítója az összes LSA-t meg nem kapja.
3. Topológia tábla építése – Az LSA-k begyűjtését követően, az OSPF forgalomirányítók az LSA-kból topológia táblát építenek. Ez az adatbázis lényegében a hálózat topológiájának minden részletét tartalmazza.
4. Az SPF-algoritmus végrehajtása – Ezt követően a forgalomirányítók végrehajtják az SPF-algoritmust. Az SPF-algoritmus eredményeként jön létre az SPF-fa.
Az SPF-fából a legjobb utak kerülnek be az irányítótáblába. A forgalomirányítási döntések pedig az irányítótábla bejegyzései alapján történnek.
Mindegyik csomagnak speciális szerepe van az OSPF forgalomirányítási folymatban:
- 1-es típus: Hello csomag (Hello packet) – Az OSPF forgalomirányítók közti szomszédsági kapcsolatok létrehozására és karbantartására szolgál.
- 2-es típus: Adatbázis leíró csomag (Database Description, DBD) – A küldő forgalomirányító LSDB-adatbázisának rövidített listáját tartalmazza és arra szolgál, hogy össze lehessen vetni a fogadó helyi LSDB-adatbázisával. Az LSDB-nek azonosnak kell lennie a terület valamennyi forgalomirányítóján, hogy azok helyes SPF-fát építhessenek.
- 3-as típus: Kapcsolatállapot kérés csomag (Link-State Request, LSR)– A fogadó forgalomirányítók egy LSR küldésével többletinformációt kérhetnek a kapott DBD bármelyik eleméről.
- 4-es típus: Kapcsolatállapot frissítés csomag (Link-State Update, LSU) – Az LSR-ek megválaszolására és új adatok hirdetésére szolgál. Az LSU-k hét különböző típusú LSA-t tartalmazhatnak.
- 5-ös típus: Kapcsolatállapot nyugta csomag (Link-State Acknowledgment, LSAck) – Ha egy forgalomirányító LSU-t kap, akkor annak nyugtázására egy LSAck-ot küld. Az LSAck adatmezője üres.
Amikor egy OSPF forgalomirányító először kapcsolódik a hálózathoz, akkor megkísérli hogy:
- szomszédsági viszonyokat alakítson ki a szomszédaival,
- forgalomirányítási adatokat cseréljen,
- kiszámítsa a legjobb utakat, illetve hogy
Amikor az OSPF-et engedélyezzük egy interfészen, a forgalomirányítónak meg kell határoznia, hogy van-e az adott kapcsolaton OSPF szomszédja. Ennek érdekében a forgalomirányító valamennyi OSPF interfészén Hello csomagokat küld szét, benne a saját forgalomirányító azonosítójával (router ID). Egy OSPF folyamatban az OSPF forgalomirányító azonosító szolgál az egyes forgalomirányítók OSPF területen belüli egyedi azonosítására. A forgalomirányító azonosító egy IP-cím, melyet az egyes OSPF forgalomirányítókhoz vannak hozzárendelve.
A többes hozzáférésű hálózatokon a szomszédsági viszonyok számának és az LSA elárasztás problémájának kezelésére megoldás a kijelölt forgalomirányító (DR). Többes hozzáférésű hálózat esetén az OSPF egy DR-t választ, hogy gyűjtési és elosztási pontként kezelje a küldött és fogadott LSA-kat. A DR meghibásodásának esetére egy BDR-t is választanak. Az összes többi forgalomirányító DROTHER-é válik.
Addig, amíg a Hello csomagok a szomszédsági viszonyok kialakítására szolgáltak, addig a másik négy OSPF csomagtípus az LSDB-k cseréjére és szinkronizációjára.
A topológiai adatbázisok szinkronizálását követően, csak bizonyos helyzetekben küldenek frissítéseket (LSU-k) a szomszédoknak:
- Változást érzékelnek (inkrementális frissítés).
A topológiában a visszacsatolási (loopback) interfész szimulálja az internet felé irányuló WAN kapcsolatot.
Az OSPFv2 a router ospf process-id globális konfigurációs paranccsal engedélyezhető. A process-id érték 1 és 65,535 közé eső szám lehet, amit a hálózati rendszergazda határoz meg. A process-id értéke csak lokálisan számít, azaz nem kell azonosnak lennie az egyes OSPF forgalomirányítókon, hogy szomszédsági kapcsolatba léphessenek.
Egy OSPF tartományban minden forgalomirányítónak egy forgalomirányító azonosítóval (Router ID) kell rendelkezni. A forgalomirányító azonosítót megadhatja a rendszergazda, vagy automatikusan meghatározhatja maga a forgalomirányító is. A forgalomirányító azonosítót az OSPF forgalomirányítók használják:
- Egyedi azonosításra – A forgalomirányító azonosítót a forgalomirányítók az OSPF tartományon belül az egyes forgalomirányítók és az általuk küldött csomagok forrásának egyedi azonosítására használják.
- A DR választási folyamat során –
(config)#router ospf 10
(config-router)#router-id 2.2.2.2
(config-router)#end
#sh ip protocols
OSPF forgalomirányítási folyamatot a clear ip ospf process privilegizált módbeli paranccsal törölhetjük.
Az azonosító megadható visszacsatolási interfésszel is.
A loopback interfész IPv4-címét 32 bites alhálózati maszkkal (255.255.255.255) kell konfigurálni. Ez egyben egy hoszt utat is definiál. A 32 bites maszkkal konfigurált útvonalakat az OSPF forgalomirányítók nem hirdetik.
int loopback 0
ip addr 1.1.1.1 255.255.255.255
end
A forgalomirányító bármelyik interfésze, amely szerepel a network parancs utáni címlistában, küld és fogad OSPF csomagokat. Ennek eredményeként az interfész hálózat, vagy alhálózat címe bekerül az OSPF forgalomirányítási frissítéseibe.
A parancs alap szintaxisa:
network hálózati_cím helyettesítő_maszk area terület_azonosító.
OSPFv2 a network intf-ip-address 0.0.0.0 area terület_azonosító forgalomirányító konfigurációs paranccsal is engedélyezhető.
hogyan lehet egy interfész IPv4-címét megadni a négy 0-s helyettesítő maszkkal. A network 172.16.3.1 0.0.0.0 area 0 parancs R1 forgalomirányítón történő kiadása engedélyezi a Serial0/0/0 interfésznek a forgalomirányítási folyamatban való részvételét.
passzív interfész
R1(config-router)#passive-int g0/0
Alternatívaként valamennyi interfészt egyszerre is passzívvá tehetjük a passive-interface default parancs kiadásával. Ezesetben azon interfészeket, amiknek nem kell passzívnak lenniük újra engedélyezhetjük a no passive-interface parancs kiadásával.
Ebben a gyakorlatban az IP-címzés már előre konfigurálva van. A feladat a három forgalomirányítóból álló topológia alap egyterületű OSPFv2 konfigurációja, majd az eszközök közötti kapcsolatok ellenőrzése.
PDF PKA
Router 1 Configuration Commands
R1>en
R1#config t
R1(config)#router ospf 10
R1(config-router)#router-id 1.1.1.1
R1(config-router)#network 172.16.1.0 0.0.0.255 area 0
R1(config-router)#network 192.168.10.4 0.0.0.3 area 0
R1(config-router)#network 172.16.3.0 0.0.0.3 area 0
R1(config-router)#passive-int g0/0
00:13:00:
%OSPF-5-ADJCHG: Process 10, Nbr 2.2.2.2 on Serial0/0/0 from LOADING to
FULL, Loading Done 00:15:07: %OSPF-5-ADJCHG: Process 10, Nbr 3.3.3.3 on
Serial0/0/1 from LOADING to FULL, Loading Done
Router 2 Configuration Commands
R2>en R2
R2#conf t
R2(config)#router ospf 10
R2(config-router)#router-id 2.2.2.2
R2(config-router)#network 172.16.2.0 0.0.0.255 area 0
R2(config-router)#network 172.16.3.0 0.0.0.3 area 0
00:13:00: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.1.1 on Serial0/0/0 from LOADING to FULL, Loading Done
R2(config-router)#network 192.168.10.8 0.0.0.3 area 0
R2(config-router)#passive-int g0/0
00:16:38: %OSPF-5-ADJCHG: Process 10, Nbr 3.3.3.3 on Serial0/0/1 from LOADING to FULL, Loading Done
Router 3 Configuration Commands
R3>en
R3#conf t
R3(config)#router ospf 10
R3(config-router)#router-id 3.3.3.3
R3(config-router)#network 192.168.10.4 0.0.0.3 area 0
R3(config-router)#network 192.168.1.0 0.0.0.255 area 0
00:15:07: %OSPF-5-ADJCHG: Process 10, Nbr 1.1.1.1 on Serial0/0/0 from LOADING to FULL, Loading Done
R3(config-router)#network 192.168.10.8 0.0.0.3 area 0
R3(config-router)# 00:16:38: %OSPF-5-ADJCHG: Process 10, Nbr 2.2.2.2 on Serial0/0/1 from LOADING to FULL, Loading Done
R3(config-router)#passive-int g0/0
----------------------------------------
Packet Tracer 8.2.4.5
https://seeseenayy.blogspot.hu/2016/03/ccnav2-completed-packet-tracer-8412.html
Ezen a laborgyakorlaton az alábbi feladatokat végezzük el:
- 1. rész: A hálózat felépítése és az eszközök alapvető konfigurálása.
- 2. rész: OSPF forgalomirányítás beállítása és ellenőrzése.
- 3. rész: Forgalomirányító azonosítók kiosztásának megváltoztatása.
- 4. rész: OSPF passzív interfészek konfigurálása.
- 5. rész: OSPF mértékek megváltoztatása.
--------------------------------------------
Ábra:
router ospf 10
R3(config-router)# passive-interface default
R3(config-router)# no passive-interface serial 0/0/0
R3(config-router)# no passive-interface serial 0/0/1
R3(config-router)# end
R3# show ip protocols
A tábla szerint beállítjuk a PC-k és a routerek címeit.
Először nyissuk R1 CLI configuració panelt:
Router>en
Router#conf t
Router(config)#hostname R1
R1(config)#int g0/0
R1(config-if)#ip add 192.168.1.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#int s0/0/0
R1(config-if)#ip add 192.168.12.1 255.255.255.252
R1(config-if)#no sh
R1(config-if)#int s0/0/1
R1(config-if)#ip add 192.168.13.1 255.255.255.252
R1(config-if)#no sh
Majd nyissuk R2 CLI configuració panelt:
Router>en
Router#conf t
Router(config)#hostname R2
R2(config)#int g0/0
R2(config-if)#ip add 192.168.2.1 255.255.255.0
R2(config-if)#no sh
R2(config-if)#int g0/1
R2(config-if)#ip add 100.100.100.10 255.255.255.0
R2(config-if)#no sh
R2(config-if)#int s0/0/0
R2(config-if)#ip add 192.168.12.2 255.255.255.252
R2(config-if)#no sh
R2(config-if)#int s0/0/1
R2(config-if)#ip add 192.168.23.2 255.255.255.252
R2(config-if)#no sh
Végül nyissuk R3 CLI configuració panelt:
Router>en
Router#conf t
Router(config)#hostname R3
R3(config)#int g0/0
R3(config-if)#ip add 192.168.3.1 255.255.255.0
R3(config-if)#no sh
R3(config-if)#int g0/1
R3(config-if)#ip add 200.200.200.20 255.255.255.0
R3(config-if)#no sh
R3(config-if)#int s0/0/0
R3(config-if)#ip add 192.168.13.2 255.255.255.252
R3(config-if)#no sh
R3(config-if)#int s0/0/1
R3(config-if)#ip add 192.168.23.2 255.255.255.252
R3(config-if)#no sh
-Process ID 10
-Router ID az egyes router-eknek: R1 = 1.1.1.1; R2 = 2.2.2.2; R3 = 3.3.3.3
-Network address for each interface
-LAN interface set to passive (do not use the default keyword)
Miután végeztünk mind3 router és a PC-k (táblázatbeli címeknek megfelelő) konfigurációjával correct addresses, pingelhetjük networkünket. Pl,
PC-C az R3-on pingelni tudja 192.168.13.2-t (R1 felőli soros port),
192.168.23.2-t ( R2 felőli soros port),valamint a Web Server-t, ua, ezen hálózatokon túl. Vagyis, konfigurálnunk kell az OSPF protokollt.
Miután az IP-címzést nefejeztük, configurálnunk kell az OSPF-et.
Zárjunk a többit és nyissuk R1 configuració panelt:
R1(config)#router ospf 10
R1(config-router)#router-id 1.1.1.1
R1(config-router)#network 192.168.13.0 0.0.0.3 area 0
R1(config-router)#network 192.168.1.0 0.0.0.255 area 0
R1(config-router)#network 192.168.12.0 0.0.0.3 area 0
R1(config-router)#passive-interface g0/0
Zárjunk a többit és nyissuk R2 configuració panelt:
R2(config)#router ospf 10
R2(config-router)#network 192.168.23.0 0.0.0.3 area 0
R2(config-router)#network 192.168.2.0 0.0.0.255 area 0
R2(config-router)#network 100.100.100.0 0.0.0.255 area 0
R2(config-router)#network 192.168.12.0 0.0.0.3 area 0
R2(config-router)#passive-interface g0/1
R2(config-router)#passive-interface g0/0
Zárjunk a többit és nyissuk R3 configuració panelt:
R3(config)#router ospf 10
R3(config-router)#router-id 3.3.3.3
R3(config-router)#network 192.168.3.0 0.0.0.255 area 0
R3(config-router)#network 200.200.200.0 0.0.0.255 area 0
R3(config-router)#network 192.168.23.0 0.0.0.3 area 0
R3(config-router)#network 192.168.13.0 0.0.0.3 area 0
R3(config-router)#passive-interface g0/1
R3(config-router)#passive-interface g0/0
Finally,
verify that your PCs are able to ping each other. (R1 to R3, etc).
Alternatively (and reccomended), use the router command to display
neighbors from OSPF, your table should look like this:
R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 0 FULL/ - 00:00:33 192.168.12.1 Serial0/0/0
3.3.3.3 0 FULL/ - 00:00:38 192.168.23.2 Serial0/0/1
R3#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 0 FULL/ - 00:00:36 192.168.13.1 Serial0/0/0
192.168.23.2 0 FULL/ - 00:00:37 192.168.23.2 Serial0/0/1
--------
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.23.2 0 FULL/ - 00:00:33 192.168.12.2 Serial0/0/0
3.3.3.3 0 FULL/ - 00:00:33 192.168.13.2 Serial0/0/1
-------------------------------
Packet Tracer 8.3.3.5
Ebben a gyakorlatban az IPv6 címzést már előzetesen beállították. A feladat a három forgalomirányítóból álló topológia egyterületű OSPFv3 konfigurációja, majd az eszközök közötti kapcsolatok ellenőrzése.
PDF PKA
R1 gyel kezdjük..
R1>en
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ipv6 router ospf 10
Kimenet:
% IPv6 routing not enabled
Engedélyeznünk kell az unicast routing-ot:
R1(config)#ipv6 unicast-routing
A PDF alapján, Process ID, Router ID, and enable
OSPFv3 for each interface. Így először engedélyezzük az OSPF-et IPv6-on az alábbi paranccsal:
R1(config)#ipv6 router ospf 10
Valami nem Ok!
%OSPFv3-4-NORTRID: OSPFv3 process 10 could not pick a router-id,please configure manually
Csak adjuk meg a router megfelelő adatait a PDF-nek megfelelően (Route, ID, stb.)
Megj: nem kell kilépni.
R1 Konfiguráció:
R1(config-rtr)#router-id 1.1.1.1 <-- Routing ID
R1(config-rtr)#int g0/0 <-- Manual Interface Conf
R1(config-if)#ipv6 ospf 10 area 0
R1(config-if)#int s0/0/0
R1(config-if)#ipv6 ospf 10 area 0
R1(config-if)#int s0/0/1
R1(config-if)#ipv6 ospf 10 area 0
És u.így a tübbi router-en.
R2's Configuration, related to R1.
R2>en
R2#conf t
R2(config)#ipv6 unicast-routing
R2(config)#ipv6 router ospf 10
%OSPFv3-4-NORTRID: OSPFv3 process 10 could not pick a router-id,please configure manually
R2(config-rtr)#router-id 2.2.2.2
R2(config-rtr)#int g0/0
R2(config-if)#ipv6 ospf 10 area 0
R2(config-if)#int s0/0/0
R2(config-if)#ipv6 ospf 10 area 0
R2(config-if)#int s0/0/1
R2(config-if)#ipv6 ospf 10 area 0
00:02:21: %OSPFv3-5-ADJCHG: Process 10, Nbr 1.1.1.1 on Serial0/0/0 from LOADING to FULL, Loading Done
Now, to configure R3's end...
R3>en
R3#conf t
R3(config)#ipv6 unicast-routing
R3(config)#ipv6 router ospf 10
%OSPFv3-4-NORTRID: OSPFv3 process 10 could not pick a router-id,please configure manually
R3(config-rtr)#router-id 3.3.3.3
R3(config-rtr)#int g0/0
R3(config-if)#ipv6 ospf 10 area 0
R3(config-if)#int s0/0/0
R3(config-if)#ipv6 ospf 10 area 0
R3(config-if)#int s0/0/1
R3(config-if)#ipv6 ospf 10 area 0
00:04:12: %OSPFv3-5-ADJCHG: Process 10, Nbr 2.2.2.2 on Serial0/0/1 from LOADING to FULL, Loading Done
00:04:14: %OSPFv3-5-ADJCHG: Process 10, Nbr 1.1.1.1 on Serial0/0/0 from LOADING to FULL, Loading Done
Ellenőrizzük a konfiguráció funkcionalitását:
Pl, R3:
R3#show ip protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "ND"
IPv6 Routing Protocol is "ospf 10"
Interfaces (Area 0)
GigabitEthernet0/0
Serial0/0/0
Serial0/0/1
Redistribution:
None
Megj: "IPv6 Routing Protocol "ospf 10"".
--------------------------------
Packet Tracer 8.4.1.2
Ebben a komplex képességmérő feladatban az OSPFv2 és OSPFv3 konfigurációt gyakoroljuk. Először az IP-címeket kell konfigurálni. Majd a hálózat IPv4 részén OSPFv2, míg az IPv6 részén OSPFv6 irányítást kell beállítani. Az egyik forgalomirányítón az IPv4 és IPv6 konfigurációt is ki kell alakítani. Végezetül ellenőrizzük a konfigurációt és az eszközök közötti kapcsolatokat.
PDF PKA
---------------------------------------
RA>en
RA#conf t
RA(config)#router ospf 1
OSPF process 1 cannot start. There must be at least one "up" IP interface
RA(config-router)#router-id 1.1.1.1
RA(config-router)#int g0/0
RA(config-if)#ip add 172.31.0.1 255.255.254.0
RA(config-if)#no sh
%LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to up
RA(config-if)#int s0/0/0
RA(config-if)#ip add 172.31.4.1 255.255.255.252
RA(config-if)#no sh
%LINK-5-CHANGED: Interface Serial0/1/0, changed state to down
Please note that I did not configure S0/1/0, it is supposed to be S0/0/0.
Then, just to wrap it up for now, do:
RA(config-if)#router ospf 1
RA(config-router)#passive-interface g0/0
Lets go open up our next router, RB. Remember,
this is the router that we have to configure for both IPv4 and IPv6, so
be careful. Not hard, but just be cautious, messing up here will fail
your packet tracer.
RB>en
RB#conf t
RB(config)#router ospf 1
OSPF process 1 cannot start. There must be at least one "up" IP interface
RB(config-router)#router-id 2.2.2.2
RB(config-router)#int g0/0
RB(config-if)#ip add 172.31.2.1 255.255.254.0
RB(config-if)#ipv6 address 2001:DB8:1::1/64
RB(config-if)#no sh
Configure the Serial cables for their respective addresses.
RB(config-if)#int s0/0/0
RB(config-if)#ip add 172.31.4.2 255.255.255.252
RB(config-if)#no sh
RB(config-if)#int s0/0/1
RB(config-if)#ipv6 add 2001:DB8:2::1/64
RB(config-if)#no sh
Now, lets add our network commands for OSPF routing.
RB(config-if)#router ospf 1
RB(config-router)#passive-interface g0/0
RB(config-router)#network 172.31.2.0 255.255.254.0 area 0
RB(config-router)#network 172.31.4.0 255.255.255.252 area 0
So,
close RB and go back to RA. While doing that, your link-lights for the
entire left side of RB should be green. Go into RA and congfigure your
OSPF:
RA(config-if)#router ospf 1
RA(config-router)#passive-interface g0/0
RA(config-router)#network 172.31.0.0 255.255.254.0 area 0
RA(config-router)#network 172.31.4.0 255.255.255.252 area 0
You should get one of these after that:
00:23:22: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0/0 from LOADING to FULL, Loading Done
So, close that and go back to RB, it's time to configure the Serial and other connections with IPv6.
RB(config-router)#int s0/0/1
RB(config-if)#ipv6 ospf 1 area 0
% IPv6 routing not enabled
Just like last packet tracer, we have to go configure to allow IPv6. Enter the unicast routing command again.
RB(config)#ipv6 unicast-routing
Resume your connetion to the serial interface...
RB(config)#int s0/0/1
RB(config-if)#ipv6 ospf 1 area 0
Then, configure OSPF to the IPv6 section of the router including the other interfaces to that router.
RB(config-if)#ex
RB(config)#ipv6 router ospf 1
RB(config-rtr)#router-id 2.2.2.2
RB(config-rtr)#int g0/0
RB(config-if)#ipv6 ospf 1 area 0
RB(config-if)#ipv6 address fe80::1 link-local
RB(config)#int s0/0/1
RB(config-if)#no sh
Now, our final router configuration, go to RC and configure like we have done before, though this router is exclusively IPv6.
RC>en
RC#conf t
RC(config)#int g0/0
RC(config-if)#ipv6 address fe80::3 link-local
RC(config-if)#ex
RC(config)#ipv6 unicast-routing
RC(config)#ipv6 router ospf 1
%OSPFv3-4-NORTRID: OSPFv3 process 1 could not pick a router-id,please configure manually
RC(config-rtr)#router-id 3.3.3.3
RC(config-rtr)#int g0/0
RC(config-if)#ipv6 ospf 1 area 0
RC(config-if)#int s0/0/0
RC(config-if)#ipv6 add 2001:DB8:2::2/64
RC(config-if)#ipv6 ospf 1 area 0
RC(config-if)#no sh
RC(config-if)#ipv6 ospf 1 area 0
RC(config-if)#int g0/0
RC(config-if)#ipv6 address 2001:DB8:3::1/64
RC(config-if)#no sh (thank you for the catch! see comments below)
RC(config-if)#ex
RC(config)#ipv6 router ospf 1
RC(config-rtr)#pas
RC(config-rtr)#passive-interface g0/0
So,
we've configured our routes fully. You must verify this, perhaps a show
command like ospf neighbor. Check your progress, all PC information
should not be correct, only everything with the routers.
Finally,
we need to do the PCs now. When you check your results, the packet
tracer displays the IP address needed for the PCs, the default gateway
and other PC information is as follows:
PC-A Configuration
No IPv6 Configuration Present
IPV4 IP Address: 172.31.1.254
IPV4 Link Local Address: 255.255.254.0
IPV4 Default Gateway: 172.31.0.1
PC-B Configuration
IPV4 IP Address: 172.31.3.254
IPV4 Subnet Mask: 255.255.254.0
IPV4 Default Gateway: 173.31.2.1
IPV6 IP Address: 2001:DB8:1::2/64
IPV6 Link Local Address: FE80::1
IPV6 Default Gateway: FE80::1
**Thank you to "Daniel" in the comments for correcting the PC address issues.
PC-C Configuration
No IPv4 Configuration Present
IPV6 IP Address: 2001:DB8:3::2/64
IPV6 Link Local Address: FE80::1
IPV6 Default Gateway: FE80::3
10 . fejezet
1. lépés: IPv4-címek kizárása
Bizonyos címek kizárásához használjuk az
ip dhcp excluded-address parancsot.
2. lépés: DHCPv4-készlet beállítása
A DHCPv4-szerverek beállítása magában foglalja a kiosztható címkészlet megadását. Ahogy a 3. ábrán is látható, az
ip dhcp pool készlet-neve
parancs egy készletet hoz létre a megadott névvel, majd DHCPv4
konfigurációs módba lépteti a forgalomirányítót, amelyet az alábbi
prompt is jelez:
Router(dhcp-config)#.
3. lépés: Konkrét feladatok beállítása
A 4. ábrán egy lista látható a DHCPv4-címkészlet
beállításához szükséges feladatokról. Ezek egy része opcionális, míg a
többi beállítás megadása kötelező.
A címkészletet, valamint az alapértelmezett átjáró szerepét betöltő forgalomirányítót be kell állítani. A
network utasítással adhatjuk meg a
bérelhető címek tartományát.
A
default-router paranccsal
adható meg az
alapértelmezett átjáró.
Egy átjáró megadása kötelező, de akár nyolc cím is megadható, ha több
is van belőlük.
A
többi DHCPv4-címkészletre vonatkozó parancs megadása nem
kötelező. A DHCPv4-kliens számára
elérhető DNS-szerver IPv4-címét
például a
dns-server paranccsal lehet beállítani. A
domain-name tartománynév használatával adható meg a
tartomány neve. A
DHCPv4-bérlet időtartama módosítható a
lease paranccsal. Az alapértelmezett bérleti idő egy nap. A
netbios-name-server parancs használatával megadható a
NetBIOS WINS szerver.
DHCPv4 példa
A
192.168.10.0/24 LAN számára
DHCPv4-szerverként szolgáló R1 forgalomirányítón megadott
DHCPv4-alapbeállítások
mintakonfigurációja.
Exclude the .1 through the .9 address, vmint a .254 address from the 192.168.11.0/24 address range.
R1(config)#
ip dhcp excluded-address 192.168.11.1 192.168.11.9
R1(config)#
ip dhcp excluded-address 192.168.11.254
Configure the DHCPv4 pool LAN-POOL-2 for 192.168.11.0/24 LAN.
R1(config)#
ip dhcp pool LAN-POOL-2
R1(dhcp-config)#
network 192.168.11.0 255.255.255.0
Configure the default gateway address.
R1(dhcp-config)#
default-router 192.168.11.1
Configure the DNS server address using the same address used for LAN-POOL-1.
R1(dhcp-config)#
dns-server 192.168.11.5
Configure the domain name using the same address used for LAN-POOL-1.
R1(dhcp-config)#
domain-name example.com
A DHCPv4 letiltása
Alapesetben engedélyezve van,
amennyiben a Cisco IOS képes ilyen szolgáltatást
nyújtani. A szolgáltatást a
no service dhcp globális konfigurációs paranccsal tilthatjuk le. A
service dhcp újra engedélyez.
A 2. ábrán látható
show running-config | section dhcp parancs kimenete megjeleníti az R1 forgalomirányítón kiadott DHCPv4-parancsokat.
show ip dhcp binding parancs megjeleníti a DHCPv4-szolgáltatás által kiosztott
összes IPv4-cím, valamint hozzárendelt
MAC-cím listáját. A
show ip dhcp server statistics
paranccsal ellenőrizhetők a forgalomirányító által fogadott és küldött
DHCPv4-üzenetek.
A statisztikák között megjelenik a
DHCPDISCOVER, DHCPREQUEST, DHCPOFFER, valamint a
DHCPACK tevékenység.
A
ipconfig /all parancs kiadásával megjelennek a TCP/IP
paraméterek. Megjeleníei a
DNS-utótagot, az
IPv4-címet,
az
alhálózati maszkot, az
alapértelmezett átjárót, valamint a
DNS-szerver címét is.
Mi a DHCP-közvetítő?
Az összetett, hierarchikus hálózatokban a vállalati
szerverek általában egy szerverfarmon találhatók. Ezek a szerverek DHCP,
DNS, TFTP és FTP szolgáltatásokat nyújthatnak a hálózat számára. A
hálózati kliensek jellemzően nincsenek egy alhálózaton ezekkel a
szerverekkel.
Példánkban a PC1 szórásos üzenet segítségével próbál
IPv4-címet szerezni egy DHCP-szervertől. Ebben a példában az R1
forgalomirányító nincs beállítva, hogy DHCPv4-szerverként működjön, így a
szórást sem továbbítja. Mivel a DHCPv4-szerver egy másik hálózaton van,
ezért a PC1 nem kaphat IP-címet a DHCP segítségével.
Ha a PC1 megpróbálja megújítani az IPv4-címét, azt az
ipconfig /release parancs kiadása teszi lehetővé. Vegyük észre, hogy az IPv4-cím felszabadítása után a 0.0.0.0 cím jelenik meg. Ezután az
ipconfig /renew parancs
kiadása következik. Ennek következtében a PC1 egy szórásos DHCPDISCOVER
üzenetet küld szét. A parancs kimenetéből látszik, hogy a PC1 nem képes
megtalálni a DHCPv4-szervert. Mivel a forgalomirányítók nem továbbítják
a szórásos üzeneteket, ezért a kérés sikertelen.
Megoldás lehet egy Cisco IOS segédcím (helper
address) beállítása. Ez lehetővé teszi, hogy egy forgalomirányító
DHCPv4-szórásokat továbbítson a DHCPv4-szerver felé. Amikor a
forgalomirányító továbbküldi a címkéréseket, DHCPv4-közvetítőként
működik. A példában szereplő topológiában a PC1 egy szórásos kéréssel
próbál egy DHCPv4-szervert találni. Ha az R1 forgalomirányító
DHCPv4-közvetítőként lenne beállítva, a
kérést a 192.168.11.0 alhálózaton található DHCPv4-szerver felé
továbbítaná.
Amikor az R1 forgalomirányító DHCPv4-közvetítőként van beállítva,
elfogadja a DHCPv4-szolgáltatásra vonatkozó szórásos kéréseket, majd
egyedi címzéssel továbbküldi azokat a 192.168.11.6 IPv4-címre. A
show ip interface paranccsal ellenőrizhető a konfiguráció.
A PC1 így már kaphat IPv4-címet a DHCPv4-szervertől.
Nem csupán a DHCPv4-szolgáltatás esetében állítható be, hogy a forgalomirányító közvetítsen. Alapesetben az
ip helper-address parancs hatására a készülékek a következő nyolc UDP alapú szolgáltatás forgalmát közvetítik:
- 37-es port: idő
- 49-es port: TACACS
- 53-as port: DNS
- 67-es port: DHCP/BOOTP kliens
- 68-as port: DHCP/BOOTP szerver
- 69-es port: TFTP
- 137-es port: NetBIOS névszolgáltatás
- 138-as port: NetBIOS datagram szolgáltatás
A PC3
kaphat IPv4-címet a
192.168.11.6 című DHCPv4-szervertől.
Configure the DHCPv4 relay commands on the correct router for PC3 to receive an IPv4 address and other parameters from the DHCPv4 server.
R3(config)#
interface g0/0
R3(config-if)#
ip helper-address 192.168.11.6
Egy Ethernet-interfész DHCP-kliensként történő
beállításához használjuk az
ip address dhcp interfész konfigurációs parancsot.
Az 1. ábrán feltételezzük, hogy az internetszolgáltatót úgy
konfigurálták, hogy a kiválasztott ügyfelek számára a 209.165.201.0/27
hálózati tartományból biztosítson IP-címeket. Miután a G0/1 interfészt
konfiguráltuk az
ip address dhcp paranccsal, a
show ip interface g0/1 paranccsal ellenőrizhetjük, hogy az interfész felkapcsolt állapotban van, címet pedig egy DHCPv4-szervertől kapott.
A 2. ábrán található parancsszimulátorral beállítható, hogy
az internetszolgáltatóhoz kapcsolódó interfész a DHCP-szervertől kapjon
címet.
Configure the interface connected to the ISP to acquire an address from the DHCP server.
SOHO(config)# interface g0/1
SOHO(config-if)# ip address dhcp
SOHO(config-if)# no shutdown
Exit entirely out of configuration mode and verify the IP information on interface g0/1.
SOHO(config-if)# end
SOHO# show ip interface g0/1
GigabitEthernet0/1 is up, line protocol is up
Internet address is 209.165.201.12/27
Broadcast address is 255.255.255.255
Address determined by DHCP
<output omitted>
10.1.3.3 Packet Tracer - DHCP-szolgáltatás Cisco IOS konfigurációja
Egy dedikált DHCP-szerver jól méretezhető és könnyen kezelhető, de
komoly költséggel járhat, ha a hálózat minden pontjára kell belőle egy
példány. Ugyanakkor nincs mindig szükség dedikált szerverre. A
DHCP-szolgáltatás egy Cisco forgalomirányító megfelelő beállításával is
biztosítható. Szükség esetén a Cisco forgalomirányítók a Cisco IOS egyik
szolgáltatása, az Easy IP funkció segítségével teljes értékű
DHCP-szerverként használhatók. Az Easy IP alapbeállítás szerint 24 órás
időtartamra adja ki a címbérleteket. A vállalat hálózati szakembereként
azt a feladatot kapjuk, hogy
állítsunk be egy Cisco forgalomirányítót, hogy DHCP-szerverként
dinamikusan osszon címeket a hálózaton lévő klienseknek. Ezen felül azt
is be kell állítanunk, hogy a perem-forgalomirányító DHCP-kliensként
saját IP-címet kapjon az internetszolgáltatótól.
PDF PKA
Part 1: Configure a Router as a DHCP Server
Step 1: Configure the excluded IPv4 addresses.
Configure R2
to exclude the first 10 addresses from the R1 and R3 LANs. All other
addresses should be available in the DHCP address pool.
Step 2: Create a DHCP pool on R2 for the R1 LAN.
a. Create a DHCP pool named R1-LAN (case-sensitive).
b. Configure the DHCP pool to include the network address, the default gateway, and the IP address of the DNS server.
Step 3: Create a DHCP pool on R2 for the R3 LAN.
a. Create a DHCP pool named R3-LAN (case-sensitive).
b. Configure the DHCP pool to include the network address, the default gateway, and the IP address of the DNS server.
Part 2: Configure DHCP Relay
Step 1: Configure R1 and R3 as a DHCP relay agent.
Step 2: Set PC1 and PC2 to receive IP addressing information from DHCP.
R1 Configuration
R1>en
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int g0/0
R1(config-if)#ip helper-address 10.1.1.2
R1(config-if)#exit
R1(config)#
R2 Configuration
R2>en
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip dhcp excluded-address 192.168.10.1 192.168.10.10
R2(config)#ip dhcp excluded-address 192.168.30.1 192.168.30.10
R2(config)#ip dhcp pool R1-LAN
R2(dhcp-config)#network 192.168.10.0 255.255.255.0
R2(dhcp-config)#default-router 192.168.10.1
R2(dhcp-config)#dns-server 192.168.20.254
R2(dhcp-config)#exit
R2(config)#ip dhcp pool R3-LAN
R2(dhcp-config)#network 192.168.30.0 255.255.255.0
R2(dhcp-config)#default-router 192.168.30.1
R2(dhcp-config)#dns-server 192.168.20.254
R3 Configuration
R3>en
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int g0/0
R3(config-if)#ip helper-address 10.2.2.2
R3(config-if)#
Assign DHCP addresses for the PCs (PC1 & PC2).
R2(config)#
R2(config)#int g0/1
R2(config-if)#ip add dhcp
R2(config-if)#ex
R2(config)#
After this we can check from R2 if 'show ip dhcp binding'. You should be at 100/100 (100%).
R2#show ip dhcp binding
IP address Client-ID/ Lease expiration Type
Hardware address
192.168.10.11 0002.4AA5.1470 -- Automatic
192.168.30.11 0004.9A97.2535 -- Automatic
A SLAAC bemutatása
A SLAAC egy olyan módszer, amellyel egy DHCPv6-szerver
szolgáltatásai nélkül szerezhetnek az eszközök IPv6 globális egyedi
címet. A SLAAC működése az ICMPv6 protokollon alapul. Az ICMPv6 az
ICMPv4-hez hasonló, de annál sokkal robusztusabb protokoll, amely
további funkcionalitást kínál. A SLAAC az ICMPv6 protokoll
forgalomirányító-keresés és forgalomirányító-hirdetés üzeneteinek
segítségével kínál címzési és egyéb konfigurációs adatokat, amelyeket
normál esetben egy DHCP-szerver biztosítana.
-
Forgalomirányító-keresés (Router Solicitation, RS) üzenet -
Ha egy kliens úgy van beállítva, hogy a címzési adatokat automatikusan a
SLAAC-tól kapja, akkor egy RS-üzenetet küld a forgalomirányítónak. Az
RS-üzenetet az IPv6 összes forgalomirányítót magába foglaló (all-routers
nevű) FF02::2 csoportcímére küldik el.
-
Forgalomirányító-hirdetés (Router Advertisement, RA) üzenet Az
RA-üzeneteket a forgalomirányítók küldik, hogy címzési információt
biztosítsanak azon klienseknek, amelyeket az IPv6-címük automatikus
megszerzésére állítottak be. Az RA-üzenet tartalmazza a helyi szegmens
előtagját és az előtag hosszát. A kliens ezen információk segítségével
hozza létre a saját IPv6 globális egyedi címét. A forgalomirányító
rendszeres időközönként, vagy egy RS-üzenetre válaszolva küld ki
RA-üzeneteket. Alapértelmezés szerint a Cisco forgalomirányítók 200
másodpercenként küldenek RA-üzenetet. Az RA-üzeneteket mindig az IPv6
összes állomást tartalmazó (all-nodes nevű) FF02::1 csoportcímére
küldik.
A SLAAC a nevéből eredően nem állapottartó. Az
állapotmentes szolgáltatás azt jelenti, hogy nincs olyan szerver, amely
karbantartja a hálózati címadatokat. A DHCP-vel ellentétben nincs olyan
SLAAC-szerver, amely tudja, hogy melyek a használatban lévő, és melyek a
rendelkezésre álló IPv6-címek.
Mielőtt egy forgalomirányító RA-üzeneteket küldhetne,
engedélyezni kell rajta az IPv6-irányítást. Ennek engedélyezéséhez
használjuk az alábbi parancsot:
Router(config)#
ipv6 unicast-routing
1. Az 1. ábrán látható topológia szerint a PC1 úgy van
beállítva, hogy automatikusan szerezzen magának IPv6-címet. Mivel a PC1
nem kapott RA-üzenetet az elindítása óta, ezért egy RS-üzenetet küld az
összes forgalomirányítót tartalmazó (all-routers) csoportcímre, amelyben
jelzi a helyi IPv6-forgalomirányító felé, hogy szüksége van egy
RA-üzenetre.
2. Ahogy a 2. ábrán is látszik, az R1 megkapja az
RS-üzenetet, amelyre egy RA-üzenettel válaszol. Az RA üzenet tartalmazza
a hálózat előtagját, valamint az előtag hosszát. Az RA-üzenet elküldése
az IPv6 összes állomást tartalmazó (all-nodes) FF02::1 csoportcímére
történik, amelyben a forgalomirányító link-local címe van megadva
IPv6-forráscímként.
3. A PC1 megkapja a helyi hálózat előtagját és az előtag
hosszát tartalmazó RA-üzenetet. A PC1 ezen információk alapján
létrehozza a saját IPv6 globális egyedi címét. A PC1 már rendelkezik egy
64-bites hálózati előtaggal, de egy globális egyedi cím létrehozásához
szüksége van egy 64-bites interfészazonosítóra (Interface ID, IID) is.
Annak, hogy a PC1 létrehozhassa a saját, egyedi IID-jét, két módja van:
-
EUI-64 - Az EUI-64 folyamat segítségével a PC1 a 48-bites MAC-címe alapján hoz létre egy IID-t.
-
Véletlenszerűen generált - A 64-bites IID lehet egy, a kliens operációs rendszere által generált véletlen szám.
A PC1 a 64-bites előtag és a 64-bites interfészazonosító
kombinálásával létrehozhat egy 128-bites IPv6 globális egyedi címet a 3.
ábrán látható módon. A PC1 a forgalomirányító link-local címét
használja az alapértelmezett átjáró címeként.
4. Mivel a SLAAC protokoll állapotmentes, ezért a PC1-nek
használat előtt ellenőriznie kell az újonnan létrehozott IPv6-cím
egyediségét. Ahogy a 4. ábrán is látszik, a PC1 egy ICMPv6
szomszédkeresés (Neighbor Solicitation) üzenetet küld ki, amelyben a
saját címe van megadva IPv6-célcímként. Ha semmilyen másik eszköz nem
válaszol a szomszédkeresés üzenetre, akkor a cím egyedi és a PC1
használatba veheti. Ha egy szomszédhirdetés (Neighbor Advertisement)
üzenet érkezik válaszként a PC1-nek, akkor a cím mégsem egyedi, így az
operációs rendszernek kell meghatározni az új interfészazonosítót.
Ez a folyamat az ICMPv6 szomszédfelderítő (Neighbor
Discovery) protokolljának részét képezi, és címütközés-érzékelés
(Duplicate Address Detection, DAD) néven is ismert.
10.2.1.3 SLAAC és DHCPv6
Az, hogy egy kliens az
IPv6-címadatait a SLAAC vagy a DHCPv6 használatával, esetleg a
kettő kombinációjával szerezze meg, az RA-üzenetben lévő beállításokon
múlik. Az ICMPv6 RA-üzenetei két jelzőbitet tartalmaznak, annak
jelölésére, hogy a kliensnek melyik lehetőséget kellene választania.
Az egyik a felügyelt címkonfigurációs jelzőbit (Managed
Address Configuration flag, M jelzőbit), a másik az egyéb konfigurációs
jelzőbit (Other Configuration flag, O jelzőbit).
Az M és az O jelzőbit különböző kombinációjával, az RA-üzenetek három
címzési lehetőség egyikét kínálják az IPv6 eszköz számára az ábrán
látható módon:
- SLAAC (csak forgalomirányító-hirdetéssel)
- Állapotmentes DHCPv6 (forgalomirányító-hirdetéssel és DHCPv6-tal)
- Állapottartó DHCPv6 (csak DHCPv6-tal)
Függetlenül a használt módtól az RFC 4861 azt javasolja,
hogy minden IPv6 eszköz végezze el a címütközés-érzékelést bármely
egyedi címre vonatkozóan, beleértve a SLAAC és DHCPv6 együttes
használatával beállított címeket is.
MEGJEGYZÉS: Habár az RA-üzenet meghatározza a kliens IPv6-címének dinamikus
megszerzéséhez javasolt folyamatot, a kliens operációs rendszere mégis
dönthet úgy, hogy figyelmen kívül hagyja az RA-üzenetet, és kizárólag
egy DHCPv6-szerver szolgáltatásait veszi igénybe.
A SLAAC opció (csak forgalomirányító-hirdetéssel)
A Cisco forgalomirányítókon a SLAAC az alapértelmezett
lehetőség. Ahogy az ábrán is látszik, ilyenkor az M és az O jelzőbit
értéke egyaránt 0 az RA-üzenetben.
Ez a lehetőség arra utasítja a klienst, hogy kizárólag az
RA-üzenet információit használja. Ebbe beletartoznak az előtagra, az
előtag hosszára, a DNS-szerverre, az MTU-ra, valamint az alapértelmezett
átjáróra vonatkozó adatok. További információt a DHCPv6-szervertől sem
fog kapni. Az IPv6 globális egyedi cím létrehozása úgy történik, hogy az
RA-üzenet előtagját kombináljuk az EUI-64 folyamat során vagy
véletlenszerűen generált interfészazonosítóval.
Az RA-üzenetek beállítása a forgalomirányítók egyes
interfészein történik. Ahhoz, hogy egy másik opcióra állított
interfészen ismételten engedélyezzük a SLAAC működését, az M és az O
jelzőbitek kezdőértékét vissza kell állítani 0-ra. Ezt az alábbi,
globális konfigurációs parancsokkal tehetjük meg:
Router(config-if)#
no
ipv6 nd managed-config-flag
Router(config-if)#
no ipv6 nd other-config-flag
10.2.1.5 Az állapotmentes DHCPv6 opció
Habár a DHCPv6 a kínált szolgáltatások tekintetében sokban
hasonlít a DHCPv4-hez, a két protokoll egymástól teljesen független. Az
DHCPv6-ot az RFC 3315 definiálja. A specifikáció nagyon komoly munka
eredménye, amit jól mutat az a tény, hogy az összes internetes
szabványtervezet közül a DHCPv6 RFC-jét dolgozták át a legtöbbször.
Az állapotmentes DHCPv6 opció (forgalomirányító-hirdetéssel és DHCPv6-tal)
Az állapotmentes DHCPv6 opció értesíti a klienst, hogy az
RA-üzenet információit kell használnia a címzéshez, de a többi
konfigurációs beállítást a DHCPv6-szerver bocsátja a rendelkezésére.
Az RA-üzenetben szereplő előtaggal és az előtag hosszával,
valamint az EUI-64 segítségével vagy véletlenszerűen generált
interfészazonosítóval, a kliens létrehozza a saját IPv6 globális egyedi
címét.
A kliens ezután kommunikálni kezd egy állapotmentes
DHCPv6-szerverrel, hogy megszerezze az RA-üzenetben nem szereplő további
adatokat. Ez lehet például egy DNS-szerverek IPv6-címeit tartalmazó
lista. Ezt a folyamatot állapotmentes DHCPv6-nak nevezzük, mivel a
szerver semmilyen, a kliens állapotára vonatkozó információt (pl.: a
kiosztott és a még rendelkezésre álló IPv6-címek listáját) nem tart
karban. Az állapotmentes DHCPv6-szerver kizárólag konfigurációs
beállításokat kínál a kliensek számára, IPv6-címet nem.
Az állapotmentes DHCPv6 esetében az O jelzőbit értékét 1-re
kell állítani, az M jelzőbit értéke pedig maradjon az alapértelmezés
szerinti 0. Az O jelzőbit 1-es értéke jelzi a kliens számára, hogy
további
konfigurációs beállítások állnak rendelkezésre egy állapotmentes
DHCPv6-szerveren.
Ahhoz, hogy egy forgalomirányító interfészén kiküldött
RA-üzenetet úgy módosítsunk, hogy az állapotmentes DHCPv6-ot jelöljön,
használjuk az alábbi parancsot:
Router(config-if)#
ipv6 nd other-config-flag
Állapottartó DHCPv6 (csak DHCPv6-tal)
Ez a lehetőség hasonlít legjobban a DHCPv4-hez. Ebben az
esetben az RA-üzenet azt jelzi a kliensnek, hogy ne használja az
RA-üzenet információit. Így minden címzési és konfigurációs adatot egy
DHCPv6-szervertől kell megszereznie. Ezt állapottartó DHCPv6-nak
nevezzük, mivel a DHCPv6-szerver tartja karban az IPv6-os
állapotinformációkat. Ez hasonlít arra, ahogy a DHCPv4-szerver osztja ki
az IPv4-címeket.
Az M jelzőbit mutatja, hogy szükség van-e az állapottartó
DHCPv6 használatára. Az O jelzőbitnek ebben nincs szerepe. Az
állapottartó DHCPv6 kifejezhető azzal, ha az alábbi parancs segítségével
átállítjuk az M jelzőbit értékét 0-ról 1-re:
Router(config-if)#
ipv6 nd managed-config-flag
Ahogy az 1. ábrán is látszik, mindegy, hogy állapotmentes
vagy állapottartó DHCPv6-ról van szó, minden a forgalomirányítótól
érkező ICMPv6-üzenettel kezdődik. Az RA-üzenet lehet periodikus, de
kérelmezheti egy RS-üzenetet küldő eszköz is.
Ha az RA-üzenet állapotmentes vagy állapottartó DHCPv6-ot
jelez, akkor az eszköz DHCPv6 kliens/szerver kommunikációt kezdeményez.
DHCPv6 kommunikáció
Ha az RA-üzenet állapotmentes vagy állapottartó DHCPv6-ot
jelez, a DHCPv6 műveleteket hívjuk segítségül. A DHCPv6-üzenetek küldése
UDP-n keresztül történik. A szerver által a kliensnek küldött
DHCPv6-üzenetek az UDP 546-os célportját használják. A kliens által a
szervernek küldött DHCPv6-üzenetek pedig az UDP 547-es célportját
használják.
A kliensnek, amely jelen esetben egy DHCPv6-kliens,
találnia kell egy DHCPv6-szervert. A 2. ábrán a kliens egy DHCPv6
SOLICIT üzenetet küld az IPv6 összes DHCPv6-szervert tartalmazó
(all-DHCPv6-servers nevű) FF02::1:2 csoportcímére. Ez a csoportcím
link-local hatókörrel rendelkezik, ami azt jelenti, hogy a
forgalomirányítók nem továbbítják az üzeneteket más hálózatokba.
Ahogy a 3. ábrán is látszik, egy vagy több DHCPv6-szerver
DHCPv6 ADVERTISE üzenet küldésével válaszol. Az ADVERTISE üzenet jelzi a
DHCPv6-kliens számára, hogy a szerver elérhető DHCPv6-szolgáltatással
rendelkezik.
A 4. ábrán a kliens válaszként egy DHCPv6 REQUEST vagy
INFORMATION-REQUEST üzenetet küld a szervernek, attól függően, hogy
állapottartó vagy állapotmentes DHCPv6-ról van szó.
-
Állapotmentes DHCPv6-kliens - A kliens egy olyan
DHCPv6 INFORMATION-REQUEST üzenetet küld a DHCPv6-szervernek, amely
kizárólag a konfigurációs beállításokat kéri. (Ilyen például a
DNS-szerver címe.) A kliens úgy generálta a saját IPv6-címét, hogy az
RA-üzenetben szereplő
előtagot, valamint egy önmaga által generált interfészazonosítót
használt.
-
Állapottartó DHCPv6-kliens - A kliens egy DHCPv6
REQUEST üzenetet küld a szervernek, hogy az IPv6-címet az összes egyéb
konfigurációs beállítással együtt a szervertől szerezze meg.
Ahogy az 5. ábrán is látszik, a szerver válaszként egy DHCPv6 REPLY
üzenetet küld a kliensnek, amely tartalmazza a REQUEST vagy
INFORMATION-REQUEST üzenetben kért adatokat.
10.2.2.1 Egy Cisco forgalomirányító állapotmentes DHCPv6-szerverként történő beállítása
Ahogy az 1. ábrán is látszik, egy forgalomirányító négy lépésben állítható be DHCPv6-szervernek.
1. lépés: Az IPv6-irányítás engedélyezése
Az ipv6 unicast-routing paranccsal
engedélyezhető az IPv6-irányítás. Ez a parancs nem szükséges ahhoz,
hogy a forgalomirányító állapotmentes DHCPv6-szerver legyen, de az
ICMPv6 RA-üzeneteinek küldéséhez nélkülözhetetlen.
2. lépés: DHCPv6 készlet beállítása
Az ipv6 dhcp pool készlet-neve parancs egy címkészletet hoz létre a megadott néven, majd DHCPv6 konfigurációs módba lépteti a forgalomirányítót, amelyet a Router(config-dhcpv6)# prompt jelez.
3. lépés: A készlet paramétereinek beállítása
A SLAAC folyamat során a kliens megkapta a saját IPv6
globális egyedi címének létrehozásához szükséges információkat. A kliens
az alapértelmezett átjáró adatait is megkapta az RA-üzenetben
szereplő IPv6-forráscím alapján, amely a forgalomirányító link-local
címe. Az állapotmentes DHCPv6-szerver azonban úgy is beállítható, hogy
egyéb információkat is biztosítson, amelyek nem feltétlenül szerepeltek
az RA-üzenetben. (Ilyen például a DNS-szerver címe, valamint a tartomány
neve.)
4. lépés: A DHCPv6-interfész beállítása
Az ipv6 dhcp server készlet-neve interfészkonfigurációs
parancs a DHCPv6-készletet hozzárendeli az interfészhez. Az
állapotmentes DHCPv6-kérésekre a forgalomirányító válaszként a
készletben szereplő információkat küldi ki a fenti interfészen. Az O
jelzőbit értékét át kell állítani 0-ról 1-re, az ipv6 nd other-config-flag interfészkonfigurációs parancs segítségével. A fenti interfészen küldött RA-üzenetek azt jelzik, hogy további
információ áll rendelkezésre az állapotmentes DHCPv6-szerveren.
Példa egy állapotmentes DHCPv6-szerverre
A 2. ábrán egy forgalomirányító állapotmentes
DHCPv6-szerverként történő beállítására láthatunk példát. Vegyük észre,
hogy az R3 forgalomirányító DHCPv6-kliensként szerepel benne! Az R3
forgalomirányító kliensként történő beállítása segít az állapotmentes
DHCPv6-műveletek ellenőrzésében.
Az állapotmentes DHCPv6-szerver ellenőrzése
Az 1. ábrán látható show ipv6 dhcp pool
paranccsal ellenőrizhető a DHCPv6-készlet neve és beállításai. Az aktív
kliensek száma 0, mivel nincs olyan állapot, amelyet karbantartana a
szerver.
A show running-config paranccsal szintén ellenőrizhető az összes korábban beállított utasítás.
Az állapotmentes DHCPv6-kliens ellenőrzése
Az ábrán látható példában egy forgalomirányító tölti be az állapotmentes DHCPv6-kliens szerepét. A 2. ábrán a show ipv6 interface parancs kimenetéből látszik, hogy a forgalomirányítón engedélyezve van az állapotmentes cím automatikus konfigurációja: "Stateless address autoconfig enabled",
valamint az, hogy a forgalomirányító rendelkezik globális egyedi IPv6
címmel. Az IPv6 globális egyedi cím létrehozása a SLAAC használatával
történt, amely tartalmazza az RA-üzenetben szereplő előtagot. Az
interfészazonosító generálása az EUI-64 segítségével történt. Az
IPv6-cím kiosztása nem a DHCPv6 segítségével valósult meg.
Az alapértelmezett forgalomirányító adatai szintén az
RA-üzenetből származnak. Ez annak a csomagnak az IPv6-forráscíme, amely
az RA-üzenetet és a forgalomirányító link-local címét tartalmazta.
A 3. ábrán a debug ipv6 dhcp detail
parancs kimenete megjeleníti a kliens és a szerver között váltott
DHCPv6-üzeneteket. Ebben a példában a parancsbevitel a kliensen történt.
Az INFORMATION-REQUEST üzenet azért látszik, mert egy állapotmentes
DHCPv6-kliensről küldték. Figyeljük meg, hogy a kliens szerepét betöltő
R3 forgalomirányító a DHCPv6-üzeneteket a link-local címéről küldi az
összes DHCPv6-közvetítőt és -szervert tartalmazó
(All_DHCPv6_Relay_Agents_and_Servers nevű) FF02::1:2 címre.
A hibakeresési kimenet megjeleníti a kliens és a szerver
között váltott összes DHCPv6-üzenetet, beleértve a DNS-szervert és a
szerveren megadott tartománynév-beállításokat.
A 4. ábrán található parancsszimulátor segítségével állítsuk be és ellenőrizzük a forgalomirányítón az állapotmentes DHCPv6-ot!
Enable IPv6 routing and configure an IPv6 dhcp pool named IPV6-STATELESS with the following parameters:
DNS Server - 2001:db8:cafe:aaaa::5
Domain - example.com
R1(config)# ipv6 unicast-routing
R1(config)# ipv6 dhcp pool IPV6-STATELESS
R1(config-dhcpv6)# dns-server 2001:db8:cafe:aaaa::5
R1(config-dhcpv6)# domain-name example.com
Exit dhcpv6 configuration mode and configure the following parameters on g0/1:
Address - 2001:db8:cafe:1::1/64
Set the IPv6 dhcp server to use the pool created previously.
Set the neighbor discover to use the O flag (Other Configuration Flag).
R1(config-dhcpv6)# exit
R1(config)# interface g0/1
R1(config-if)# ipv6 address 2001:db8:cafe:1::1/64
R1(config-if)# ipv6 dhcp server IPV6-STATELESS
R1(config-if)# ipv6 nd other-config-flag
Configure R3 as a stateless DHCPv6 client, exit completely out of configuration mode when complete.
R3(config)# interface g0/1
R3(config-if)# ipv6 enable
R3(config-if)# ipv6 address autoconfig
Verify the ipv6 dhcp settings on R1.
R1# show ipv6 dhcp pool
DHCPv6 pool: IPV6-STATELESS
DNS server: 2001:DB8:CAFE:AAAA::5
Domain name: example.com
Active clients: 0
R1#
Verify the ipv6 settings on g0/1 on R3.
R3# show ipv6 interface g0/1
GigabitEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::32F7:DFF:FE25:2DE1
No Virtual link-local address(es):
Stateless address autoconfig enabled
Global unicast address(es):
2001:DB8:CAFE:1:32F7:DFF:FE25:2DE1, subnet is 2001:DB8:CAFE:1::/64
[EUI/CAL/PRE]
valid lifetime 2591935 preferred lifetime 604735
Joined group address(es):
FF02::1
FF02::1:FF25:2DE1
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 30000)
ND NS retransmit interval is 1000 milliseconds
Default router is FE80::D68C:B5FF:FECE:A0C1 on GigabitEthernet0/1
R3#
Use the debug command to view detailed ipv6 dhcp packets.
R3# debug ipv6 dhcp detail
IPv6 DHCP debugging is on (detailed)
R3#
*Feb 3 02:39:10.454: IPv6 DHCP: Sending INFORMATION-REQUEST to FF02::1:2
on GigabitEthernet0/1
*Feb 3 02:39:10.454: IPv6 DHCP: detailed packet contents
*Feb 3 02:39:10.454: src FE80::32F7:DFF:FE25:2DE1
*Feb 3 02:39:10.454: dst FF02::1:2 (GigabitEthernet0/1)
*Feb 3 02:39:10.454: type INFORMATION-REQUEST(11), xid 12541745
*Feb 3 02:39:10.454: IPv6 DHCP: Adding server FE80::D68C:B5FF:FECE:A0C1
*Feb 3 02:39:10.454: IPv6 DHCP: Processing options
*Feb 3 02:39:10.454: IPv6 DHCP: Configuring DNS server
2001:DB8:CAFE:AAAA::5
*Feb 3 02:39:10.454: IPv6 DHCP: Configuring domain name example.com
*Feb 3 02:39:10.454: IPv6 DHCP: DHCPv6 changes state from INFORMATION-
REQUEST to IDLE (REPLY_RECEIVED) on GigabitEthernet0/1
10.2.3.1 Egy forgalomirányító állapottartó DHCPv6-szerverként történő beállítása
Egy állapottartó DHCPv6-szerver beállítása nem sokban
különbözik egy állapotmentes szerver beállításától. A legjelentősebb
eltérés az, hogy egy állapottartó szerver a DHCPv4-szerverekhez
hasonlóan IPv6-címadatokat is tartalmaz.
1. lépés: Az IPv6-irányítás engedélyezése
Az ábrán látható módon használjuk az
ipv6 unicast-routing parancsot
az IPv6-irányítás engedélyezéséhez. Ez a parancs nem szükséges ahhoz,
hogy a forgalomirányító állapottartó DHCPv6-szerver legyen, de az ICMPv6
RA-üzeneteinek küldéséhez nélkülözhetetlen.
2. lépés:
DHCPv6 készlet beállítása
Az
ipv6 dhcp pool készlet-neve parancs egy címkészletet hoz létre a megadott névvel, majd DHCPv6 konfigurációs módba lépteti a forgalomirányítót, amelyet a
Router(config-dhcpv6)# prompt jelez.
3. lépés:
A készlet paramétereinek beállítása
Az állapottartó DHCPv6 esetében minden címzési és konfigurációs adatot a DHCPv6-szervernek kell kiosztania. Az
address prefix/hossz parancs kiadásával jelezhetjük, hogy a címkészletet a szerver osztja ki. A
lifetime paraméter
mutatja az érvényben lévő, valamint az előnyben részesített bérleti
időt, másodpercben megadva. Csakúgy, mint az állapotmentes DHCPv6
esetében, a kliens annak a
csomagnak az IPv6-forráscímét használja, amely tartalmazta az
RA-üzenetet.
Az állapottartó DHCPv6-szerver által biztosított egyéb
információk között jellemzően szerepel a DNS-szerver címe, valamint a
tartomány neve.
4. lépés: Az interfészkonfigurációs parancsok
Az
ipv6 dhcp server készlet-neve interfészkonfigurációs
parancs a DHCPv6-készletet hozzárendeli az interfészhez. Az
állapotmentes DHCPv6-kérésekre a forgalomirányító válaszként a
készletben szereplő információkat küldi ki a fenti interfészen. Az M
jelzőbit értékét át kell állítani 0-ról 1-re, az
ipv6 nd managed-config-flag
interfészkonfigurációs paranccsal. Ez értesíti az eszközt, hogy ne a
SLAAC-t használja, hanem egy állapottartó DHCPv6-szervertől szerezze meg
a címadatokat és az összes konfigurációs beállítást.
Példa egy állapottartó DHCPv6-szerverre
A 2. ábrán az R1 forgalomirányító állapottartó
DHCPv6-szerverként történő beállítására láthatunk példát. Vegyük észre,
hogy az alapértelmezett átjáró nincs megadva, mivel a forgalomirányító
automatikusan a saját link-local címét küldi el alapértelmezett
átjáróként! Az R3 forgalomirányító kliensként történő beállítása segít
az állapottartó DHCPv6-műveletek ellenőrzésében.
10.2.3.2 Egy forgalomirányító állapottartó DHCPv6-kliensként történő beállítása
Az ábrán látható módon használjuk az
ipv6 enable
interfészkonfigurációs parancsot, hogy a forgalomirányító megkapja a
link-local címét, küldhessen RS-üzeneteket és részt vehessen a
DHCPv6-folyamatban is.
Az
ipv6 address dhcp interfészkonfigurációs paranccsal engedélyezhetjük, hogy a forgalomirányító DHCPv6-kliensként viselkedjen ezen az interfészen.
10.2.3.4 Egy forgalomirányító DHCPv6-közvetítőként történő beállítása
Ha a DHCPv6-szerver és a kliens eltérő hálózaton vannak,
akkor az IPv6-forgalomirányítót beállíthatjuk DHCPv6-közvetítőként. Egy
DHCPv6-közvetítő beállítása nem sokban különbözik egy
IPv4-forgalomirányító DHCPv4-közvetítőként történő beállításától.
MEGJEGYZÉS: Habár egy DHCP-közvetítő beállítása nem
sokban különbözik DHCPv6 és DHCPv4 esetén, az IPv6-forgalomirányítók és
-közvetítők kissé eltérő módon továbbítják a DHCPv6-üzeneteket, mint a
DHCPv4-közvetítők. Ezek az üzenetek és a folyamat túlmutatnak a jelen
tananyag keretein.
Az 1. ábrán látható topológia szerint a
2001:DB8:CAFE:1::/64 hálózaton található egy DHCPv6-szerver. A hálózati
rendszergazda ezt egy központi, állapottartó DHCPv6-szerverként kívánja
használni, amely az összes kliens IPv6-címének kiosztásáért felel. Ennek
következtében a más hálózatra kapcsolódó klienseknek.(például a
2001:DB8:CAFE:A::/64 hálózaton lévő PC1-nek) kommunikálniuk kell a
DHCPv6-szerverrel.
A kliensektől származó DHCPv6-üzenetek kiküldése az összes
DHCPv6-közvetítőt és -szervert tartalmazó
(All_DHCPv6_Relay_Agents_and_Servers nevű) FF02::1:2 címre történik. Ez a
cím link-local hatókörrel rendelkezik, ami azt jelenti, hogy a
forgalomirányítók nem továbbítják az üzeneteket más hálózatokba. Ahhoz,
hogy a DHCPv6-szerver és -kliens képes legyen egymással kommunikálni, az
IPv6-forgalomirányítót DHCPv6-közvetítőként kell beállítanunk.
A DHCPv6-közvetítő beállítása
Ahogy a 3. ábrán is látszik, egy DHCPv6-közvetítő beállítása az
ipv6 dhcp relay destination
paranccsal történik. Ezt a parancsot a DHCPv6-kliens felőli interfészen
kell kiadni, célként pedig a DHCPv6-szerver címe legyen megadva.
A
show ipv6 dhcp interface
paranccsal ellenőrizhető, hogy a G0/0 interfész közvetítő módban van-e,
valamint a 2001:DB8:CAFE:1::6 cím van-e DHCPv6-szerverként megadva.
Az 3. ábrán található parancsszimulátor segítségével a megfelelő
forgalomirányítón beállíthatók a DHCPv6 közvetítő parancsok, így a PC3
kaphat IPv6-címet a DHCPv6-szervertől. Vegyük alapul az 1. ábrán látható hálózat topológiáját!
Configure the DHCPv6 relay commands on the correct router for PC3 to receive an IPv4 address and other parameters from the DHCPv6 server. Exit configuration mode on any device that needs no configuration.
R3(config)# interface g0/0
R3(config-if)# ipv6 dhcp relay destination 2001:db8:cafe:1::6
