Frame Relay konfigurálása

Először nézzük meg a kialakult PVC-ket. (A statisztikát most nem jelenítjük meg.)

R1#sh frame-relay pvc | i DLCI
DLCI = 23, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0
DLCI = 36, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

Jól láthatók a Frame Relay kapcsolón konfigurált PVC-k. A PVC-k állapotáról később még részletesen szó lesz, itt most annyit láthatunk, hogy aktívak, vagyis forgalmazni lehet rajtuk.

Ezután jelenítsük meg az összerendelt DLCI-IP párokat. A dinamikus megjelölés mutatja, hogy R1 az inverz ARP-vel tanulta meg a virtuális áramkörök másik végén található IP címeket.

R1#sh frame-relay map
Serial1/0 (up): ip 10.0.0.2 dlci 23(0x17,0x470), dynamic,
broadcast,, status defined, active
Serial1/0 (up): ip 10.0.0.3 dlci 36(0x24,0x840), dynamic,
broadcast,, status defined, active

Próbáljuk meg megpingetni R1-en a saját IP címét. Azt tapasztaljuk, hogy nem sikerül.

R1#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Természetesen már tudjuk a sikertelen ping okát: Nincsen definiálva a saját IP címéhez vezető PVC címe. Pótoljuk ezt egy statikus összerendeléssel:

R1(config-if)#frame-relay map ip 10.0.0.1 23

És így most már működik a ping:

R1#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/160/184 ms

Nézzük meg ismét a forgalomirányítón az IP DLCI összerendeléseket. Jól láthatjuk, megjelent ez utóbbi, általunk defifniált, de statikus megjelöléssel, jelezve, hogy ezt nem a Frame Relay kapcsolótól tanulta meg inverz ARP-vel, hanem manuálisan lett általunk beállítva:

R1#sh frame-relay map
Serial1/0 (up): ip 10.0.0.1 dlci 23(0x17,0x470), static,
CISCO, status defined, active
Serial1/0 (up): ip 10.0.0.2 dlci 23(0x17,0x470), dynamic,
broadcast,, status defined, active
Serial1/0 (up): ip 10.0.0.3 dlci 36(0x24,0x840), dynamic,
broadcast,, status defined, active

A frame-relay map parancs (elméletileg) kikapcsolja az inverz ARP-t, vagyis ezután már minden összerendelést statikusan kell megadni. Az inverz ARP-t a no frame-relay inverse-arp paranccsal mi magunk is letilthatjuk. Ez a folyamat viszont nem egészen egyértelmű. Az inverz ARP kétféle üzenetből áll, a kérésből (inverse ARP request) és a válaszból (inverse ARP replay). Ezek közül a tiltás csak a válaszra vonatkozik, vagyis a kérést elküldi az eszköz, de egy beérkező kérére nem válaszol. De a kérésből is tanul az eszköz, vagyis a folyamat felemásra sikerül így. Ráadásul ez gyártó és implementáció függő is lehet. (Lehet vele kísérletezni, csak győzze kivárni az ember az időzítőket.) Biztosra akkor mehetünk, ha mindkét oldalon letiltjuk az inverz ARP-t. Akármennyire hasznos is ez a protokoll, megfontolandó az IP-DLCI összerendeléseket a saját kezünkben tartani a frame-relay map parancs használatával. Valamennyi összerendelést úgysem lehet automatikusan létrehozni. Gondoljunk például arra, mi történik, ha R2 meg akarja pingetni R3-at. R2-nek ismernie kell az R3-hoz vezető PVC-t. Mivel közvetlen PVC nem lett definiálva felé, csak R1-en keresztül érheti el, ezt azonban az inverz ARP nem tudja kitalálni. Az meg nem túl szerencsés, ha bizonyos IP-DLCI összerendeléseket mi magunk készítünk el, a többi meg automatikusan jön létre. (Persze gyakorlati helyzete váltogatja.) Ha szükség van rá, a korábban dinamikusan megtanult összerendelések a clear frame-relay inarp paranccsal törölhetők ki. Amennyiben a frame-relay map parancsot kiegészítjük a broadcast kulcsszóval (pl. frame-relay map ip 10.0.0.2 23 broadcast), akkor ezen az áramkörön keresztül a 3. rétegbeli szórásos üzeneteket is továbbítja a forgalomirányító. Erre főleg dinamikus útvonalválasztó protokollok használata esetén van szükség.

Konfiguráljuk a többi forgalomirányítón is, hogy elérjék a saját IP címüket, valamint R2 és R3 elérje egymást. (Értelemszerűen ezeket a parancsokat az S1/0 interfész konfigurációjaként adjuk ki.)

R2(config-if)#frame-relay map ip 10.0.0.2 47
R2(config-if)#frame-relay map ip 10.0.0.3 47

R3(config-if)#frame-relay map ip 10.0.0.3 23
R3(config-if)#frame-relay map ip 10.0.0.2 23

A frame-relay map parancsnak van egy mellékhatása: Mivel interfész alparancsként adjuk ki, és szerepel benne a DLCI is, így az interfészhez rendeli a DLCI-t is. (Amit ez az interfész az LMI üzenetekből is megtanul.)

Próbáljunk ki valamit: Hozzunk létre R1-en manuálisan egy olyan PVC-t (legyen a címe 40), amelyet nem definiálunk a Frame Relay kapcsolón. PVC manuális (statikus) létrehozására a frame-relay interface dlci interfész alparancsot használjuk.

R1(config-if)#frame-relay interface-dlci 40

Listázzuk ki most is R1-en a PVC-ket. Azt láthatjuk, hogy azt a virtuális áramkört, amely csak a forgalomirányítón van az interfészhez rendelve, de nincsen a Frame Relay kapcsolón létrehozva, törölt állapotúnak jelöl meg az IOS.

R1#sh frame-relay pvc | i DLCI
DLCI = 23, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0
DLCI = 36, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0
DLCI = 40, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial1/0

Állítsuk vissza az eredeti állapotot (vagyis töröljük a forgalomirányítóról ezt a nem létező PVC-t):

R1(config-if)#no frame-relay interface-dlci 40

Noha a Frame Relay kapcsolók automatikusan hirdetik a PVC-ket a forgalomirányítóknak az LMI segítségével, semmi nem akadályoz meg minket, hogy a működő PVC-k DLCI címét mi magunk rendeljük statikusan a forgalomirányító adott interfészéhez:

R1(config-if)#no frame-relay interface-dlci 23
R1(config-if)#no frame-relay interface-dlci 36

Jelenítsük meg most az R1 forgalomirányítón az LMI információkat. A sok statisztikai információ között számunkra most az a fontos, hogy ezt egy DTE eszközön adták ki, illetve a használt LMI protokoll az ANSI. (Alapértelmezetten a GNS3 frame-relay kapcsolója az ANSI LMI protokollt használja. Nem átállítható.)

R1#sh frame-relay lmi
LMI Statistics for interface Serial1/0 (Frame Relay DTE) LMI TYPE = ANSI
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 832 Num Status msgs Rcvd 829
Num Update Status Rcvd 0 Num Status Timeouts 3
Last Full Status Req 00:00:05 Last Full Status Rcvd 00:00:05

Sajnos a GNS3-ba beépített Frame Relay kapcsoló csak részben szimulálja egy Frame Relay kapcsoló működését, így a hozzáférési összeköttetés LMI üzeneteivel való kísérletezgetést itt nem végezhetjük el, ugyanis nem a valóságnak megfelelő eredményt szolgáltatná. A következő cikkben egy valós forgalomirányítóból készítünk majd kapcsolót, és ott már megnézhetjük az LMI működését.

Első nekifutásra ennyi elég is a Frame Relay konfgurációból. Láthatjuk, amennyiben Cisco eszközökön alapértelmezetten hagyjuk a beállításokat, elegendő csak beágyaznunk a protokollt az interfészeken, és az IP címek konfigurálása után már minden működik. Az utána következő parancsokkal már csak ezt a működő hálózatot finomítottuk. A helyzet azonban nem ennyire egyszerű. A fenti példahálózatunk túl egyszerű, a gyakorlat ennél egy kicsit bonyolultabb. Lehet, hogy R1-R2 és R1-R3 más-más hálózatokban vannak, a hálózat non-broadcast jellege miatt az olyan protokollokok, mint például az OSPF nem amegszokott módon működnek, és hát a gyakorlatban nem vehetünk elő egy “egérrel kattintgatható” frame relay kapcsolót, mint a GNS3-ban vagy a Packet Tracer-ben. Ezekről a problémákról fognak szólni a következő cikkek.

Ha érdekelt a bejegyzés, olvasd el ezt is: Frame Relay kapcsoló konfigurálása