Frame Relay – megérteni és megszeretni?

Egyik nagy mumusom mindig a Frame Relay volt már a CCNA/CCNP időkben is. Sosem értettem teljesen, mikor hogy viselkedik, ezért nem is szerettem. Szerintem a Cisco könyvekben nem érthetően magyarázzák, és a való életben sem láttam még ezt a technológiát. Most megpróbálom érthetővé tenni, mikor hogy viselkedik a Frame-Relay: LMI, InARP, DLCI…

Kezdjük. A topológia most nem a kis szokásos lesz, az INE-t használom fel erre a célra.
Számunkra ez lesz a releváns rész:

frame_relay_ine

Egy kicsit áttekinthetőbb formában így néz ki, DLCI-kkel együtt.

frame_relay_ine_topology

A FRSW már előre fel van konfigurálva. Menjünk végig eseteken.

1. Fizikai interface

– Minden fizikai interface “multipoint” interface alapértelmezetten. Ez azt jelenti, hogy több DLCI tartozhat hozzá. Mivel az InARP protokol alapértelmezetten engedélyezve van, ezért látjuk a többi routert IP/DLCI párral a map táblában.
Nézzünk egy példát.

 

R5#
 R5#conf t
 Enter configuration commands, one per line. End with CNTL/Z.
 R5(config)#int s0/0
 R5(config-if)#encap frame
 R5(config-if)#ip add 155.1.0.5 255.255.255.0
 R5(config-if)#no shut
 R5(config-if)#^Z
 R5#
 

 

Semmi mást nem tettünk, minthogy beállítottuk a Frame Relay-t és egy IP-t.
Nézzük, kapjuk -e a FRSW-től az LMI (Local Management Interface) üzeneteket.

 

R5#sh frame-relay lmi
 LMI Statistics for interface Serial0/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 6 Num Status msgs Rcvd 7
 Num Update Status Rcvd 0 Num Status Timeouts 0
 Last Full Status Req 00:00:07 Last Full Status Rcvd 00:00:07
 R5#

 

Tehát az LMI működik. És ha az LMI működik, a routerünk automatikusan InARP request-eket fog küldeni, ahogy ez látszik a debug-ban:

 

R5#debug frame packet
 Frame Relay packet debugging is on
 R5#
 *Mar 1 03:05:02.023: Serial0/0(o): dlci 501(0x7C51), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
 *Mar 1 03:05:02.027: FR: Sending INARP Request on interface Serial0/0 dlci 501 for link 7(IP)
 *Mar 1 03:05:02.031: Serial0/0(o): dlci 502(0x7C61), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34

 

Tehát amint az LMI megvan, a routerünk rekámozza magát: hééé, én itt vagyok! IP-m 155.1.0.1 (hexából ha visszafejtitek, ez látszik a debug-ban). Senkit ne zavarjon össze az ARP (0x806) a debugban. A Frame-Relay Inverse-ARP az ARP protokoll formátumát használja.

Nézzük, kapunk -e már valami infonk más routerekről:

R5#sh frame-relay map
 [üres]
 R5#

 

De a PVC-ket kapjuk a FRSW-től. Tehát minden PVC-n toljuk ki az InARP REQ-t. Miért mindegyiken? Mert mindegyik a fizikai interface-hez tartozik. Akkor van inARP küldés, ha protokoll-DLCI páros van konfigurálva. IP van, DLCI meg mindegyik, toljuk hát mindegyik PVC-n az InARP-t.

 

R5#sh frame-relay pvc | i DLCI
 DLCI = 501, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 DLCI = 502, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 DLCI = 503, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 DLCI = 504, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 DLCI = 513, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 R5#

 

Map még nincs. Nosza, konfiguráljuk fel R1-et is. Ott is fizikai interface-re teszem a konfigot. Tehát InARP engedélyezve, több DLCI tartozhat az interface-hez.

R5 megkapja R1 InARP REQ üzenetét, és válaszol neki a saját adataival. R1-n hasonló történik.

 

*Mar 1 03:09:46.523: Serial0/0: frame relay INARP received
  *Mar 1 03:09:46.527: FR: Sending INARP Reply on interface Serial0/0 dlci 501 for link 7(IP)
 R5#
 *Mar 1 03:10:02.023: Serial0/0(o): dlci 502(0x7C61), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34

 

Ez azt jelenti, hogy a két router tud egymásról Layer2-ben. Ha megnézzük:

 

R5#sh frame map
 Serial0/0 (up): ip 155.1.0.1 dlci 501(0x1F5,0x7C50), dynamic,
 broadcast,, status defined, active
 R5#

 

Tehát mennie kell a pingnek is. Bekapcsolom a debug ip packetet.

 

R5#debug ip packet
 IP packet debugging is on
 R5#ping 155.1.0.1 repe 1
 Type escape sequence to abort.
 Sending 1, 100-byte ICMP Echos to 155.1.0.1, timeout is 2 seconds:
 !
 Success rate is 100 percent (1/1), round-trip min/avg/max = 52/52/52 ms
 R5#
 *Mar 1 03:12:37.087: IP: tableid=0, s=155.1.0.5 (local), d=155.1.0.1 (Serial0/0), routed via FIB
 *Mar 1 03:12:37.091: IP: s=155.1.0.5 (local), d=155.1.0.1 (Serial0/0), len 100, sending
 *Mar 1 03:12:37.131: IP: tableid=0, s=155.1.0.1 (Serial0/0), d=155.1.0.5 (Serial0/0), routed via RIB
 *Mar 1 03:12:37.135: IP: s=155.1.0.1 (Serial0/0), d=155.1.0.5 (Serial0/0), len 100, rcvd 3
 R5#

 

Sikeres. Nézzük át, mit tudunk a multipoint interface-ről:
– InARP alapból engedélyezve van
– Minden DLCI ehhez az interface-hez tartozik.

2. Multipoint subinterface

– InARP alapértelmezetten engedélyezve van. Meg kell adnunk, mely DLCI-k tartoznak az interface-hez (a többi DLCI a fizikaihoz fog tartozni) a frame-relay interface-dlci parancs használatával.

R5-t átkonfigurálom úgy, hogy az 501-es DLCI egy multipoint subinterface-hez tartozzon.

 

!
 interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 !
 interface Serial0/0.501 multipoint
 ip address 155.1.0.5 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 501
 !

 

A debug-ból láthatjuk, hogy R5 a multipoint subinterface-n továbbra is küld InARP REQ-t. De csak az 501-n, mert ezt konfiguráltam az interfacve-hez! A többihez nem küldünk, mert a fő interface-n nincs IP, így azon nem tud futni az InARP.

 

R5#debug frame packet
 Frame Relay packet debugging is on
 R5#
 *Mar 1 03:19:12.907: Serial0/0.501(o): dlci 501(0x7C51), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
 *Mar 1 03:19:12.911: FR: Sending INARP Request on interface Serial0/0.501 dlci 501 for link 7(IP)

 

Map:

 

R5#sh frame map
 Serial0/0.501 (up): ip 155.1.0.1 dlci 501(0x1F5,0x7C50), dynamic,
 broadcast,, status defined, active
 R5#

 

Gyakorlatilag semmi nem változott. Működik a kommunikáció:

 

R5#ping 155.1.0.1
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 155.1.0.1, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 4/43/80 ms
 R5#

 

Ha a FRSW-től sok olyan DLCI-t kapunk, amelyre nincs szükségünk, a legjobb, ha csinálunk egy multipoint subinterface-t IP nélkül, és ahhoz társítjuk őket. Miért IP nélkül? Mert az InARP csak protokoll-dlci párosra fut. Ha nincs IP, nincs InARP! Ez fontos! Később megmutatom.
Multipoint subinterface alatt használhatnánk a frame-relay map ip 155.1.0.1 501 parancsot is, és működne! A rutinosak most felkapják a fejüket: a frame-relay map parancs kikapcsolja az InARP-t! Hogy működne? Kikapcsolja, de csak a küldést. Ha az interface-n kap egy InARP REQ-t a router, válaszol. A választ NEM LEHET KIKAPCSOLNI! Nem hiszitek? Mutatom:

 

R5:
 !
 interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 !
 interface Serial0/0.501 multipoint
 ip address 155.1.0.5 255.255.255.0
 snmp trap link-status
 frame-relay map ip 155.1.0.1 501 broadcast
 frame-relay interface-dlci 501
 !

 

A STATIC azt jelenti, hogy kézzel konfiguráltuk:

 

R5#sh frame-relay map
 Serial0/0.501 (up): ip 155.1.0.1 dlci 501(0x1F5,0x7C50), static,
 broadcast,
 CISCO, status defined, active
 R5#

 

Lenyomom R1 interface-t, hogy InARP szinkronizációt kényszerítsek ki. Közben debugot nézek R5-n.

 

R5#
 R5#debug frame-relay pack
 Frame Relay packet debugging is on
 R5#
 R5#
 R5#sh clock
 *03:32:30.307 UTC Fri Mar 1 2002
 R5#
 R5#
 R5#
 R5#sh clock
 *03:34:11.007 UTC Fri Mar 1 2002
 R5#

 

Ennyi idő alatt már küldenie kellett volna InARP REQ-t R5-nek, tehát kijelenthetjük, hogy multipoint interface-n a frame-relay map parancs kikapcsolja az InARP küldést.
Ha felengedem R1 S0/0 interface-t, nézzük mi történik R5-n:

 

R5#sh clock
 *03:34:11.007 UTC Fri Mar 1 2002
 R5#
 *Mar 1 03:35:16.971: Serial0/0(i): dlci 501(0x7C51), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
 *Mar 1 03:35:16.979: Serial0/0.501: frame relay INARP received
  *Mar 1 03:35:16.979: FR: Sending INARP Reply on interface Serial0/0.501 dlci 501 for link 7(IP)
 R5#

 

Látjátok? INARP Received, sending reply! A választ nem lehet kikapcsolni!

 

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

 

Persze ha R1-n is frame-relay map parancsot használnék, akkor nem működne az InARP. Miért? Mert akkor nem küldene R1 InARP REQ-t, R5 nem válaszolna.
A kommunikáció persze működne, mert mindkét router tudná, melyik IP melyik DLCI-hez tartozik (hiszen megadtuk kézzel).
A broadcast parancs a végén azt jelenti, hogy támogatjuk a broadcast-ot. Valójában NBMA hálózatokban nincs broadcast. A Frame-Relay úgy oldja meg ezt, hogy minden olyan DLCI-re, amely tartalmazza a “broadcast” parancsot, kirakja a keretet [ún “pseudo-broadcast”]. Tehát ha sok mappinged van amelyben ott van a “broadcast” kulccsszó, minden PVC-re kilöki a keretet. Ja igen, erről jut eszembe: a multipoint interface alapjából engedi a broadcast-ot. Mindig nézzétek meg a show frame-relay map parancsot, ha kétségetek van. Ha ott írja, hogy broadcast, akkor megengedett a broadcast.

 

155.1.0.1 dlci 501(0x1F5,0x7C50), static,
 broadcast,
 CISCO, status defined, active

 

3. Point-to-point subinterface

– InARP letiltva alapból. Miért? Mert egy subinterface-hez csak 1 DLCI tartozhat. Logikus: ha nem én vagyok a cél, a másik oldal az. Nézzük meg R2-n a konfigurációját.

 

R2:
 !
 interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 !
 interface Serial0/0.205 point-to-point
 ip address 155.1.0.2 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 205
 !

 

R5-n hozzá kell adnom az 502-s DLCI-t a multipoint subinterface-hez.

 

R5#sh run interface Serial0/0.501
 Building configuration...
 Current configuration : 165 bytes
 !
 interface Serial0/0.501 multipoint
 ip address 155.1.0.5 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 501
 frame-relay interface-dlci 502
 end

 

Működik a kommunikáció?

 

R2#ping 155.1.0.5 repe 1
 Type escape sequence to abort.
 Sending 1, 100-byte ICMP Echos to 155.1.0.5, timeout is 2 seconds:
 !
 Success rate is 100 percent (1/1), round-trip min/avg/max = 40/40/40 ms
 R2#

 

Igen!
Küld R2 InARP requesteket? Nem! Még akkor sem, ha interface-dlci-t konfiguráltam, nem frame-relay map-t.Kap R5-től? Igen! Miért? Mert frame-relay interface-dlci-vel konfiguráltam R5-n a MULTIpoint interface-t! Nézzük mi van, ha mappingra váltok. R1-t kikapcsoltam közben, így nem is mapoltam ide.

 

R5#sh run int Serial0/0.501
 Building configuration...
 !
 Current configuration : 135 bytes
 !
 interface Serial0/0.501 multipoint
 ip address 155.1.0.5 255.255.255.0
 snmp trap link-status
 frame-relay map ip 155.1.0.2 502
 end

 

Ping:

 

R5#ping 155.1.0.2 repe 1
 Type escape sequence to abort.
 Sending 1, 100-byte ICMP Echos to 155.1.0.2, timeout is 2 seconds:
 !
 Success rate is 100 percent (1/1), round-trip min/avg/max = 80/80/80 ms

 

4. Hogyan engedélyezzük csak a kívánt DLCI-kre az InARP-t?

Csináljunk egy multipoint interface-t IP nélkül, és társítsuk hozzá a DLCI-ket. A fő interface alatt csak azokat a DLCI-ket hagyjuk, amelyekre akarunk InARP-zni.

 

R5(config)#int s0/0
 R5(config-if)#encap frame
 R5(config-if)#ip add 155.1.0.5 255.255.255.0
 R5(config-if)#^Z
R5#sh frame-relay map
 Serial0/0 (up): ip 155.1.0.2 dlci 502(0x1F6,0x7C60), dynamic,
 broadcast,, status defined, active
 R5#

 

De ezek a PVC-k vannak ide konfigurálva a FRSW által:

 

R5#sh frame-relay PVC | i DLCI
 DLCI = 501, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 DLCI = 502, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 DLCI = 503, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 DLCI = 504, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 DLCI = 513, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
 R5#
 

 

Mondjuk ha 501-re és 504-re nem akarok InARP-t küldeni….

 

R5(config)#int s0/0.666 mult
 R5(config-subif)#frame-relay inter
 R5(config-subif)#frame-relay interface-dlci 501
 R5(config-fr-dlci)#frame-relay interface-dlci 504
 R5(config-fr-dlci)#^Z
 R5#

 

R4 konfigurációja….

 

R4(config)#int s0/0
 R4(config-if)#encap frame
 R4(config-if)#ip add 155.1.0.4 255.255.255.0
 R4(config-if)#do debug frame packet
 Frame Relay packet debugging is on
 R4(config-if)#no shut
 R4(config-if)#^Z
 R4#

 

Küldi is szegény az InARP-t (mindegyik DLCI-n!)…

 

R4#
 *Mar 1 04:02:10.926: Serial0/0(o): dlci 401(0x6411), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
 *Mar 1 04:02:10.930: FR: Sending INARP Request on interface Serial0/0 dlci 401 for link 7(IP)
 *Mar 1 04:02:10.930: Serial0/0(o): dlci 402(0x6421), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
 *Mar 1 04:02:10.934: FR: Sending INARP Request on interface Serial0/0 dlci 402 for link 7(IP)
 *Mar 1 04:02:10.938: Serial0/0(o): dlci 403(0x6431), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
 *Mar 1 04:02:10.942: FR: Sending INARP Request on interface Serial0/0 dlci 403 for link 7(IP)
 *Mar 1 04:02:10.942: Serial0/0(o): dlci 405(0x6451), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
 *Mar 1 04:02:10.946: FR: Sending INARP Request on interface Serial0/0 dlci 405 for link 7(IP)
 *Mar 1 04:02:10.950: Serial0/0(o): dlci 413(0x64D1), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
 *Mar 1 04:02:10.954: FR: Sending INARP Request on interface Serial0/0 dlci 413 for link 7(IP)
 *Mar 1 04:02:10.958: broadcast dequeue
 *Mar 1 04:02:10.958: Serial0/0(o):Pkt sent on dlci 401(0x6411), pkt encaps 0x300 0x8000 0x0 0x806 (ARP), datagramsize 34

 

De R5 nem válaszol, mert csak akkor van InARP küldés, ha protokol-dlci együtt van konfigurálva. Mivel a subinterface-n nincs IP konfigurálva, nem méltatjuk válaszra R4-t…

 

*Mar 1 04:02:09.582: Serial0/0.666: frame relay INARP received
 R5#

 

Remélem hasznos volt mindenkinek!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.