Ha még nem olvastad, olvasd el ezt a bejegyzést: Frame Relay konfigurálása
Mind a Packet Tracer-ben, mind a GNS3-ban ugyan beépítve találunk egy-egy Frame Relay kapcsolót, de mindkettő csupán szimulálja ezt az eszközt. A Cisco forgalomirányítókból azonban egy nagyon egyszerű konfigurációval magunk is készíthetünk Frame Relay kapcsolót. Nézzük meg most ezt.
Induljunk ki a már jól megszokott topológiákból. Az R4 forgalomirányítót fogjuk Frame Relay kapcsolóként konfigurálni.
R1, R2 és R3 forgalomirányítókon konfiguráljuk az IP címeket és a Frame Relay beágyazást:
R1(config)#interface Serial1/0
R1(config-if)#encapsulation frame-relay
R1(config-if)#ip address 10.0.0.1 255.0.0.0
R1(config-if)#no shutdown
R2(config)#interface Serial1/0
R2(config-if)#encapsulation frame-relay
R2(config-if)#ip address 10.0.0.2 255.0.0.0
R2(config-if)#no shutdown
R3(config)#interface Serial1/0
R3(config-if)#encapsulation frame-relay
R3(config-if)#ip address 10.0.0.3 255.0.0.0
R3(config-if)#no shutdown
Térjünk rá az igazi feladatra, R4 konfigurációjára. Először átkapcsoljuk Frame Relay kapcsoló módba:
R4(config)#frame-relay switching
Foglalkozzunk most R4 R1-hez kapcsolódó interfészével. Először is beállítjuk az órajelet. Ne feledjük, R4 lesz a DCE, vagyis ő határozza meg az órajelet a kapcsolatban.
R4(config)#interface Serial1/0
R4(config-if)#clock rate 128000
Ágyazzuk be a protokollt, utána kijelöljük az interfészt DCE-nek:
R4(config-if)#encapsulation frame-relay
R4(config-if)#frame-relay intf-type dce
R4(config-if)#no shutdown
Az interfészt DCE, DTE és NNI módba kapcsolhatjuk. DTE az alapértelmezett. Ilyenkor a forgalomirányító egy Frame Relay hálózathoz kapcsolódik vele. NNI (Network-to-Network Interface) módot akkor használunk, ha két Frame Relay kapcsolóként konfigurált forgalomirányító egymáshoz kapcsolódik. DCE módban, ahogyan a fenti példában láthatjuk, egy forgalomirányítóhoz kapcsolódhatunk vele.
Ezután meg kell határoznunk a kapcsolón áthaladó PVC-t. Egyszerű dolgunk van, mivel most egyetlen kapcsoló köti össze R1-et és R2-t. Emlékezzünk vissza a Frame Relay kapcsoló szerepére a DLCI cím kezelésében: A forrás forgalomirányító által betett DLCI címet a cél forgalomirányító előtti Frame Relay kapcsoló kicseréli arra a DLCI-re, amivel a cél forgalomirányító azonosítja a PVC-t. Gyakorlatilag ezt a folyamatot írjuk elő a következő paranccsal:
R4(config-if)#frame-relay route 23 interface serial 1/1 47
A parancsot így olvassuk: Az S1/0 interfészen (hiszen ennek a konfigurációjában adjuk ki a parancsot) beérkező 23-as DLCI-vel rendelkező Frame Relay keretet továbbítsd az S1/1 interfészen úgy, hogy cseréld ki a DLCI-t 47-re.
Ugyanezt konfiguráljuk a R2 oldaláról is a S1/1 interfészen:
R4(config)#interface Serial1/1
R4(config-if)#clock rate 128000
R4(config-if)#encapsulation frame-relay
R4(config-if)#frame-relay intf-type dce
R4(config-if)#frame-relay route 47 interface serial 1/0 23
R4(config-if)#no shutdown
Az eddigi konfigurációt tartalmazza a következő ábra:
Az R1 és R2 közötti virtuális áramkört létrehoztuk. Ellenőrizzük le. Először jelenítsük meg R4-et a kialakított Frame Relay útvonalakat a show frame-relay route paranccsal. Jól látható, hogy az általunk konfigurált útvonalak a megfelelő interfészen rendelkezésünkre állnak aktív állapottal.
R4#sh frame-relay route
Input Intf Input Dlci Output Intf Output Dlci Status
Serial1/0 23 Serial1/1 47 active
Serial1/1 47 Serial1/0 23 active
Nézzük meg, hogy R1-en is megjelent-e a PVC. Azt tapasztaljuk, hogy igen, tehát az LMI is rendben működik.
R1#sh frame-relay pvc | i DLCI
DLCI = 23, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1/0
És az inverz ARP is megtette a dolgát, a DLCI-IP párok is kialakultak:
R1#sh frame-relay map
Serial1/0 (up): ip 10.0.0.2 dlci 23(0x17,0x470), dynamic,
broadcast,
CISCO, status defined, active
A biztonság kedvéért nézzük meg, milyen LMI-t használnak. Azt látjuk, az alapértelmezett Cisco típusút:
R1#sh frame-relay lmi LMI Statistics for interface Serial1/0 (Frame Relay DTE) LMI TYPE = CISCO
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 236 Num Status msgs Rcvd 68
Num Update Status Rcvd 0 Num Status Timeouts 169
Last Full Status Req 00:00:40 Last Full Status Rcvd 00:00:40
Természetesen ha R2-n futtatjuk ezeket a show parancsokat, hasonló eredményt kapunk.
Az előző cikkben, ahol a GNS3 beépített Frame Relay kapcsolóját használtuk, nem tudtuk kipróbálni az LMI konfigurációját. Itt most megtehetjük.
Mint a Frame Relay alapjai cikkben olvashattuk, az LMI végzi el a DTE és a DCE eszköz közötti kapcsolattartást. A DCE eszköz (a Frame Relay kapcsoló) az alapértelmezetten 60 másodpercenként kiküldött LMI üzeneteken keresztül tájékoztatja a forgalomirányítót például a PVC-k állapotáról, valamint keepalive üzenetket is küld. (És a forgalomirányító is viszont.) Az LMI üzenetek fogadása kikapcsolható a forgalomirányítón a no keepalive interfész alparanccsal. Tegyük ezt meg az R1 S1/0 interfészén:
R1(config-if)#no keepalive
Kis idő elteltével azt tapasztaljuk, hogy noha az R1 nem felejtette el a PVC-ket és a DLCI-IP összerendelést, és S1/0 interfésze up/up állapotban maradt, mégsem tudja elérni már R2-t. Jelenítsük meg R4-en (vagyis a Frame Relay kapcsolón) az interfészek állapotát. Mivel R4 az S1/0 interfészén keresztül már nem kap ébrenléti (keepalive) üzeneteket, protokoll állapota DOWN lett, ez az oka a kapcsolat hiányának. (R1 R4-től még kap keepalive üzeneteket, ott ezért maradt az interfész állapota UP/UP.)
R4#sh ip interface brief
Interface IP-Address OK? Method Status Protocol
Serial1/0 unassigned YES unset up down
Serial1/1 unassigned YES unset up up
Kapcsoljuk vissza az ébrenléti üzeneteket R1-en:
R1(config-if)#keepalive
Jegyezzük meg, az ébrenléti üzenetek csupán a forgalomirányító és a Frame Relay kapcsoló között haladnak, és nem a két forgalomirányító között!
Nézzük az LMI típusát. A Cisco IOS a 11.2 verziótól kezdve automatikusan megállapítja, hogy a kapcsoló milyen LMI-t használ, és automatikusan ezt állítja be a kapcsolóhoz csatlakozó interfészen. Természetesen ezt mi átállíthatjuk (erre szolgál a frame-relay lmi-type [cisco|ansi|q933a] interfész alparancs), de így hibába futhatunk bele. Konfiguráljuk például R1 S1/0 interfészén az LMI típusát q933a-ra. (A GNS3 Frame Relay kapcsolója az ANSI-t használja.)
R1(config-if)#frame-relay lmi-type q933a
Ezután már nem cserélnek LMI üzeneteket (hiszen nem azonos LMI protokollt használnak), és a hozzáférési összeköttetés nem fog működni. A protokoll állapota R1-en és R4-is DOWN lesz:
R1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Serial1/0 10.0.0.1 YES NVRAM up down
Serial1/1 unassigned YES unset up up
R4#sh ip interface brief
Interface IP-Address OK? Method Status Protocol
Serial1/0 unassigned YES unset up down
Serial1/1 unassigned YES unset up up
Állítsuk vissza az R1 forgalomirányítón a CISCO LMI típust, és helyreáll a kapcsolat:
R1(config-if)#frame-relay lmi-type cisco
Konfiguráljuk most a másik virtuális áramkört. R4 S1/0 interfészén csupán annyi a dolgunk, hogy definiáljuk ezt az új virtuális áramkört:
R4(config-if)#frame-relay route 36 interface serial 1/2 23
Az S1/2 interfészen már az órajelállítást, a beágyazást, az interfész típusának beállítását és a PVC definiálását is el kell végeznünk:
R4(config)#interface Serial1/2
R4(config-if)#clock rate 128000
R4(config-if)#encapsulation frame-relay
R4(config-if)#frame-relay intf-type dce
R4(config-if)#frame-relay route 23 interface serial 1/0 36
R4(config-if)#no shutdown
Láthatjuk milyen egyszerű egy forgalomirányítóból Frame Relay kapcsolót konfigurálni, és ez a módszer labor körülmények között is nagyszerűen működik.
Ha érdekelt a bejegyzés, olvasd el ezt is: Frame relay hálózat tervezése
