Guida completa alla configurazione e alla risoluzione dei problemi di Frame Relay

Introduzione

Frame Relay è un protocollo di commutazione standard del settore, a livello di collegamento dati, che gestisce più circuiti virtuali utilizzando l'incapsulamento HDLC (High-Level Data Link) tra i dispositivi collegati. In molti casi, Frame Relay è più efficiente di X.25, il protocollo di cui è generalmente considerato il sostituto. Nella figura seguente viene mostrato un frame di Frame Relay (ANSI T1.618).

Nella figura precedente, gli indirizzi Q.922, come attualmente definiti, sono due ottetti e contengono un identificatore DLCI (Data-Link Connection Identifier) a 10 bit. In alcune reti gli indirizzi Q.922 possono essere facoltativamente aumentati a tre o quattro ottetti.

I campi "flag" delimitano l'inizio e la fine del frame. Seguendo il campo "flag" iniziale ci sono due byte di informazioni sull'indirizzo. Dieci bit di questi due byte costituiscono l'ID del circuito effettivo (detto DLCI, identificativo della connessione dati).

Il valore DLCI a 10 bit è il cuore dell'intestazione Frame Relay. Identifica la connessione logica che viene multiplex nel canale fisico. Nella modalità di indirizzamento di base, ovvero non estesa dalla modalità LMI (Local Management Interface), le DLCI hanno un significato locale, ovvero i dispositivi terminali su due estremità diverse di una connessione possono utilizzare un DLCI diverso per fare riferimento alla stessa connessione.

Operazioni preliminari

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Prerequisiti

Per ulteriori informazioni e definizioni dei termini utilizzati nel presente documento, consultare il glossario Frame Relay.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Nozioni di base

Frame Relay è stato originariamente concepito come protocollo da utilizzare sulle interfacce ISDN. Le prime proposte in tal senso sono state presentate nel 1984 al settore della normalizzazione delle telecomunicazioni dell'Unione internazionale delle telecomunicazioni (UIT-T) (ex Comitato consultivo per il telegrafo e il telefono internazionali, CCITT). Il lavoro su Frame Relay è stato intrapreso anche dal comitato per gli standard T1S1 accreditato ANSI negli Stati Uniti.

Nel 1990, Cisco Systems, StrataCom, Northern Telecom e Digital Equipment Corporation hanno costituito un consorzio per focalizzare lo sviluppo della tecnologia Frame Relay e accelerare l'introduzione di prodotti Frame Relay interoperabili. Hanno sviluppato una specifica conforme al protocollo Frame Relay di base in discussione in T1S1 e ITU-T, ma l'hanno estesa con caratteristiche che forniscono funzionalità aggiuntive per ambienti di internetworking complessi. Queste estensioni Frame Relay sono chiamate collettivamente LMI. Questa è l'LMI "cisco" del router, in contrapposizione all'LMI "ansi" o "q933a".

Frame Relay fornisce una funzionalità di comunicazione dei dati a commutazione di pacchetto utilizzata nell'interfaccia tra dispositivi utente (ad esempio router, bridge, macchine host) e apparecchiature di rete (ad esempio nodi di commutazione). I dispositivi utente sono spesso denominati DTE (Data Terminal Equipment), mentre le apparecchiature di rete che si interfacciano con DTE sono spesso denominate DCE (Data Circuit-Terminating Equipment). La rete che fornisce l'interfaccia Frame Relay può essere una rete pubblica fornita dal vettore o una rete di apparecchiature private che servono una singola azienda.

Frame Relay differisce notevolmente da X.25 per quanto riguarda le funzionalità e il formato. In particolare, Frame Relay è un protocollo più snello, che facilita prestazioni più elevate e una maggiore efficienza.

Come interfaccia tra utente e apparecchiature di rete, Frame Relay fornisce un mezzo per multiplexare statisticamente molte conversazioni di dati logici (chiamate circuiti virtuali) su un singolo collegamento di trasmissione fisico. A differenza dei sistemi che utilizzano solo tecniche TDM (Time-Division-Multiplexing) per il supporto di più flussi di dati. Il multiplexing statistico di Frame Relay fornisce un uso più flessibile ed efficiente della larghezza di banda disponibile. Può essere utilizzato senza tecniche TDM o su canali forniti da sistemi TDM.

Un'altra caratteristica importante del Frame Relay è che sfrutta i recenti progressi della tecnologia di trasmissione WAN (Wide-Area Network). I protocolli WAN precedenti, come X.25, sono stati sviluppati quando predominavano i sistemi di trasmissione analogici e i supporti in rame. Questi collegamenti sono molto meno affidabili rispetto ai collegamenti di trasmissione in fibra/digitale attualmente disponibili. Su collegamenti come questi, i protocolli a livello di collegamento possono rinunciare agli algoritmi di correzione degli errori, che richiedono molto tempo, e lasciare che vengano eseguiti a livelli di protocollo più elevati. Prestazioni ed efficienza maggiori sono quindi possibili senza compromettere l'integrità dei dati. Frame Relay è stato progettato tenendo presente questo approccio. Include un algoritmo CRC (Cyclic Redundancy Check) per il rilevamento dei bit danneggiati (in modo che i dati possano essere eliminati), ma non include alcun meccanismo di protocollo per la correzione dei dati danneggiati (ad esempio, ritrasmettendoli a questo livello di protocollo).

Un'altra differenza tra Frame Relay e X.25 è l'assenza di controllo del flusso esplicito per circuito virtuale in Frame Relay. Ora che molti protocolli di livello superiore stanno eseguendo in modo efficace i propri algoritmi di controllo del flusso, la necessità di questa funzionalità a livello di collegamento è diminuita. Frame Relay, pertanto, non include procedure di controllo del flusso esplicite che duplicano quelle nei livelli superiori. Al contrario, sono forniti meccanismi molto semplici di notifica della congestione per consentire a una rete di informare un dispositivo utente che le risorse di rete sono vicine a uno stato di congestione. Questa notifica può avvisare i protocolli di livello superiore che potrebbe essere necessario il controllo del flusso.

Configurazione di Frame Relay di base

Dopo aver ottenuto connessioni affidabili allo switch Frame Relay locale a entrambe le estremità del circuito virtuale permanente (PVC), è possibile iniziare a pianificare la configurazione di Frame Relay. Nel primo esempio, per impostazione predefinita, il tipo di interfaccia di gestione locale (LMI) è "cisco" LMI su Spicey. Un'interfaccia è per impostazione predefinita un'interfaccia "multipunto", quindi il frame-relay inverse-arp è attivo (per il point-to-point, non è presente il reverse ARP). Per impostazione predefinita, il controllo IP split-horizon è disabilitato per l'incapsulamento Frame Relay, quindi gli aggiornamenti del routing entrano ed escono dalla stessa interfaccia. I router ricevono informazioni sugli identificatori di connessione (DLCI) che devono utilizzare dallo switch Frame Relay tramite gli aggiornamenti LMI. I router quindi invertono il protocollo ARP per l'indirizzo IP remoto e creano una mappatura degli elementi DLCI locali e dei relativi indirizzi IP remoti associati.

Esempio di rete

Configurazioni

• Spicey

• Prasit

Spicey#show running-config
Building configuration...

Current configuration : 1705 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Spicey
!
!
!
interface Ethernet0
 ip address 124.124.124.1 255.255.255.0
!
interface Serial0
 ip address 3.1.3.1 255.255.255.0
 encapsulation frame-relay
 frame-relay interface-dlci 140
!
!
router rip
 network 3.0.0.0
 network 124.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Prasit#show running-config
Building configuration...
Current configuration : 1499 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Prasit
!
!
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
!
interface Serial1
 ip address 3.1.3.2 255.255.255.0
 encapsulation frame-relay
 frame-relay interface-dlci 150
!
!
router rip
 network 3.0.0.0
 network 123.0.0.0
!
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Comandi debug e show

Prima di usare i comandi di debug, consultare le informazioni importanti sui comandi di debug.

• mostra mappa frame relay

• show frame-relay pvc

• show frame-relay lmi

• ping <nome dispositivo>

• show ip route

Spicey

Spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
              broadcast,, status defined, active

Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
  input pkts 83            output pkts 87           in bytes 8144      
  out bytes 8408           dropped pkts 0           in FECN pkts0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 41         out bcast bytes 3652      
  pvc create time 01:31:50, last time pvc status changed 01:28:28
Spicey#show frame-relay lmi
LMI Statistics for interface Serial0 (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 550              Num Status msgs Rcvd 552
  Num Update Status Rcvd 0              Num Status Timeouts 0
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route
 
Gateway of last resort is not set
     3.0.0.0/24 is subnetted, 1 subnets
C       3.1.3.0 is directly connected, Serial0
     124.0.0.0/24 is subnetted, 1 subnets
C       124.124.124.0 is directly connected, Ethernet0
R    123.0.0.0/8 [120/1] via 3.1.3.2, 00:00:08, Serial0

Prasit

Prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
              broadcast,, status defined, active

Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
  input pkts 87            output pkts 83           in bytes 8408      
  out bytes 8144           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 38         out bcast bytes 3464      
  pvc create time 01:34:29, last time pvc status changed 01:28:05

Prasit#show frame-relay lmi
LMI Statistics for interface Serial1 (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 569              Num Status msgs Rcvd 570
  Num Update Status Rcvd 0              Num Status Timeouts 0

Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route
Gateway of last resort is not set
     3.0.0.0/24 is subnetted, 1 subnets
C       3.1.3.0 is directly connected, Serial1
R    124.0.0.0/8 [120/1] via 3.1.3.1, 00:00:19, Serial1
     123.0.0.0/24 is subnetted, 1 subnets
C       123.123.123.0 is directly connected, Ethernet0

Configurazione di Hub e Spoke Frame Relay

Nell'esempio, il router apprende quali identificatori di connessione del collegamento dati (DLCI) utilizza dallo switch Frame Relay e li assegna all'interfaccia principale. Quindi, il router inverte il protocollo ARP per l'indirizzo IP remoto.

Nota: non sarà possibile eseguire il ping dell'indirizzo IP seriale di Prasit da Aton a meno che non si aggiungano esplicitamente mappe Frame Relay su ciascuna estremità. Se il routing è configurato correttamente, il traffico proveniente dalle LAN non dovrebbe presentare problemi. Per eseguire il ping, è possibile usare l'indirizzo IP Ethernet come indirizzo di origine in un ping esteso.

Quando l'opzione frame-relay inverse-arp è abilitata, il traffico IP di trasmissione si interrompe sulla connessione per impostazione predefinita.

Esempio di rete

Configurazioni

• Spicey

• Prasit

• Aton

spicey#show running-config
Building configuration...
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname spicey
!
!
!
!
interface Ethernet0
 ip address 124.124.124.1 255.255.255.0
!
interface Serial0
 ip address 3.1.3.1 255.255.255.0
 encapsulation frame-relay
 frame-relay interface-dlci 130
 frame-relay interface-dlci 140
!
!
router rip
 network 3.0.0.0
 network 124.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

prasit#show running-config
Building configuration...

Current configuration : 1499 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname prasit
!
!
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
interface Serial1
 ip address 3.1.3.2 255.255.255.0
 encapsulation frame-relay
 frame-relay interface-dlci 150
!
!
router rip
 network 3.0.0.0
 network 123.0.0.0
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

aton#show running-config
Building configuration...
Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname aton
!
!
interface Ethernet0
ip address 122.122.122.1 255.255.255.0
!
interface Serial1
 ip address 3.1.3.3 255.255.255.0
 encapsulation frame-relay
 frame-relay interface-dlci 160
!
router rip
 network 3.0.0.0
 network 122.0.0.0
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Comandi show

• mostra mappa frame relay

• show frame-relay pvc

• ping <nome dispositivo>

Spicey

spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
              broadcast,, status defined, active
Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,
              broadcast,, status defined, active

spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
  input pkts 32            output pkts 40           in bytes 3370      
  out bytes 3928           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 30         out bcast bytes 2888      
  pvc create time 00:15:46, last time pvc status changed 00:10:42

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

  input pkts 282           output pkts 291          in bytes 25070     
  out bytes 27876          dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 223        out bcast bytes 20884     
  pvc create time 02:28:36, last time pvc status changed 02:25:14
spicey#
spicey#ping 3.1.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
spicey#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

Prasit

prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
              broadcast,, status defined, active

prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
  input pkts 311           output pkts 233          in bytes 28562     
  out bytes 22648          dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 162        out bcast bytes 15748     
  pvc create time 02:31:39, last time pvc status changed 02:25:14

prasit#ping 3.1.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
prasit#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Aton

aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
              broadcast,, status defined, active

aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1

  input pkts 35            output pkts 32           in bytes 3758      
  out bytes 3366           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 27         out bcast bytes 2846      
  pvc create time 00:10:53, last time pvc status changed 00:10:53

aton#ping 3.1.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

aton#ping 3.1.3.2

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

Connessione da spoke a spoke

Non è possibile eseguire il ping da uno spoke a un altro spoke in una configurazione hub e spoke utilizzando interfacce multipunto perché non esiste alcun mapping per gli indirizzi IP degli altri spoke. Solo l'indirizzo dell'hub viene appreso tramite il protocollo IARP (Inverse Address Resolution Protocol). Se si configura una mappa statica utilizzando il comando frame-relay map per l'indirizzo IP di un spoke remoto per utilizzare l'identificatore DLCI (Data Link Connection Identifier) locale, è possibile eseguire il ping degli indirizzi di altri spoke.

Configurazioni

prasit#show running-config
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
interface Serial
 ip address 3.1.3.2 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 3.1.3.3 150
 frame-relay interface-dlci 150

Comandi show

• mostra mappa frame relay

• ping <nome dispositivo>

• show running-config

Prasit

prasit#show frame-relay map
 Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
                    broadcast,, status defined, active
 Serial1 (up): ip 3.1.3.3 dlci 150(0x96,0x2460), static,
                    CISCO, status defined, active
   
 prasit#ping 3.1.3.3
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/80 ms
   
 prasit#ping 122.122.122.1 
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/76 ms 

Aton

aton#show running-config
 interface Ethernet0
 ip address 122.122.122.1 255.255.255.0
 !
 interface Serial1
   ip address 3.1.3.3 255.255.255.0
   no ip directed-broadcast
   encapsulation frame-relay
   frame-relay map ip 3.1.3.2 160
   frame-relay interface-dlci 160
   
 aton#show frame-relay map
 Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
                    broadcast,, status defined, active
 Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,
                    CISCO, status defined, active
 aton#ping 3.1.3.2
   
 Type escape sequence to abort
 Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
 
aton#ping 123.123.123.1   
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/80 ms

Configurazione delle sottointerfacce Frame Relay

Le sottointerfacce Frame Relay forniscono un meccanismo per supportare le reti Frame Relay parzialmente mesh. La maggior parte dei protocolli presuppone la transitività su una rete logica, ovvero se la stazione A può comunicare con la stazione B e la stazione B può comunicare con la stazione C, la stazione A deve essere in grado di comunicare direttamente con la stazione C. La transitività è vera sulle LAN, ma non sulle reti Frame Relay a meno che A non sia collegato direttamente a C.

Inoltre, alcuni protocolli, come AppleTalk e il bridging trasparente, non possono essere supportati sulle reti parzialmente mesh perché richiedono lo "split-horizon", in cui un pacchetto ricevuto su un'interfaccia non può essere trasmesso sulla stessa interfaccia anche se il pacchetto viene ricevuto e trasmesso su circuiti virtuali diversi.

La configurazione delle sottointerfacce Frame Relay garantisce che una singola interfaccia fisica venga considerata come più interfacce virtuali. Questa funzionalità consente di superare le regole della divisione degli orizzonti. I pacchetti ricevuti su un'interfaccia virtuale possono ora essere inoltrati su un'altra interfaccia virtuale, anche se sono configurati sulla stessa interfaccia fisica.

Le sottointerfacce eliminano i limiti delle reti Frame Relay consentendo di suddividere una rete Frame Relay con mesh parziale in una serie di sottoreti più piccole, a mesh completa (o point-to-point). A ogni sottorete viene assegnato un numero di rete specifico e i protocolli vengono visualizzati come raggiungibili tramite un'interfaccia separata. Si noti che le sottointerfacce point-to-point possono essere senza numero per l'utilizzo con l'IP, riducendo il carico di lavoro che potrebbe derivare dall'indirizzamento.

Sottointerfacce point-to-point

Esempio di rete

Configurazioni

• Spicey

• Prasit

Spicey#show running-config
Building configuration...
   
Current configuration : 1338 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Spicey
!
enable password ww
!
!
!
!
interface Ethernet0
 ip address 124.124.124.1 255.255.255.0
!
interface Serial0
 no ip address
 encapsulation frame-relay
!
interface Serial0.1 point-to-point
 ip address 3.1.3.1 255.255.255.0
 frame-relay interface-dlci 140   
!
!
router igrp 2
 network 3.0.0.0
 network 124.0.0.0
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Prasit#show running-config
Building configuration...
   
Current configuration : 1234 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Prasit
!
!
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
 interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 point-to-point
 ip address 3.1.3.2 255.255.255.0
 frame-relay interface-dlci 150   
!
router igrp 2
 network 3.0.0.0
 network 123.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Comandi show

• mostra mappa frame relay

• show frame-relay pvc

Spicey

Spicey#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
             status defined, active
 
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
   
                 Active     Inactive      Deleted          Static
  Local          1               0            0               0
  Switched       0               0            0               0
  Unused         0               0            0               0
   
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
   
  input pkts 193              output pkts 175          in bytes 20450     
  out bytes 16340             dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0              out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0                out DE pkts 0         
  out bcast pkts 50         out    bcast bytes 3786      
  pvc create time 01:11:27, last time pvc status changed 00:42:32
   
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Prasit

Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
             status defined, active
   
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
   
                Active     Inactive      Deleted          Static
 Local          1               0            0               0
 Switched       0               0            0               0
 Unused         0               0            0               0
   
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
   
     input pkts 74               output pkts 89           in    bytes 7210      
     out bytes 10963             dropped pkts 0           in    FECN pkts 0         
     in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0         
     in DE pkts 0                out DE pkts 0         
     out bcast pkts 24           out bcast bytes 4203      
     pvc create time 00:12:25, last time pvc status changed 00:12:25
   
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Sottointerfacce hub e spoke

Nella configurazione di esempio di hub e spoke seguente vengono illustrate due sottointerfacce point-to-point e viene utilizzata la risoluzione degli indirizzi dinamici in un sito remoto. Ogni sottointerfaccia è dotata di un indirizzo di protocollo e di una subnet mask individuali e il comando interface-dlci associa la sottointerfaccia a un identificatore di connessione (DLCI) dati specificato. Gli indirizzi delle destinazioni remote per ogni sottointerfaccia point-to-point non vengono risolti perché sono point-to-point e il traffico deve essere inviato al peer all'altra estremità. L'estremità remota (Aton) utilizza l'ARP inverso per la mappatura e l'hub principale risponde di conseguenza con l'indirizzo IP della sottointerfaccia. Questo si verifica perché Frame Relay Inverse ARP è attivo per impostazione predefinita per le interfacce multipunto.

Esempio di rete

Configurazioni

• Spicey

• Prasit

• Aton

Spicey#show running-config
Building configuration...
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Spicey
!
!
!
!
interface Ethernet0
 ip address 124.124.124.1 255.255.255.0
!
interface Serial0
 no ip address
 encapsulation frame-relay
!
interface Serial0.1 point-to-point
 ip address 4.0.1.1 255.255.255.0
 frame-relay interface-dlci 140   
!
interface Serial0.2 point-to-point
 ip address 3.1.3.1 255.255.255.0
 frame-relay interface-dlci 130   
!
router igrp 2
 network 3.0.0.0
 network 4.0.0.0
 network 124.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Prasit#show running-config
Building configuration...

version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Prasit
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 point-to-point
 ip address 4.0.1.2 255.255.255.0
 frame-relay interface-dlci 150   
!
router igrp 2
 network 4.0.0.0
 network 123.0.0.0
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Aton#show running-config
Building configuration...

Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
!
hostname Aton
!
!
!
interface Ethernet0
 ip address 122.122.122.1 255.255.255.0
!
interface Serial1
 ip address 3.1.3.3 255.255.255.0
 encapsulation frame-relay
 frame-relay interface-dlci 160
!
router igrp 2
 network 3.0.0.0
 network 122.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Comandi show

• mostra mappa frame relay

• show frame-relay pvc

Spicey

Spicey#show frame-relay map
Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
          status defined, active
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
          status defined, active

Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.2

  input pkts 11            output pkts 22           in bytes 1080      
  out bytes 5128           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 17         out bcast bytes 4608      
  pvc create time 00:06:36, last time pvc status changed 00:06:36

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

  input pkts 33            output pkts 28           in bytes 3967      
  out bytes 5445           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 17        out bcast bytes 4608      
  pvc create time 00:06:38, last time pvc status changed 00:06:38

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

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

Prasit

Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
          status defined, active

Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1

  input pkts 45            output pkts 48           in bytes 8632      
  out bytes 6661           dropped pkts 0           in FECN pkts 0        
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 31         out bcast bytes 5573      
  pvc create time 00:12:16, last time pvc status changed 00:06:23

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

Aton

Aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
              broadcast,, status defined, active

Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
  input pkts 699           output pkts 634          in bytes 81290     
  out bytes 67008          dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 528        out bcast bytes 56074     
  pvc create time 05:46:14, last time pvc status changed 00:05:57

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

Configurazione del mapping dinamico e statico per le sottointerfacce multipunto

Il mapping degli indirizzi dinamici utilizza il protocollo ARP inverso Frame Relay per richiedere l'indirizzo di protocollo dell'hop successivo per una connessione specifica, in base a un identificatore di connessione del collegamento dati (DLCI). Le risposte alle richieste ARP inverse vengono immesse in una tabella di mapping da indirizzo a DLCI sul router o sul server di accesso; la tabella viene quindi utilizzata per fornire l'indirizzo di protocollo dell'hop successivo o il DLCI per il traffico in uscita.

Poiché l'interfaccia fisica è ora configurata come più sottointerfacce, è necessario fornire informazioni che distinguano una sottointerfaccia dall'interfaccia fisica e associino una sottointerfaccia specifica a un DLCI specifico.

Il protocollo ARP inverso è abilitato per impostazione predefinita per tutti i protocolli supportati, ma può essere disabilitato per coppie protocollo-DLCI specifiche. Di conseguenza, è possibile utilizzare il mapping dinamico per alcuni protocolli e il mapping statico per altri protocolli dello stesso DLCI. È possibile disabilitare in modo esplicito l'ARP inverso per una coppia protocollo-DLCI se si è certi che il protocollo non è supportato sull'altra estremità della connessione. Poiché il protocollo ARP inverso è abilitato per impostazione predefinita per tutti i protocolli supportati, non è necessario alcun comando aggiuntivo per configurare il mapping degli indirizzi dinamici su una sottointerfaccia. Una mappa statica collega un indirizzo di protocollo dell'hop successivo specificato a un DLCI specificato. Il mapping statico elimina la necessità di richieste ARP inverse. Quando si fornisce una mappa statica, la funzione ARP inverso viene disabilitata automaticamente per il protocollo specificato nel DLCI specificato. È necessario utilizzare la mappatura statica se il router sull'altra estremità non supporta affatto l'ARP inverso o non supporta l'ARP inverso per un protocollo specifico che si desidera utilizzare su Frame Relay.

Esempio di rete

Abbiamo già visto come configurare un router Cisco per eseguire l'ARP inverso. Nell'esempio seguente viene illustrato come configurare le mappe statiche nel caso in cui siano necessarie per interfacce multipunto o sottointerfacce:

Configurazioni

• Aton

• Spicey

• Prasit

Aton#show running-config
Building configuration...
Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Aton
!
!
interface Ethernet0
 ip address 122.122.122.1 255.255.255.0
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 multipoint
 ip address 4.0.1.3 255.255.255.0
 frame-relay map ip 4.0.1.1 160 broadcast
!
router igrp 2
 network 4.0.0.0
 network 122.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Spicey#show running-config
Building configuration...Current configuration : 1652 bytes!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Spicey
!
!
interface Ethernet0 
ip address 124.124.124.1 255.255.255.0
!
interface Serial0 
ip address 4.0.1.1 255.255.255.0 
encapsulation frame-relay 
frame-relay map ip 4.0.1.2 140 broadcast 
frame-relay map ip 4.0.1.3 130 broadcast
!
router igrp 2 
network 4.0.0.0 
network 124.0.0.0
!
!
line con 0 
exec-timeout 0 0 
transport input none
line aux 0
line vty 0 4 
login
!
end

Prasit#show running-config
Building configuration...
Current configuration : 1162 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Prasit
!
!
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 multipoint
 ip address 4.0.1.2 255.255.255.0
 frame-relay map ip 4.0.1.1 150 broadcast
!
router igrp 2
 network 4.0.0.0
 network 123.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Comandi debug e show

• mostra mappa frame relay

• show frame-relay pvc

Aton

Aton#show frame-relay map
Serial1.1 (up): ip 4.0.1.1 dlci 160(0xA0,0x2800), static, broadcast,
CISCO, status defined, active

Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1

  input pkts 16            output pkts 9            in bytes 3342      
  out bytes 450            dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 9          out bcast bytes 450       
  pvc create time 00:10:02, last time pvc status changed 00:10:02

Aton#ping 124.124.124.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

Spicey

Spicey#show frame-relay map
Serial0 (up): ip 4.0.1.2 dlci 140(0x8C,0x20C0), static, broadcast,
              CISCO, status defined, active
Serial0 (up): ip 4.0.1.3 dlci 130(0x82,0x2020), static, broadcast,
              CISCO, status defined, active

Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

  input pkts 9              output pkts 48           in bytes 434       
  out bytes 11045           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0            out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0              out DE pkts 0         
  out bcast pkts 48         out bcast bytes 11045     
  pvc create time 00:36:25, last time pvc status changed 00:36:15

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

  input pkts 17             output pkts 26           in bytes 1390      
  out bytes 4195            dropped pkts 0           in FECN pkts 0           
  in BECN pkts 0            out FECN pkts 0          out BECN pkts 0           
  in DE pkts 0              out DE pkts 0           
  out bcast pkts 16         out bcast bytes 3155        
pvc create time 00:08:39, last time pvc status changed 00:08:39

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

Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 

Prasit

Prasit#show frame-relay map
Serial1.1 (up): ip 4.0.1.1 dlci 150(0x96,0x2460), static,
              broadcast,
              CISCO, status defined, active

Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1
  input pkts 28            output pkts 19           in bytes 4753      
  out bytes 1490           dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0           
  in DE pkts 0             out DE pkts 0           
  out bcast pkts 9         out bcast bytes 450         
pvc create time 00:11:00, last time pvc status changed 00:11:00

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

Per ulteriori informazioni su questi comandi, vedere Comandi Frame Relay.

Configurazione di IP Unnumber Frame Relay

Se non si dispone dello spazio di indirizzi IP per utilizzare molte sottointerfacce, è possibile utilizzare IP senza numero su ciascuna sottointerfaccia. In questo caso, è necessario utilizzare route statiche o routing dinamico in modo che il traffico venga instradato come di consueto e utilizzare sottointerfacce point-to-point.

Esempio di rete

L'esempio seguente illustra quanto segue:

Configurazioni

• Spicey

• Prasit

Spicey#show running-config
Building configuration...
Current configuration : 1674 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Spicey
!
!
!
interface Ethernet0
 ip address 124.124.124.1 255.255.255.0
!
interface Serial0
 no ip address
 encapsulation frame-relay
!
interface Serial0.1 point-to-point
 ip unnumbered Ethernet0
 frame-relay interface-dlci 140   
!
router igrp 2
 network 124.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Prasit#show running-config
Building configuration...

Current configuration : 1188 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Prasit
!
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 point-to-point
 ip unnumbered Ethernet0
 frame-relay interface-dlci 150   
!
router igrp 2
 network 123.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

Comandi show

• mostra mappa frame relay

• show frame-relay pvc

Spicey

Spicey#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
          status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial0.1

  input pkts 23            output pkts 24           in bytes 3391      
  out bytes 4952           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 14         out bcast bytes 3912      
  pvc create time 00:04:47, last time pvc status changed 00:04:47

Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set
     124.0.0.0/24 is subnetted, 1 subnets
C       124.124.124.0 is directly connected, Ethernet0
     123.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
I       123.0.0.0/8 [100/8576] via 123.123.123.1, 00:01:11, Serial0.1
I       123.123.123.0/32 [100/8576] via 123.123.123.1, 00:01:11,
Serial0.1

Spicey#ping 123.123.123.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Prasit

Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
          status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1

  input pkts 24            output pkts 52           in bytes 4952      
  out bytes 10892          dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 41         out bcast bytes 9788      
  pvc create time 00:10:54, last time pvc status changed 00:03:51

Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set
     124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
I       124.0.0.0/8 [100/8576] via 124.124.124.1, 00:00:18, Serial1.1
I       124.124.124.0/32 [100/8576] via 124.124.124.1, 00:00:18,
Serial1.1
     123.0.0.0/24 is subnetted, 1 subnets
C       123.123.123.0 is directly connected, Ethernet0

Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/120/436 ms

Configurazione del backup Frame Relay

Backup Frame Relay su ISDN

È possibile eseguire il backup di circuiti Frame Relay utilizzando ISDN. Esistono diversi modi per eseguire questa operazione. Il primo, e probabilmente il migliore, è l'utilizzo di route statiche mobili che instradano il traffico a un indirizzo IP BRI (Basic Rate Interface) e utilizzano una metrica di routing appropriata. È inoltre possibile utilizzare un'interfaccia di backup sull'interfaccia principale o su una base DLCI (Per-Data-Link Connection Identifier). Il backup dell'interfaccia principale potrebbe non essere di grande aiuto in quanto si potrebbero perdere i PVC (Permanent Virtual Circuit) senza che l'interfaccia principale si interrompa. Tenere presente che il protocollo viene scambiato con lo switch Frame Relay locale, non con il router remoto.

Configurazioni

• Router 1

• Router 2

ROUTER1#
!
hostname ROUTER1
!
username ROUTER2 password same
 isdn switch-type basic-dms100
!
interface Ethernet 0
 ip address 172.16.15.1 255.255.255.248
!
interface serial 0
 ip address 172.16.24.129 255.255.255.128
 encapsulation FRAME-RELAY
!
interface BRI0
 description Backup ISDN for frame-relay
 ip address 172.16.12.1 255.255.255.128
 encapsulation PPP
 dialer idle-timeout 240
 dialer wait-for-carrier-time 60
 dialer map IP 172.16.12.2 name ROUTER2 broadcast 7086639706
 ppp authentication chap
 dialer-group 1
 isdn spid1 0127280320 2728032
 isdn spid2 0127295120 2729512
!
router igrp 1
 network 172.16.0.0
!
ip route 172.16.15.16 255.255.255.248 172.16.12.2 150  

!--- Floating static route.

!
access-list 101 deny   igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
 dialer-list 1 LIST 101
!

ROUTER2#
!
hostname ROUTER2
!
username ROUTER1 password same
 isdn switch-type basic-dms100
!
interface Ethernet 0
 ip address 172.16.15.17 255.255.255.248
!
interface Serial 0
 ip address 172.16.24.130 255.255.255.128
 encapsulation FRAME-RELAY
!
interface BRI0
 description ISDN backup interface for frame-relay
 ip address 172.16.12.2 255.255.255.128
 encapsulation PPP
 dialer idle-timeout 240
 dialer map IP 172.16.12.1 name ROUTER1 broadcast 
 ppp authentication chap
 pulse-time 1
 dialer-group 1
 isdn spid1 0191933333 4445555
 isdn spid2 0191933334 4445556
!
router igrp 1
 network 172.16.0.0
!
ip route 172.16.15.0 255.255.255.248 172.16.12.1 150  

!--- Floating static route.

!
access-list 101 deny   igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
 access-list 101 permit ip 0.0.0.0 255.255.255.255 162.27.9.0 0.0.0.255
 dialer-list 1 LIST 101
!

Comandi show

Per verificare il corretto funzionamento dell'ISDN, utilizzare i seguenti comandi di debug. Prima di usare i comandi di debug, consultare le informazioni importanti sui comandi di debug.

• debug isdn q931

• debug ppp neg

• debug ppp auth

Provare a effettuare una chiamata ISDN dal lato chiamante al lato centrale senza i comandi di backup. Se l'operazione ha esito positivo, aggiungere i comandi di backup al lato chiamante.

Nota: per verificare il backup, non usare il comando shutdown sull'interfaccia seriale, ma emulare un problema reale della linea seriale estraendo il cavo dalla linea seriale.

Configurazione per backup DCLI

Supponiamo ora che Spicey sia il lato centrale e che Prasit sia il lato che crea connessioni con il lato centrale (Spicey). Accertatevi di aggiungere solo i comandi di backup sul lato che chiama il lato centrale.

Nota: il carico di backup non è supportato sulle sottointerfacce. Poiché non si tiene traccia dei livelli di traffico sulle sottointerfacce, non viene calcolato alcun carico.

Esempio di rete

Configurazioni

• Spicey

• Prasit

Spicey#show running-config
Building configuration...
   
Current configuration : 1438 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Spicey
!
!
username Prasit password 0 cisco
!
!
isdn switch-type basic-net3
!
!
!
interface Ethernet0
 ip address 124.124.124.1 255.255.255.0
!
interface Serial0
 no ip address
 encapsulation frame-relay
!
interface Serial0.1 point-to-point
 ip address 4.0.1.1 255.255.255.0
 frame-relay interface-dlci 140   
!
interface BRI0
 ip address 3.1.6.1 255.255.255.0
 encapsulation ppp
 dialer map ip 3.1.6.2 name Prasit broadcast
 dialer-group 1
 isdn switch-type basic-net3
 no peer default ip address
 no cdp enable
 ppp authentication chap
!
router igrp 2
 network 3.0.0.0
 network 4.0.0.0
 network 124.0.0.0
!
ip classless
 ip route 123.123.123.0 255.255.255.0 3.1.6.2 250
!
access-list 101 deny   igrp any any
 access-list 101 permit ip any any
 dialer-list 1 protocol ip list 101
!
line con 0
 exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

Prasit#show running-config
Building configuration...
   
Current configuration : 1245 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Prasit
!
username Spicey password 0 cisco
!
!
isdn switch-type basic-net3
!
!
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 point-to-point
 backup delay 5 10
 backup interface BRI0
 ip address 4.0.1.2 255.255.255.0
 frame-relay interface-dlci 150   
!
interface BRI0
 ip address 3.1.6.2 255.255.255.0
 encapsulation ppp
 dialer map ip 3.1.6.1 name Spicey broadcast 6106
 dialer-group 1
 isdn switch-type basic-net3
 ppp authentication chap
!
router igrp 2
 network 3.0.0.0
 network 4.0.0.0
 network 123.0.0.0
!
ip route 124.124.124.0 255.255.255.0 3.1.6.1 250
!
access-list 101 deny   igrp any any
 access-list 101 permit ip any any
 dialer-list 1 protocol ip list 101
!
line con 0
 exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

Comandi show

• mostra mappa frame relay

• show ip route

• mostra cronologia isdn

• show isdn status

• show interface bri 0

• mostra isdn attivo

Spicey

Spicey#show frame-relay map
   Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
             status defined, active
   Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
             status defined, active
   
   Spicey#show ip route
   Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
          D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
          N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
          E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
          i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
   inter area
          * - candidate default, U - per-user static route, o - ODR
          P - periodic downloaded static route
   
   Gateway of last resort is not set
   
        3.0.0.0/24 is subnetted, 2 subnets C       
        3.1.3.0 is directly connected, Serial0.2 C       
        3.1.6.0 is directly connected, BRI0
        4.0.0.0/24 is subnetted, 1 subnets C
        4.0.1.0 is directly connected, Serial0.1
        124.0.0.0/24 is subnetted, 1 subnets C
        124.124.124.0 is directly connected, Ethernet0
        123.0.0.0/8 is variably subnetted, 2 subnets, 2 masks I
        123.0.0.0/8 [100/8576] via 4.0.1.2, 00:00:00, Serial0.1 S
        123.123.123.0/24 [250/0] via 3.1.6.2 I    
        122.0.0.0/8 [100/8576] via 3.1.3.3, 00:00:37, Serial0.2
   
   Spicey#
   *Mar  1 00:59:12.527: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
   *Mar  1 00:59:13.983: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   BRI0:1, changed state to up
   *Mar  1 00:59:18.547: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6105 Prasit
   
   Spicey#show isdn history
   --------------------------------------------------------------------------------
                                      ISDN CALL HISTORY
   --------------------------------------------------------------------------------
   Call History contains all active calls, and a maximum of 100 inactive calls.
   Inactive call data will be retained for a maximum of 15 minutes.
   --------------------------------------------------------------------------------
   Call    Calling      Called          Remote  Seconds Seconds Seconds
   Charges
   Type    Number       Number          Name    Used    Left    Idle  Units/Currency
   --------------------------------------------------------------------------------
   In         6105           6106       Prasit          31      90     29                  
   --------------------------------------------------------------------------------
   
   Spicey#
   *Mar  1 01:01:14.547: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected
   from 6105 Prasit, call lasted 122 seconds
   *Mar  1 01:01:14.663: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   *Mar  1 01:01:15.663: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   BRI0:1, changed state to down 

Prasit

Prasit#show frame-relay map
   Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
             status defined, active
   
   Prasit#ping 124.124.124.1
   
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
   
   Prasit#show ip route
   Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
          D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
          N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
          E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
          i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
   inter area
          * - candidate default, U - per-user static route, o - ODR
          P - periodic downloaded static route
   
   Gateway of last resort is not set
   
   I    3.0.0.0/8 [100/10476] via 4.0.1.1, 00:00:55, Serial1.1
        4.0.0.0/24 is subnetted, 1 subnets
   C    4.0.1.0 is directly connected, Serial1.1
        124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
   S    124.124.124.0/24 [250/0] via 3.1.6.1
   I    124.0.0.0/8 [100/8576] via 4.0.1.1, 00:00:55, Serial1.1
        123.0.0.0/24 is subnetted, 1 subnets
   C    123.123.123.0 is directly connected, Ethernet0
   I    122.0.0.0/8 [100/10576] via 4.0.1.1, 00:00:55, Serial1.1

La linea seriale si interrompe.

Prasit#
   *Mar  1 01:23:50.531: %LINK-3-UPDOWN: Interface Serial1, changed state to down
   *Mar  1 01:23:51.531: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   Serial1, changed state to down
   *Mar  1 01:23:53.775: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   *Mar  1 01:23:53.791: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
   *Mar  1 01:23:53.827: %LINK-3-UPDOWN: Interface BRI0, changed state to up
   *Mar  1 01:23:57.931: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 64 changed to up
   
   Prasit#show ip route
   Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
          D - EIGRP, EX - EIGRP external, O - OSPF,IA - OSPF inter area 
          N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
          E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
          i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
   inter area
          * - candidate default, U - per-user static route, o - ODR
          P - periodic downloaded static route
   
   Gateway of last resort is not set
   
        3.0.0.0/24 is subnetted, 1 subnets
   C    3.1.6.0 is directly connected, BRI0
        124.0.0.0/24 is subnetted, 1 subnets
   S    124.124.124.0 [250/0] via 3.1.6.1
        123.0.0.0/24 is subnetted, 1 subnets
   C    123.123.123.0 is directly connected, Ethernet0
   
   Prasit#show isdn status
   Global ISDN Switchtype = basic-net3
   ISDN BRI0 interface
           dsl 0, interface ISDN Switchtype = basic-net3
       Layer 1 Status:
           ACTIVE
       Layer 2 Status:
           TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
       Layer 3 Status:
           0 Active Layer 3 Call(s)
       Active dsl 0 CCBs = 0
       The Free Channel Mask:  0x80000003
       Total Allocated ISDN CCBs = 0
   
   Prasit#ping 124.124.124.1
   
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   !
   *Mar  1 01:25:47.383: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up!!!
   Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms
   Prasit#
   *Mar  1 01:25:48.475: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   BRI0:1, changed state to up
   
   Prasit#
   *Mar  1 01:25:53.407: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
   to 6106 Spicey
   
   Prasit#show isdn status
   Global ISDN Switchtype = basic-net3
   ISDN BRI0 interface
           dsl 0, interface ISDN Switchtype = basic-net3
       Layer 1 Status:
           ACTIVE
       Layer 2 Status:
           TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
       Layer 3 Status:
           1 Active Layer 3 Call(s)
           CCB:callid=8003, sapi=0, ces=1, B-chan=1, calltype=DATA
       Active dsl 0 CCBs = 1
       The Free Channel Mask: 0x80000002
       Total Allocated ISDN CCBs = 1
   
   Prasit#show isdn active
   --------------------------------------------------------------------------------
                                      ISDN ACTIVE CALLS
   --------------------------------------------------------------------------------
   Call    Calling      Called          Remote  Seconds Seconds Seconds Charges
   Type    Number       Number          Name    Used    Left    Idle    Units/Currency
   --------------------------------------------------------------------------------
   Out                   6106         Spicey      21     100      19       0        
   --------------------------------------------------------------------------------
   
   Prasit#
   *Mar  1 01:27:49.027: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected
   from 6106 Spicey, call lasted 121 seconds
   *Mar  1 01:27:49.131: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   *Mar  1 01:27:50.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   BRI0:1, changed state to down
   *Mar  1 01:28:09.215: %LINK-3-UPDOWN: Interface Serial1, changed state to up
   *Mar  1 01:28:10.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   Serial1, changed state to up
   *Mar  1 01:28:30.043: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0,
   TEI 64 changed to down
   *Mar  1 01:28:30.047: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI
   64 changed to down
   *Mar  1 01:28:30.371: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode
   *Mar  1 01:28:30.387: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   *Mar  1 01:28:30.403: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
   Prasit#

La connessione seriale è di nuovo attiva.

Prasit#show isdn status
   Global ISDN Switchtype = basic-net3
   ISDN BRI0 interface
           dsl 0, interface    ISDN Switchtype = basic-net3
       Layer 1 Status:
           DEACTIVATED
       Layer 2 Status:
           Layer 2 NOT Activated
       Layer 3 Status:
           0 Active Layer    3 Call(s)
       Active dsl 0 CCBs = 0
       The Free Channel Mask:  0x80000003
       Total Allocated ISDN CCBs = 0

   Prasit#show interface bri 0
   BRI0 is standby mode, line protocol is down 
     Hardware is BRI
     Internet address is 3.1.6.2/24
     MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, 
        reliability 255/255, txload 1/255, rxload 1/255
     Encapsulation PPP, loopback not set
     Last input 00:01:00, output 00:01:00, output hang never
     Last clearing of "show interface" counters 01:28:16
     Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
     Queueing strategy: weighted fair
     Output queue: 0/1000/64/0 (size/max total/threshold/drops) 
        Conversations  0/1/16 (active/max active/max total)
        Reserved Conversations 0/0 (allocated/max allocated)
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
        128 packets input, 601 bytes, 0 no buffer
        Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        132 packets output, 687 bytes, 0 underruns
        0 output errors, 0 collisions, 10 interface resets
        0 output buffer failures, 0 output buffers swapped out
        14 carrier transitions
  
   Prasit#ping 124.124.124.1
   
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Profili Hub and Spoke con dialer

Di seguito è riportato un esempio di hub and spoke per configurazione di backup DLCI. I router spoke stanno chiamando il router hub. Come si può vedere, è consentito un solo canale B per lato utilizzando l'opzione max-link sul pool dialer sul lato hub.

Nota: il carico di backup non è supportato sulle sottointerfacce. Poiché non si tiene traccia dei livelli di traffico sulle sottointerfacce, non viene calcolato alcun carico.

Esempio di rete

Configurazioni

• Aton

• Spicey

• Prasit

Aton#show running-config
Building configuration...
   
Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Aton
!
!
username Spicey password 0 cisco
!
isdn switch-type basic-net3
!
!
!
interface Ethernet0
 ip address 122.122.122.1 255.255.255.0
!
!
interface Serial1
 no ip address
 encapsulation frame-relay
!
interface Serial1.1 point-to-point
 ip address 3.1.3.3 255.255.255.0
 backup delay 5 10
 backup interface BRI0
 frame-relay interface-dlci 160   
!
interface BRI0
 ip address 155.155.155.3 255.255.255.0
 encapsulation ppp
 no ip route-cache
 no ip mroute-cache
 dialer map ip 155.155.155.2 name Spicey broadcast 6106
 dialer-group 1
 isdn switch-type basic-net3
 ppp authentication chap
!
router igrp 2
 network 3.0.0.0
 network 122.0.0.0
 network 155.155.0.0
!
ip route 124.124.124.0 255.255.255.0 155.155.155.2 250
!
access-list 101 deny   igrp any any
 access-list 101 permit ip any any
 dialer-list 1 protocol ip list 101
!
line con 0
 exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

Spicey#show running-config
Building configuration...
Current configuration : 1887 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Spicey
!
username Prasit password 0 cisco
username Aton password 0 cisco
!
isdn switch-type basic-net3
!
!
!
interface Ethernet0
 ip address 124.124.124.1 255.255.255.0
!
interface Serial0
 no ip address
 encapsulation frame-relay
!
interface Serial0.1 point-to-point
 ip address 4.0.1.1 255.255.255.0
 frame-relay interface-dlci 140   
!
interface Serial0.2 point-to-point
 ip address 3.1.3.1 255.255.255.0
 frame-relay interface-dlci 130   
!
interface BRI0
 no ip address
 encapsulation ppp
 no ip route-cache
 no ip mroute-cache
 dialer pool-member 2 max-link 1
 dialer pool-member 1 max-link 1
 isdn switch-type basic-net3
 no peer default ip address
 no cdp enable
 ppp authentication chap
!
interface Dialer1
 ip address 160.160.160.1 255.255.255.0
 encapsulation ppp
 no ip route-cache
 no ip mroute-cache
 dialer pool 1
 dialer remote-name Prasit
 dialer-group 1
 ppp authentication chap
!
interface Dialer2
 ip address 155.155.155.2 255.255.255.0
 encapsulation ppp
 no ip route-cache
 no ip mroute-cache
 dialer pool 2
 dialer remote-name Aton
 dialer-group 1
 ppp authentication chap
!
router igrp 2
 network 3.0.0.0
 network 4.0.0.0
 network 124.0.0.0
 network 155.155.0.0
 network 160.160.0.0
!
access-list 101 deny   igrp any any
 access-list 101 permit ip any any
 dialer-list 1 protocol ip list 101
!
line con 0
 exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

Prasit#show running-config
Building configuration...
   
Current configuration : 1267 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Prasit
!
username Spicey password 0 cisco
!
isdn switch-type basic-net3
!
!
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
interface Serial1
  no ip address
  encapsulation frame-relay
!
interface Serial1.1 point-to-point
 backup delay 5 10
 backup interface BRI0
 ip address 4.0.1.2 255.255.255.0
 frame-relay interface-dlci 150   
!
interface BRI0
 ip address 160.160.160.2 255.255.255.0
 encapsulation ppp
 dialer map ip 160.160.160.1 name Spicey broadcast 6106
 dialer-group 1
 isdn switch-type basic-net3
 ppp authentication chap
!
router igrp 2
 network 4.0.0.0
 network 123.0.0.0
 network 160.160.0.0
!
ip route 124.124.124.0 255.255.255.0 160.160.160.1 250
!
access-list 101 deny   igrp any any
 access-list 101 permit ip any any
 dialer-list 1 protocol ip list 101
!
line con 0
 exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

Comandi show

• mostra mappa frame relay

• show ip route

• mostra mappa fotogrammi

• show frame-relay pvc

Aton

Aton#show frame-relay map
   Serial1.1 (up): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast
             status defined, active
   
   Aton#ping 124.124.124.1
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
   
   Aton#show ip route
   Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
          D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area 
          N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2
          E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
          i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
          U - per-user static route, o - ODR, P - periodic downloaded static route
          T - traffic engineered route
   
   Gateway of last resort is not set
   
   I    155.155.0.0/16 [100/182571] via 3.1.3.1, Serial1.1
        3.0.0.0/24 is subnetted, 1 subnets
   C    3.1.3.0 is directly connected, Serial1.1
   I    4.0.0.0/8 [100/10476] via 3.1.3.1, Serial1.1
   I    160.160.0.0/16 [100/182571] via 3.1.3.1, Serial1.1
        124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
   S    124.124.124.0/24 [250/0] via 155.155.155.2
   I    124.0.0.0/8 [100/8576] via 3.1.3.1, Serial1.1
   I    123.0.0.0/8 [100/10576] via 3.1.3.1, Serial1.1
        122.0.0.0/24 is subnetted, 1 subnets
   C    122.122.122.0 is directly connected, Ethernet0
   Aton#   

Serial 1 sta per essere interrotto.

Aton#
   01:16:33: %LINK-3-UPDOWN: Interface Serial1, changed state to down
   01:16:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,
   changed state to down
   01:16:37: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   01:16:37: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
   01:16:37: %LINK-3-UPDOWN: Interface BRI0, changed state to up
   01:16:41: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 64 changed to up

   Aton#show ip route    
   Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
          D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
          N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
          E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP
          i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
          U - per-user static route, o - ODR, P - periodic downloaded static route
          T - traffic engineered route
   
   Gateway of last resort is not set
        155.155.0.0/24 is subnetted, 1 subnets
   C    155.155.155.0 is directly connected, BRI0
        124.0.0.0/24 is subnetted, 1 subnets
   S    124.124.124.0 [250/0] via 155.155.155.2
        122.0.0.0/24 is subnetted, 1 subnets
   C    122.122.122.0 is directly connected, Ethernet0
   
   Aton#ping 124.124.124.1
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   
   01:21:33: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.!!!!
   Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms
   Aton#
   01:21:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
   changed state to up
   01:21:39: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6106
   Spicey
   
   Aton#ping 124.124.124.1
   
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 32/123/296 ms
   Aton#

La porta seriale 1 torna attiva

Aton#
   01:24:02: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected from 6106
   Spicey, call lasted 149 seconds
   01:24:02: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   01:24:03: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
   changed state to down
  
   Aton#show frame map
   Serial1.1 (down): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast
             status deleted
   Aton#
   01:26:35: %LINK-3-UPDOWN: Interface Serial1, changed state to up
   01:26:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,
   changed state to up
   01:26:56: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0, TEI 64 changed
   to down
   01:26:56: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI 64 changed
   to down
   01:26:56: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode
   01:26:56: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   01:26:56: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
  
   Aton#show frame map
   Serial1.1 (up): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast
             status defined, active
   Aton#ping 124.124.124.1  
   
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
   
   Aton#ping 124.124.124.1

   Aton#show frame-relay pvc
   PVC Statistics for interface Serial1 (Frame Relay DTE)
                    Active     Inactive      Deleted          Static
     Local          1               0            0               0
     Switched       0               0            0               0
     Unused         0               0            0               0
   
   DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
   Serial1.1
     input pkts 60               output pkts 69           in    bytes 9694      
     out bytes 10811             dropped pkts 0           in    FECN pkts 0         
     in BECN pkts 0              out FECN pkts 0          out BECN pkts 0         
     in DE pkts 0                out DE pkts 0         
     out bcast pkts 44         out    bcast bytes 7565      
     pvc create time 01:28:35, last time pvc status changed 00:02:19

Spicey

Spicey#show frame-relay map
   Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
             status defined, active
   Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
             status defined, active
   
   Spicey#ping 122.122.122.1
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
   
   Spicey#ping 123.123.123.1
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
   
   Spicey#show ip route
   Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
          D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area 
          N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2
          E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP
          i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS    level-2, ia - IS-IS
   inter area
          * - candidate default, U - per-user static    route, o - ODR
          P - periodic downloaded static route
   Gateway of last resort is not set
        155.155.0.0/24 is subnetted, 1 subnets
   C    155.155.155.0 is directly connected, Dialer2
        3.0.0.0/24 is subnetted, 1 subnets
   C    3.1.3.0 is directly connected, Serial0.2
        4.0.0.0/24 is subnetted, 1 subnets
   C    4.0.1.0 is directly connected, Serial0.1
        160.160.0.0/24 is subnetted, 1 subnets
   C    160.160.160.0 is directly connected, Dialer1
        124.0.0.0/24 is subnetted, 1 subnets
   C    124.124.124.0 is directly connected, Ethernet0
   I    123.0.0.0/8 [100/8576] via 4.0.1.2, 00:00:55, Serial0.1
   I    122.0.0.0/8 [100/8576] via 3.1.3.3, 00:00:35, Serial0.2

Entrambe le linee seriali dai lati della chiamata stanno scendendo.

Spicey#

   *Mar  1 01:21:30.171: %LINK-3-UPDOWN: Interface BRI0:1, changed state toup
   *Mar  1 01:21:30.627: %DIALER-6-BIND: Interface BR0:1 bound to profile Di2
   *Mar  1 01:21:31.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   BRI0:1, changed state to up
   *Mar  1 01:21:36.191: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
   to 6104 Aton
   *Mar  1 01:21:40.923: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
   *Mar  1 01:21:41.359: %DIALER-6-BIND: Interface BR0:2 bound to profile Di1
   *Mar  1 01:21:42.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   BRI0:2, changed state to up
   *Mar  1 01:21:46.943: %ISDN-6-CONNECT: Interface BRI0:2 is now connected
   to 6105 Prasit
   *Mar  1 01:23:59.819: %DIALER-6-UNBIND: Interface BR0:1 unbound from
   profile Di2
   *Mar  1 01:23:59.831: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected
   from 6104 Aton, call lasted 149 seconds
   *Mar  1 01:23:59.927: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   *Mar  1 01:24:00.923: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   BRI0:1, changed state to down
   *Mar  1 01:24:03.015: %DIALER-6-UNBIND: Interface BR0:2 unbound from
   profile Di1
   *Mar  1 01:24:03.023: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected
   from 6105 Prasit, call lasted 142 seconds
   *Mar  1 01:24:03.107: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
   *Mar  1 01:24:04.107: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   BRI0:2, changed state to down

   Spicey#show frame map
   Serial0.1 (down): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
             status defined, inactive
   Serial0.2 (down): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
             status defined, inactive
   Spicey#

Entrambe le linee seriali sono di nuovo disponibili.

Spicey#show frame pvc
   PVC Statistics for interface Serial0 (Frame Relay DTE)
                    Active     Inactive      Deleted          Static
     Local          2               0            0               0
     Switched       0               0            0               0
     Unused         0               0            0               0
   
   DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
   Serial0.2
   
     input pkts 54               output pkts 61           in    bytes 7014      
     out bytes 9975              dropped pkts 3           in    FECN pkts 0         
     in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0         
     in DE pkts 0                out DE pkts 0         
     out bcast pkts 40         out    bcast bytes 7803      
     pvc create time 01:28:14, last time pvc status changed 00:02:38
   
   DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
   Serial0.1
   
     input pkts 56               output pkts 60           in    bytes 7604      
     out bytes 10114             dropped pkts 2           in    FECN pkts 0         
     in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0         
     in DE pkts 0                out DE pkts 0         
     out bcast pkts 39           out    bcast bytes 7928      
     pvc create time 01:28:15, last time pvc status changed 00:02:29

Prasit

Prasit#show frame-relay map
   Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
             status defined, active

   Prasit#ping 124.124.124.1
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
   
   Prasit#show ip route
   Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
          D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area 
          N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2
          E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP
          i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS    level-2, ia - IS-IS
   inter area
          * - candidate default, U - per-user static    route, o - ODR
          P - periodic downloaded static route
   
   Gateway of last resort is not set
   
   I    155.155.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1
   I    3.0.0.0/8 [100/10476] via 4.0.1.1, 00:00:41, Serial1.1
        4.0.0.0/24 is subnetted, 1 subnets
   C    4.0.1.0 is directly connected, Serial1.1
   I    160.160.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1
        124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
   S    124.124.124.0/24 [250/0] via 160.160.160.1
   I    124.0.0.0/8 [100/8576] via 4.0.1.1, 00:00:41, Serial1.1
        123.0.0.0/24 is subnetted, 1 subnets
   C    123.123.123.0 is directly connected, Ethernet0
   I    122.0.0.0/8 [100/10576] via 4.0.1.1, 00:00:42, Serial1.1
   Prasit#

Il numero seriale 1 non funziona.

Prasit#
   *Mar  1 01:16:08.287: %LINK-3-UPDOWN: Interface Serial1, changed state to down
   *Mar  1 01:16:09.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   Serial1, changed state to down
   *Mar  1 01:16:11.803: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   *Mar  1 01:16:11.819: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
   *Mar  1 01:16:11.855: %LINK-3-UPDOWN: Interface BRI0, changed state to up
   *Mar  1 01:16:15.967: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI
   64 changed to up
 
   Prasit#show ip route
   Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
          D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area 
          N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2
          E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP
          i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS    level-2, ia - IS-IS
   inter area
          * - candidate default, U - per-user static    route, o - ODR
          P - periodic downloaded static route
   
   Gateway of last resort is not set
   
        160.160.0.0/24 is subnetted, 1 subnets
   C    160.160.160.0 is directly connected, BRI0
        124.0.0.0/24 is subnetted, 1 subnets
   S    124.124.124.0 [250/0] via 160.160.160.1
        123.0.0.0/24 is subnetted, 1 subnets
   C    123.123.123.0 is directly connected, Ethernet0
   
   Prasit#ping 124.124.124.1
   
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   
   *Mar  1 01:21:38.967: %LINK-3-UPDOWN: Interface BRI0:1, changed state to
   up.!!!!
   Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms
   Prasit#
   *Mar  1 01:21:40.063: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   BRI0:1, changed state to up
   *Mar  1 01:21:44.991: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
   to 6106 Spicey
   
   Prasit#ping 124.124.124.1
   
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
   Prasit#

La porta seriale 1 diventa nuovamente attiva.

Prasit#

   *Mar  1 01:26:40.579: %LINK-3-UPDOWN: Interface Serial1, changed state to up
   *Mar  1 01:26:41.579: %LINEPROTO-5-UPDOWN: Line protocol on Interface
   Serial1, changed state to up
   *Mar  1 01:27:01.051: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0,
   TEI 64 changed to down
   *Mar  1 01:27:01.055: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI
   64 changed to down
   *Mar  1 01:27:01.363: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode
   *Mar  1 01:27:01.379: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
   *Mar  1 01:27:01.395: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

   Prasit#show frame map
   Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
             status defined, active

   Prasit#ping 124.124.124.1
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 36/116/432 ms
   
   Prasit#show frame-relay pvc
   PVC Statistics for interface Serial1 (Frame Relay DTE)
   
                    Active     Inactive      Deleted          Static
     Local          1               0            0               0
     Switched       0               0            0               0
     Unused         0               0            0               0
   
   DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
   Serial1.1
   
     input pkts 58               output pkts 66           in    bytes 9727      
     out bytes 10022             dropped pkts 0           in    FECN pkts 0         
     in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0         
     in DE pkts 0                out DE pkts 0         
     out bcast pkts 46         out    bcast bytes 7942      
     pvc create time 01:27:37, last time pvc status changed 00:01:59

Configurazione di Frame Relay Switching

La commutazione Frame Relay consente di commutare i pacchetti in base all'identificatore della connessione dati (DLCI). In questo caso possiamo considerarlo l'equivalente Frame Relay di un indirizzo MAC (Media Access Control). La commutazione viene eseguita configurando il router o il server di accesso Cisco in una rete Frame Relay. Una rete Frame Relay è composta da due parti:

• Apparecchiatura terminale dati Frame Relay (DTE): il router o il server di accesso.

• Interruttore Frame Relay Data Circuit-Terminating Equipment (DCE).

Nota: nel software Cisco IOS versione 12.1(2)T e successive, il comando frame route è stato sostituito dal comando connect.

Esaminiamo un esempio di configurazione. Nella configurazione seguente, viene utilizzato il router America come switch Frame Relay. Stiamo utilizzando Spicey come router hub e Prasit e Aton come router spoke. Le abbiamo collegate come segue:

• Prasit serial 1 (s1) DTE è collegato all'America serial 1/4 (s1/4) DCE.

• Spicey serial 0 (s0) DTE è collegato all'America serial 1/5 (s1/5) DCE.

• Aton serial 1 (s1) DTE è collegato all'America serial 3/4 (s3/4) DCE.

Esempio di rete

Questo documento si basa sulla seguente configurazione:

Configurazioni

• Spicey

• Prasit

• Aton

• America

Spicey#show running-config
Building configuration...

!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Spicey
!
!
!
interface Ethernet0
 ip address 124.124.124.1 255.255.255.0
!
interface Serial0
 ip address 3.1.3.1 255.255.255.0
 encapsulation frame-relay
 frame-relay interface-dlci 130
 frame-relay interface-dlci 140
!
!
router rip
 network 3.0.0.0
 network 124.0.0.0
!
line con 0
!
exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

Prasit#show running-config
Building configuration...
Current configuration : 1499 bytes
!
 version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Prasit
!
!
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
interface Serial1
 ip address 3.1.3.2 255.255.255.0
 encapsulation frame-relay
 frame-relay interface-dlci 150
!
!
router rip
 network 3.0.0.0
 network 123.0.0.0
!
 !
line con 0
 exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

Aton#show running-config
Building configuration...
Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Aton
!
!
!
interface Ethernet0
 ip address 122.122.122.1 255.255.255.0
!
interface Serial1
 ip address 3.1.3.3 255.255.255.0
 encapsulation frame-relay
 frame-relay interface-dlci 160
!
router rip
 network 3.0.0.0
 network 122.0.0.0
!
!
line con 0
 exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

america#show running-config
Building configuration...
Current configuration:
!
!
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname america
!
frame-relay switching
!
!
interface Serial1/4
 description *** static DCE connection to s1 Prasit
 no ip address
 encapsulation frame-relay
 clockrate 2000000
 frame-relay intf-type dce
 frame-relay route 150 interface Serial1/5 140
!
interface Serial1/5
 description *** static DCE connection to s0 spicy
 no ip address
 encapsulation frame-relay
 bandwidth 1000000
 tx-queue-limit 100
 frame-relay intf-type dce
 frame-relay route 130 interface Serial3/4 160
 frame-relay route 140 interface Serial1/4 150
 transmitter-delay 10
!
interface Serial3/4
 description *** static DCE connection to s1 Aton
 encapsulation frame-relay
 no ip mroute-cache
 clockrate 2000000
 frame-relay intf-type dce
 frame-relay route 160 interface Serial1/5 130
!

Comandi show

Per verificare che la rete funzioni correttamente, utilizzare i comandi show seguenti:

• mostra mappa frame relay

• show frame-relay pvc

L'output mostrato di seguito è il risultato dell'immissione di questi comandi sui dispositivi che stiamo utilizzando in questa configurazione di esempio.

Spicey

Spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
              broadcast,, status defined, active
Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,
              broadcast,, status defined, active

Spicey#show frame-relay pvc
     
PVC Statistics for interface Serial0 (Frame Relay DTE)
                   Active     Inactive      Deleted            Static
 Local          2                 0            0                 0
 Switched       0                 0            0                 0
 Unused         0                 0            0                 0
     
 DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
     
  input pkts 32                 output pkts 40                in bytes 3370      
  out bytes 3928                dropped pkts 0                in FECN pkts 0         
  in BECN pkts 0                out FECN pkts 0               out BECN pkts 0         
  in DE pkts 0                  out DE pkts 0         
  out bcast pkts 30             out bcast bytes 2888      
  pvc create time 00:15:46, last time pvc status changed 00:10:42
     
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
     
   input pkts 282                output pkts 291          in bytes 25070     
   out bytes 27876               dropped pkts 0           in FECN pkts 0         
   in BECN pkts 0                out FECN pkts 0          out BECN pkts 0         
   in DE pkts 0                  out DE pkts 0         
   out bcast pkts 223            out bcast bytes 20884     
   pvc create time 02:28:36, last time pvc status changed 02:25:14

Prasit

Prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
                   broadcast,, status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)
                   Active     Inactive      Deleted            Static
  Local          1                 0            0                 0
  Switched       0                 0            0                 0
  Unused         0                 0            0                 
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
  input pkts 311                output pkts 233          in bytes 28562     
  out bytes 22648               dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0                out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0                  out DE pkts 0         
  out bcast pkts 162            out bcast bytes 15748     
  pvc create time 02:31:39, last time pvc status changed 02:25:14

Aton

Aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic, broadcast, status defined, active

Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
               Active     Inactive      Deleted            Static
Local          1                 0            0                 0
Switched       0                 0            0                 0
Unused         0                 0            0                 0
     
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial
 input pkts 35                 output pkts 32                in bytes 3758      
 out bytes 3366                dropped pkts 0                in FECN pkt 0         
 in BECN pkts 0                out FECN pkts 0               out BECN pkts 0         
 in DE pkts 0                  out DE pkts 0         
 out bcast pkts 27 out bcast bytes 2846      
 pvc create time 00:10:53, last time pvc status changed 00:10:53

Configurazione della definizione di priorità DLCI Frame Relay

La definizione di priorità DLCI (Data-Link Connection Identifier) è il processo in base al quale tipi di traffico diversi vengono inseriti in DLCI separati in modo che una rete Frame Relay possa fornire una diversa velocità di commit delle informazioni per ogni tipo di traffico. Può essere utilizzato in combinazione con le code personalizzate o con le code di priorità per fornire il controllo della gestione della larghezza di banda sul collegamento di accesso alla rete Frame Relay. Inoltre, alcuni provider di servizi Frame Relay e switch Frame Relay (come gli switch Stratacom Internetwork Packet Exchange [IPX], IGX e BPX o AXIS) in realtà forniscono l'assegnazione di priorità nel cloud Frame Relay in base a questa impostazione di priorità.

Considerazioni sull'implementazione

Quando si implementa la definizione delle priorità DLCI, tenere presente quanto segue:

• Se un DLCI secondario diventa inattivo, si perde il traffico destinato solo a quella coda.

• Se si perde il DLCI primario, l'interfaccia secondaria si blocca e si perde tutto il traffico.

Esempio di rete

Per utilizzare questa impostazione, è necessario disporre di quattro DLCI per il lato che utilizzerà la definizione di priorità DLCI. Nell'esempio, Spicey è stato configurato per l'accodamento delle priorità come segue:

• Ping nella coda ad alta priorità.

• Telnet è nella coda a priorità media.

• Il protocollo FTP (File Transfer Protocol) si trova nella coda con priorità normale.

• Tutto il resto del traffico IP si trova nella coda a bassa priorità.

Nota: accertarsi di configurare i DLCI in modo che corrispondano all'elenco di priorità, altrimenti il sistema non utilizzerà la coda corretta.

Configurazioni

• Spicey

• Prasit

Spicey#show running-config
Building configuration...

Current configuration : 1955 bytes
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname Spicey
!
!
interface Ethernet0
 ip address 124.124.124.1 255.255.255.0
!
interface Serial0
 no ip address
 encapsulation frame-relay
 priority-group 1
!
interface Serial0.1 point-to-point
 ip address 4.0.1.1 255.255.255.0
 frame-relay priority-dlci-group 1 140 180 190 200
 frame-relay interface-dlci 140   
!
router igrp 2
 network 4.0.0.0
 network 124.0.0.0
!
access-list 102 permit icmp any any
 priority-list 1 protocol ip high list 102
 priority-list 1 protocol ip medium tcp telnet
 priority-list 1 protocol ip normal tcp ftp
 priority-list 1 protocol ip low
!
line con 0
 exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

Prasit#show running-config
Building configuration...

!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname Prasit
!
!
!
interface Ethernet0
 ip address 123.123.123.1 255.255.255.0
!
interface Serial1
 ip address 4.0.1.2 255.255.255.0
 encapsulation frame-relay
!
router igrp 2
 network 4.0.0.0
 network 123.0.0.0
!
line con 0
 exec-timeout 0 0
 transport input none
 line aux 0
 line vty 0 4
 login
!
end

Comandi debug e show

Utilizzare i seguenti comandi show ed debug per verificare che la rete funzioni correttamente. Prima di usare i comandi di debug, consultare le informazioni importanti sui comandi di debug.

• show frame-relay pvc

• mostra mappa frame relay

• mostra priorità in coda

• priorità di debug

L'output mostrato di seguito è il risultato dell'immissione di questi comandi sui dispositivi che stiamo utilizzando in questa configurazione di esempio.

Spicey

Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          4            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

  input pkts 106           output pkts 15           in bytes 6801      
  out bytes 1560           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 0         out bcast bytes 0         
  pvc create time 00:29:22, last time pvc status changed 00:20:37
  Priority DLCI Group 1, DLCI 140 (HIGH), DLCI 180 (MEDIUM)
  DLCI 190 (NORMAL), DLCI 200 (LOW)

DLCI = 180, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

  input pkts 0             output pkts 51           in bytes 0         
  out bytes 2434           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 0         out bcast bytes 0         
  pvc create time 00:29:23, last time pvc status changed 00:14:48

DLCI = 190, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

  input pkts 0             output pkts 13           in bytes 0         
  out bytes 3653           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 13        out bcast bytes 3653      
  pvc create time 00:29:23, last time pvc status changed 00:14:28

DLCI = 200, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

  input pkts 0             output pkts 42           in bytes 0         
  out bytes 2554           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 10        out bcast bytes 500       
  pvc create time 00:29:24, last time pvc status changed 00:14:09

Spicey#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
  status defined, active
  Priority DLCI Group 1, DLCI 140 (HIGH), DLCI 180 (MEDIUM)
  DLCI 190 (NORMAL), DLCI 200 (LOW)

Spicey#show queueing priority
Current priority queue configuration:

List   Queue  Args
1      high   protocol ip          list 102
1      medium protocol ip          tcp port telnet
1      normal protocol ip          tcp port ftp
1      low    protocol ip         

Per verificare la coda di priorità, utilizzare il comando debug priority.

Spicey#debug priority 
Priority output queueing debugging is on

Spicey#ping 123.123.123.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48 ms
Spicey#
*Mar  1 00:32:30.391: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.395: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.399: PQ: Serial0 output (Pk size/Q 104/0)
*Mar  1 00:32:30.439: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.443: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.447: PQ: Serial0 output (Pk size/Q 104/0)
*Mar  1 00:32:30.487: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.491: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.495: PQ: Serial0 output (Pk size/Q 104/0)
*Mar  1 00:32:30.535: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.539: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.543: PQ: Serial0 output (Pk size/Q 104/0)
*Mar  1 00:32:30.583: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.587: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high
*Mar  1 00:32:30.587: PQ: Serial0 output (Pk size/Q 104/0)Spicey#

Spicey#telnet 123.123.123.1
Trying 123.123.123.1 ... Open

User Access Verification

Password: 
*Mar  1 00:32:59.447: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.451: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.451: PQ: Serial0 output (Pk size/Q 48/1)
*Mar  1 00:32:59.475: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.479: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.483: PQ: Serial0 output (Pk size/Q 44/1)
*Mar  1 00:32:59.487: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.487: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.491: PQ: Serial0 output (Pk size/Q 53/1)
*Mar  1 00:32:59.495: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.499: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.499: PQ: Serial0 output (Pk size/Q 44/1)
*Mar  1 00:32:59.511: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.511: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.515: PQ: Serial0 output (Pk size/Q 47/1)
*Mar  1 00:32:59.519: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.519: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.523: PQ: Serial0 output (Pk size/Q 47/1)
*Mar  1 00:32:59.527: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.527: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.531: PQ: Serial0 output (Pk size/Q 53/1)
*Mar  1 00:32:59.539: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.543: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.547: PQ: Serial0 output (Pk size/Q 47/1)
*Mar  1 00:32:59.751: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.755: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:32:59.755: PQ: Serial0 output (Pk size/Q 44/1)
Password:

L'altro traffico IP passa attraverso la coda bassa.

Spicey#
*Mar  1 00:53:57.079: PQ: Serial0 output (Pk size/Q 13/0)
*Mar  1 00:53:58.851: PQ: Serial0: ip -> low
*Mar  1 00:53:58.907: PQ: Serial0: ip -> low
*Mar  1 00:53:58.907: PQ: Serial0 output (Pk size/Q 36/3)
*Mar  1 00:53:59.459: PQ: Serial0: ip -> low
*Mar  1 00:53:59.463: PQ: Serial0: ip -> low
*Mar  1 00:53:59.463: PQ: Serial0 output (Pk size/Q 50/3)
Spicey#

Prasit

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1

  input pkts 134           output pkts 119          in bytes 12029     
  out bytes 7801           dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  out bcast pkts 18         out bcast bytes 1260      
  pvc create time 00:21:15, last time pvc status changed 00:21:15

Prasit#show frame-relay map
Serial1 (up): ip 4.0.1.1 dlci 150(0x96,0x2460), dynamic,
              broadcast, status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48
Here is the debug output shown on Spicey when you use the command above to ping to Spicey from Prasit. 
Spicey#
*Mar  1 00:33:26.755: PQ: Serial0 output (Pk size/Q 13/0)
*Mar  1 00:33:28.535: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.539: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.543: PQ: Serial0 output (Pk size/Q 104/0)
*Mar  1 00:33:28.583: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.587: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.587: PQ: Serial0 output (Pk size/Q 104/0)
*Mar  1 00:33:28.631: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.635: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.635: PQ: Serial0 output (Pk size/Q 104/0)
*Mar  1 00:33:28.679: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.683: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.683: PQ: Serial0 output (Pk size/Q 104/0)
*Mar  1 00:33:28.723: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.727: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high
*Mar  1 00:33:28.731: PQ: Serial0 output (Pk size/Q 104/0)

Prasit#telnet 124.124.124.1
Trying 124.124.124.1 ... Open


User Access Verification
Password: 
Spicey>exit

[Connection to 124.124.124.1 closed by foreign host]
Prasit#

Di seguito è riportato l'output del comando debug mostrato su Spicey quando si usa il comando precedente per telnet su Spicey da Prasit.

Spicey#
*Mar  1 00:33:54.499: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.499: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.503: PQ: Serial0 output (Pk size/Q 48/1)
*Mar  1 00:33:54.527: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.531: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.531: PQ: Serial0 output (Pk size/Q 56/1)
*Mar  1 00:33:54.547: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.551: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.555: PQ: Serial0 output (Pk size/Q 86/1)
*Mar  1 00:33:54.559: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.563: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.563: PQ: Serial0 output (Pk size/Q 47/1)
*Mar  1 00:33:54.571: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.575: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.575: PQ: Serial0 output (Pk size/Q 47/1)
*Mar  1 00:33:54.779: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.783: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:54.783: PQ: Serial0 output (Pk size/Q 44/1)
*Mar  1 00:33:56.755: PQ: Serial0 output (Pk size/Q 13/0)
*Mar  1 00:33:57.143: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:57.143: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:57.147: PQ: Serial0 output (Pk size/Q 44/1)
*Mar  1 00:33:57.447: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:57.447: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:57.451: PQ: Serial0 output (Pk size/Q 44/1)
*Mar  1 00:33:57.899: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:57.899: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:57.903: PQ: Serial0 output (Pk size/Q 53/1)
*Mar  1 00:33:59.491: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:59.495: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:59.495: PQ: Serial0 output (Pk size/Q 45/1)
*Mar  1 00:33:59.711: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:59.715: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:59.715: PQ: Serial0 output (Pk size/Q 45/1)
*Mar  1 00:33:59.951: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:59.951: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:33:59.955: PQ: Serial0 output (Pk size/Q 45/1)
*Mar  1 00:34:00.123: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:34:00.123: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:34:00.127: PQ: Serial0 output (Pk size/Q 45/1)
*Mar  1 00:34:00.327: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:34:00.327: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:34:00.331: PQ: Serial0 output (Pk size/Q 46/1)
*Mar  1 00:34:00.495: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:34:00.499: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:34:00.499: PQ: Serial0 output (Pk size/Q 44/1)
*Mar  1 00:34:00.543: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:34:00.543: PQ: Serial0: ip (tcp 23) -> medium
*Mar  1 00:34:00.547: PQ: Serial0 output (Pk size/Q 44/1)

Coda di trasmissione Frame Relay

La coda di trasmissione è una funzione principale utilizzata nelle reti IP o IPX di medie e grandi dimensioni, in cui le trasmissioni SAP (Service Access Point) e di routing devono passare attraverso la rete Frame Relay. La coda di trasmissione viene gestita indipendentemente dalla normale coda di interfaccia, dispone di propri buffer e ha dimensioni e velocità di servizio configurabili. Questa coda di trasmissione non viene utilizzata per il bridging di aggiornamenti Spanning-Tree (BPDU) a causa di problemi di sensibilità negli intervalli. Questi pacchetti passeranno attraverso le code normali. Di seguito è riportato il comando di interfaccia per abilitare la coda di trasmissione:

frame-relay dimensioni coda di broadcast byte-rate packet-rate

A una coda di trasmissione viene assegnato un limite di velocità di trasmissione massima (throughput) misurato in byte al secondo e pacchetti al secondo. La coda viene servita per garantire che venga fornito solo questo numero massimo. La coda di trasmissione ha la priorità quando trasmette a una velocità inferiore al massimo configurato e quindi ha una allocazione minima garantita della larghezza di banda. I due limiti di velocità di trasmissione hanno lo scopo di evitare di inondare l'interfaccia con le trasmissioni. Il limite effettivo in un secondo è il primo limite di tasso raggiunto. Data la restrizione della velocità di trasmissione, è necessario un buffer aggiuntivo per archiviare i pacchetti broadcast. La coda di trasmissione è configurabile per archiviare un numero elevato di pacchetti di trasmissione. Impostare le dimensioni della coda per evitare la perdita dei pacchetti di aggiornamento del routing di trasmissione. Le dimensioni esatte dipendono dal protocollo in uso e dal numero di pacchetti richiesti per ogni aggiornamento. Per sicurezza, la dimensione della coda deve essere impostata in modo da poter archiviare un aggiornamento di routing completo da ogni protocollo e per ogni DLCI (Data-Link Connection Identifier). Come regola generale, iniziare con 20 pacchetti per DLCI. La velocità in byte deve essere minore di entrambe le seguenti:

• N/4 volte la velocità di accesso remoto minima (misurata in byte al secondo), dove N è il numero di DLCI su cui deve essere replicata la trasmissione

• 1/4 della velocità di accesso locale (in byte al secondo)

La velocità dei pacchetti non è critica se la velocità in byte è impostata in modo conservativo. In generale, la velocità dei pacchetti deve essere impostata presupponendo pacchetti da 250 byte. I valori predefiniti per le interfacce seriali sono 64 dimensioni della coda, 256.000 byte al secondo (2.048.000 bps) e 36 punti/sec. I valori predefiniti per le interfacce seriali ad alta velocità (HSSI) sono 256 dimensioni della coda, 1.024.000 byte al secondo (8.192.000 bps) e 144 bps.

Traffic Shaping

Il Traffic Shaping utilizza un meccanismo di controllo della velocità denominato filtro token bucket. Il filtro bucket token è impostato come segue:

Excess Burst plus Committed Burst (Bc + Be) = velocità massima per il circuito virtuale (VC)

Il traffico al di sopra della velocità massima viene memorizzato nel buffer in una coda di traffic shaping corrispondente alle dimensioni della coda equa ponderata (WFQ). Il filtro Token Bucket non filtra il traffico, ma controlla la velocità di invio del traffico sull'interfaccia in uscita. Per ulteriori informazioni sui filtri token bucket, vedere Panoramica su policy e shaping.

Questo documento offre una panoramica del traffic shaping generico e del traffic shaping Frame Relay.

Parametri di Traffic Shaping

È possibile utilizzare i seguenti parametri di traffic shaping:

• CIR = tasso informazioni vincolate (= tempo medio)

• EIR = tasso di informazioni in eccesso

• TB = bucket token (= Bc + Be)

• Bc = dimensione burst impegnata (= dimensione burst sostenuta)

• Be = dimensione burst in eccesso

• DE = idoneità al rifiuto

• Tc = intervallo di misurazione

• AR = velocità di accesso corrispondente alla velocità dell'interfaccia fisica (quindi se si utilizza un T1, AR è di circa 1,5 Mbps).

Esaminiamo più dettagliatamente alcuni di questi parametri:

Access Rate (AR)

Il numero massimo di bit al secondo che una stazione terminale può trasmettere nella rete è limitato dalla velocità di accesso dell'interfaccia utente-rete. La velocità di linea della connessione di rete dell'utente limita la velocità di accesso. È possibile stabilire tale valore nella sottoscrizione al provider di servizi.

Dimensioni Burst Committed (Bc)

La quantità massima di dati di cui è stato eseguito il commit che è possibile offrire alla rete è definita come Bc. Bc è una misura per il volume di dati per i quali la rete garantisce il recapito dei messaggi in condizioni normali. Viene misurato durante il tasso impegnato Tc.

Dimensioni burst in eccesso (Be)

Numero di bit non vincolati (esterni a CIR) ancora accettati dallo switch Frame Relay ma contrassegnati come idonei per essere scartati (DE).

Il bucket di token è un buffer 'virtuale'. Contiene un numero di token che consentono di inviare una quantità limitata di dati per intervallo di tempo. Il bucket del token è riempito con bit in bc per tc. La dimensione massima del bucket è Ccn + Be. Se il Be è molto grande e, se a T0 il bucket è pieno di token Bc + Be, è possibile inviare bit Bc + Be alla velocità di accesso. Questo non è limitato da Tc ma dal tempo necessario per inviare il Be. Questa è una funzione della velocità di accesso.

CIR (Committed Information Rate)

Il CIR è la quantità consentita di dati che la rete si impegna a trasferire in condizioni normali. La velocità viene calcolata sulla base di un incremento di tempo Tc. Il CIR è anche definito throughput minimo accettabile. Bc e Be sono espressi in bit, Tc in secondi, e la velocità di accesso e CIR in bit al secondo.

Bc, Be, Tc e CIR sono definiti per DLCI (Data-Link Connection Identifier). Per questo motivo, il filtro bucket di token controlla la velocità per DLCI. La velocità di accesso è valida per interfaccia utente-rete. Per i valori Bc, Be e CIR in entrata e in uscita è possibile distinguerli. Se la connessione è simmetrica, i valori in entrambe le direzioni sono uguali. Per i circuiti virtuali permanenti, definiamo Bc, Be e CIR in entrata e in uscita al momento dell'abbonamento.

• Picco = velocità massima DLCI. Larghezza di banda per il DLCI specifico.

• Tc = Bc / CIR

• Picco = CIR + Be/Tc = CIR (1 + Be/Bc)

Se il valore Tc è pari a un secondo:

• Picco = CIR + Be = Bc + Be

• EIR = Be

Nell'esempio che stiamo utilizzando qui, il router invia il traffico tra 48 Kbps e 32 Kbps a seconda della congestione della rete. Le reti possono contrassegnare i frame sopra Bc con DE, ma hanno una grande capacità di riserva per trasportare il frame. È anche possibile il contrario: possono avere una capacità limitata, ma scartare fotogrammi eccessivi immediatamente. Le reti possono contrassegnare i frame sopra Bc + Be con DE, e possibilmente trasportarli, o semplicemente rilasciare i frame come suggerito dalla specifica di settore ITU-T I.370 Telecommunication Union Telecommunication Standardisation. Il traffic shaping limita il traffico in base ai pacchetti con tag BECN (Backward-Explication Congestion Notification) provenienti dalla rete dello switch. Se si riceve il 50% di BECN, il router diminuisce il traffico di un ottavo della larghezza di banda trasmessa corrente per quel particolare DLCI.

Esempio

La velocità di trasmissione è di 42 Kb. Il router diminuisce la velocità a 42 meno 42 diviso 8 (42 - 42/8), ottenendo 36,75 Kb. Se la congestione diminuisce dopo la modifica, il router riduce ulteriormente il traffico, riducendolo a un ottavo della larghezza di banda trasmessa corrente. Il traffico viene ridotto fino a raggiungere il valore CIR configurato. Tuttavia, la velocità può scendere sotto il CIR quando possiamo ancora vedere i BECN. È possibile specificare un limite inferiore, ad esempio CIR/2. La rete non è più congestionata quando tutti i frame ricevuti dalla rete non hanno più un bit BECN per un determinato intervallo di tempo. 200 ms è il valore predefinito per questo intervallo.

GTS (Generic Traffic Shaping)

La funzionalità Generic traffic shaping è uno strumento di traffic shaping indipendente dall'incapsulamento e dai supporti che aiuta a ridurre il flusso del traffico in uscita in caso di congestione nel cloud, sul collegamento o sul router dell'endpoint ricevente. Possiamo impostarlo sulle interfacce o sottointerfacce all'interno di un router.

Generic traffic shaping è utile nelle situazioni seguenti:

• Se si dispone di una topologia di rete costituita da una connessione ad alta velocità (velocità della linea T1) nel sito centrale e da connessioni a bassa velocità (inferiori a 56 kbps) nel sito di filiale o di telelavoro. A causa della mancata corrispondenza della velocità, spesso esiste un collo di bottiglia per il traffico sulle filiali o sui siti di telelavoro quando il sito centrale invia i dati a una velocità più elevata che i siti remoti possono ricevere. Ciò determina un collo di bottiglia nell'ultimo switch prima del router del punto remoto.

• Se l'utente è un provider di servizi che offre servizi a tariffa secondaria, questa funzionalità consente di utilizzare il router per partizionare, ad esempio, i collegamenti T1 o T3 in canali più piccoli. È possibile configurare ogni sottointerfaccia con un bucket di filtro token corrispondente al servizio ordinato da un cliente.

Sulla connessione Frame Relay è possibile impostare il router in modo che rallenti il traffico anziché inviarlo alla rete. Limitando il traffico si limita la perdita di pacchetti nel cloud del provider di servizi. La funzionalità di limitazione basata sulla rete BECN fornita con questa funzionalità consente di impostare il router in modo dinamico per la limitazione del traffico in base alla ricezione di pacchetti con tag BECN dalla rete. Questa limitazione contiene i pacchetti nei buffer del router per ridurre il flusso di dati dal router alla rete Frame Relay. Il router limita il traffico su una base di sottointerfaccia e la velocità aumenta anche quando si ricevono meno pacchetti con tag BECN.

Comandi per Generic Traffic Shaping

Per definire il controllo della velocità, utilizzare questo comando:

velocità in bit del traffico [burst-size [exceeded-burst-size] [group access-list]

Per limitare i nomi BECN su un'interfaccia Frame Relay, utilizzare questo comando:

adattivo a forma di traffico [bit rate]

Per configurare una sottointerfaccia Frame Relay in modo da stimare la larghezza di banda disponibile quando riceve i numeri BECN, utilizzare il comando traffic-shape adaptive.

Nota: per poter utilizzare il comando traffic-shape adaptive, è necessario abilitare il traffic shaping sull'interfaccia con il comando traffic-shape rate.

La velocità in bit specificata per il comando traffic-shape rate è il limite superiore, mentre la velocità in bit specificata per il comando traffic-shape adaptive è il limite inferiore (di solito il valore CIR) in corrispondenza del quale il traffico ha la forma quando l'interfaccia riceve i BECN. Il tasso effettivamente utilizzato si situa normalmente tra questi due tassi. È necessario configurare il comando traffic-shape adaptive su entrambe le estremità del collegamento, in quanto configura anche il dispositivo all'estremità del flusso in modo che rifletta i segnali FECN (forward explicit congestion notification) come BECN. Ciò consente al router all'estremità ad alta velocità di rilevare e adattarsi alla congestione anche quando il traffico scorre principalmente in una direzione.

Esempio

L'esempio che segue configura il traffic shaping sull'interfaccia 0.1 con un limite superiore (generalmente Bc + Be) di 128 kbps e un limite inferiore di 64 kbps. Ciò consente al collegamento di funzionare da 64 a 128 kbps, a seconda del livello di congestione. Se il lato centrale ha un limite superiore di 256 kbps, è necessario utilizzare il valore limite superiore più basso.

Di seguito è riportata la configurazione effettuata su questi router:

Central# 
 interface serial 0 
  encapsulation-frame-relay 
 interface serial 0.1    
  traffic-shape rate 128000 
  traffic-shape adaptive 64000 


Client# 
 interface serial 0 
  encapsulation-frame-relay 
 interface serial 0.1 
  traffic-shape rate 128000 
  traffic-shape adaptive 64000 

FRTS (Frame Relay Traffic Shaping)

Con il traffic shaping generico è possibile specificare solo una velocità di picco (limite superiore) per interfaccia fisica e un valore CIR (limite inferiore) per sottointerfaccia. Con il traffic shaping Frame Relay si avvia un filtro token bucket per circuito virtuale.

Il traffic shaping su Frame Relay offre le seguenti funzionalità:

• Applicazione della velocità per ogni VC: è possibile configurare una velocità massima per limitare il traffico in uscita al CIR o a un altro valore definito, ad esempio la velocità per le informazioni in eccesso (EIR, Excess Information Rate).

• Supporto BECN generalizzato per ogni VC: il router può monitorare le BECN e limitare il traffico in base al feedback dei pacchetti con marchio BECN dalla rete Frame Relay.

• Supporto PQ (Priority Queuing), CQ (Custom Queuing) o WFQ a livello VC. Ciò consente una maggiore granularità nell'assegnazione delle priorità e nelle code del traffico, offrendo un maggiore controllo sul flusso del traffico di una singola VC. Il traffic shaping su Frame Relay si applica ai PVC (Permanent Virtual Circuit) e ai SVC (Switched Virtual Circuit) di Frame Relay.

Esempio

Interface Serial 0 
 no ip address 
 encapsulation frame-relay 
 frame-relay traffic-shaping    
! 
interface Serial0.100 
 ip address 1.1.1.1 255.255.255.252 
 frame-relay interface-dlci 100 
 frame-relay class fast 
! 
interface Serial0.200 
 ip address 1.1.1.5 255.255.255.252    
 frame-relay interface-dlci 200 
 frame-relay class slow 
! 
map-class frame-relay slow 
 frame-relay traffic-rate 64000 128000 
! 
map-class 
 frame-relay fast 
 frame-relay traffic-rate 16000 64000 
!

Nell'esempio, il router aggiunge due token-bucket.

• Uno è compreso tra 64000 (CIR) e 128000 (Bc + Be).

• L'altro valore è compreso tra 16000 (CIR) e 64000 (Bc + Be).

Se il traffico in arrivo da Ethernet è più grande del filtro token bucket, viene memorizzato nel buffer nella coda del traffico frame relay.

Per visualizzare un diagramma di flusso che mostra il flusso del pacchetto quando si implementa il traffic shaping Frame Relay, vedere Diagramma di flusso del traffico Frame Relay. Per visualizzare un diagramma di flusso che utilizza in modo specifico un filtro token bucket, vedere Diagramma di flusso del traffico Frame Relay - Token Bucket.

Comandi Frame Relay di uso comune

In questa sezione vengono descritti due comandi Cisco IOS® particolarmente utili per la configurazione di Frame Relay.

show frame-relay pvc

Questo comando mostra lo stato del circuito virtuale permanente (PVC), i pacchetti in entrata e in uscita, i pacchetti ignorati se c'è congestione sulla linea tramite notifica esplicita di congestione diretta (FECN), notifica esplicita di congestione all'indietro (BECN) e così via. Per una descrizione dettagliata dei campi utilizzati con il comando show frame-relay pvc, fare clic qui.

se il dispositivo Cisco restituisce i risultati di un comando show frame-relay pvc, è possibile usare Output Interpreter (solo utenti registrati) per visualizzare i potenziali errori e correggerli.

Di seguito è riportato un esempio di output:

RouterA#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
DLCI = 666, DLCI USAGE = UNUSED, PVC STATUS = DELETED, INTERFACE = Serial0
  input pkts 0             output pkts 0            in bytes 0         
  out bytes 0              dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  pvc create time 0:03:18  last time pvc status changed 0:02:27
  Num Pkts Switched 0         
DLCI = 980, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
  input pkts 19            output pkts 87           in bytes 2787      
  out bytes 21005          dropped pkts 0           in FECN pkts 0         
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0         
  in DE pkts 0             out DE pkts 0         
  pvc create time 1:17:47  last time pvc status changed 0:58:27

Il campo DLCI USAGE (USO DLCI) contiene una delle seguenti voci:

• SWITCHED: il router o il server di accesso viene utilizzato come switch.

• LOCAL: il router o il server di accesso viene utilizzato come apparecchiatura terminale dati (DTE).

• UNUSED - I comandi di configurazione immessi dall'utente sul router non fanno riferimento all'identificatore della connessione dati (DLCI).

Il PVC può avere quattro stati possibili. Questi sono mostrati dal campo PVC STATUS come segue:

• ATTIVO - Il PVC è attivo e funziona normalmente.

• INACTIVE - Il PVC non è completo. Ciò si può verificare perché non esiste alcun mapping (o mapping errato) per il DLCI locale nel cloud Frame Relay o perché l'estremità remota del PVC è eliminata.

• DELETED: l'interfaccia di gestione locale (LMI) non viene scambiata tra il router e lo switch locale o lo switch non ha DLCI configurato sullo switch locale.

• STATIC - non è stato configurato alcun keepalive sull'interfaccia frame-relay del router.

mostra mappa frame relay

Utilizzare questo comando per determinare se l'inverso-arp frame-relay ha risolto un indirizzo IP remoto in un DLCI locale. Questo comando non è abilitato per le sottointerfacce point-to-point. È utile solo per le interfacce multipunto e le sottointerfacce. Di seguito è riportato un esempio di output:

RouterA#show frame-relay map
Serial0 (up): ip 157.147.3.65 dlci 980(0x3D4,0xF440), dynamic,
         broadcast,, status defined, active

Per una descrizione dettagliata dei campi utilizzati con il comando show frame-relay map, consultare la documentazione sui comandi frame relay.

se il dispositivo Cisco restituisce i risultati di un comando show frame-relay map, è possibile usare Output Interpreter (solo utenti registrati) per visualizzare i potenziali errori e correggerli.

Frame Relay e Bridging

I messaggi di configurazione chiamati BDPU (Bridge Protocol Data Unit) vengono utilizzati nei protocolli spanning-tree supportati nei bridge e nei router Cisco. Questi flussi di traffico a intervalli regolari tra i ponti e costituiscono una quantità significativa di traffico a causa della loro frequenza. Nel bridging trasparente sono disponibili due tipi di protocolli spanning-tree. Introdotto per la prima volta dalla Digital Equipment Corporation (DEC), l'algoritmo è stato successivamente revisionato dal comitato IEEE 802 e pubblicato nella specifica IEEE 802.1d. Il protocollo DEC Spanning-Tree Protocol emette BPDU a intervalli di un secondo, mentre l'IEEE emette BPDU a intervalli di due secondi. Ogni pacchetto è lungo 41 byte, e include un messaggio BPDU di configurazione da 35 byte, un'intestazione Frame Relay da 2 byte, Ethertype da 2 byte e FCS da 2 byte.

Frame Relay e memoria

Il consumo di memoria per le risorse Frame Relay si verifica in quattro aree:

1. Ogni identificatore di connessione dati (DLCI): 216 byte

2. Ogni istruzione map: 96 byte (o mappa generata dinamicamente)

3. Ogni IDB (interfaccia hardware + Frame Relay di accesso): 5040 + 8346 = 13.386 byte

4. Ogni IDB (sottointerfaccia software): 2260 byte

Ad esempio, una Cisco 2501 che utilizza due interfacce Frame Relay, ognuna con quattro sottointerfacce, con un totale di otto DLCI e mappe associate, richiede quanto segue:

• IDB hardware a 2 interfacce x 13.386 = 26.772

• 8 sottointerfacce IDB x 2260 = 18.080 sottointerfacce

• 8 DLCI x 216 = 1728 DLCI

• 8 istruzioni map x 96 = 768 istruzioni map o dinamica

Il totale è pari a 47.348 byte di RAM utilizzati.

Nota: i valori utilizzati in questo documento sono validi per il software Cisco IOS versione 11.1, 12.0 e 12.1.

Risoluzione dei problemi di Frame Relay

In questa sezione vengono illustrate alcune parti dell'output del comando show interface che potrebbe essere generato durante la risoluzione dei problemi. Vengono inoltre fornite le spiegazioni dell'output.

"Serial0 non è attivo, il protocollo di linea non è attivo"

Ciò significa che si è verificato un problema con il cavo, l'unità di servizio del canale/l'unità di servizio dati (CSU/DSU) o la linea seriale. È necessario risolvere il problema con un test di loopback. Per eseguire un test di loopback, attenersi alla seguente procedura:

1. Impostare l'incapsulamento della linea seriale su HDLC e keepalive su 10 secondi. A tale scopo, usare i comandi encapsulation hdlc e keepalive 10 sotto l'interfaccia seriale.

2. Posizionare il CSU/DSU o il modem in modalità di loop locale. Se il protocollo di linea viene attivato quando la CSU, la DSU o il modem si trova in modalità loopback locale (indicata dal messaggio "il protocollo di linea è attivo (con loop)"), il problema si verifica oltre la CSU/DSU locale. Se lo stato della linea di stato non cambia, è possibile che vi sia un problema nel router, nel cavo di connessione, nel CSU/DSU o nel modem. Nella maggior parte dei casi, il problema è causato dalla CSU/DSU o dal modem.

3. Eseguire il ping del proprio indirizzo IP con CSU/DSU o modem a ciclo continuo. Non ci dovrebbero essere mancanze. Un ping esteso di 0x0000 è utile per risolvere i problemi di linea in quanto un T1 o E1 deriva l'orologio dai dati e richiede una transizione ogni 8 bit. B8ZS assicura che. Un pesante modello di dati pari a zero consente di determinare se le transizioni vengono applicate correttamente sul trunk. Un modello di tipo heavy ones viene utilizzato per simulare in modo appropriato un carico elevato pari a zero nel caso in cui vi sia una coppia di invertitori di dati nel percorso. Il motivo alternato (0x5555) rappresenta un motivo dati "tipico". Se i ping hanno esito negativo o se si verificano errori CRC (Cyclic Redundancy Check), è necessario utilizzare un tester di bit error rate (BERT) con un analizzatore appropriato dal teleco.

4. Al termine del test, accertarsi di restituire l'incapsulamento a Frame Relay.

"Serial0 è attivo, il protocollo di linea non è attivo"

Questa linea nell'output indica che il router riceve un segnale vettore dal CSU/DSU o dal modem. Verificare che il provider Frame Relay abbia attivato la porta e che le impostazioni dell'interfaccia di gestione locale (LMI) corrispondano. In genere, lo switch Frame Relay ignora l'apparecchiatura terminale dati (DTE) a meno che non veda la corretta LMI (usare l'impostazione predefinita di Cisco per "cisco" LMI). Verificare che il router Cisco stia trasmettendo i dati. È molto probabile che sia necessario controllare l'integrità della linea utilizzando test di loop in varie posizioni a partire dalla CSU locale e procedendo all'uscita fino a raggiungere lo switch Frame Relay del provider. Per informazioni sull'esecuzione di un test di loopback, vedere la sezione precedente.

"Serial0 è attivo, il protocollo di linea è attivo"

Se l'opzione keepalive non è stata disattivata, questa linea di output indica che il router sta parlando con lo switch del provider Frame Relay. Lo scambio di traffico a due vie sull'interfaccia seriale dovrebbe avere esito positivo e non si dovrebbero verificare errori CRC. I pacchetti keepalive sono necessari in Frame Relay perché sono il meccanismo utilizzato dal router per "conoscere" gli identificatori di connessione (DLCI) dati forniti dal provider. Per guardare lo scambio, è possibile utilizzare in modo sicuro il debug frame-relay lmi in quasi tutte le situazioni. Il comando debug frame-relay lmi genera pochissimi messaggi e può fornire risposte a domande quali:

1. Il router Cisco sta parlando con lo switch Frame Relay locale?

2. Il router riceve messaggi di stato LMI completi per i PVC (Permanent Virtual Circuit) sottoscritti dal provider Frame Relay?

3. I DLCI sono corretti?

Di seguito è riportato un esempio di output lmi debug frame-relay restituito da una connessione riuscita:

*Mar  1 01:17:58.763: Serial0(out): StEnq, myseq 92, yourseen 64, DTE up
*Mar  1 01:17:58.763:  datagramstart = 0x20007C, datagramsize = 14
*Mar  1 01:17:58.763:  FR encap = 0x0001030800 75 95 01 01 01 03 02 5C 40 
*Mar  1 01:17:58.767: 
*Mar  1 01:17:58.815: Serial0(in): Status, myseq 92
*Mar  1 01:17:58.815: RT IE 1, length 1, type 1
*Mar  1 01:17:58.815: KA IE 3, length 2, yourseq 65, myseq 92
*Mar  1 01:18:08.763: Serial0(out): StEnq, myseq 93, yourseen 65, DTE up
*Mar  1 01:18:08.763:  datagramstart = 0x20007C, datagramsize = 14
*Mar  1 01:18:08.763:  FR encap = 0x0001030800 75 95 01 01 01 03 02 5D 41 
*Mar  1 01:18:08.767: 
*Mar  1 01:18:08.815: Serial0(in): Status, myseq 93
*Mar  1 01:18:08.815: RT IE 1, length 1, type 1
*Mar  1 01:18:08.815: KA IE 3, length 2, yourseq 66, myseq 93
*Mar  1 01:18:18.763: Serial0(out): StEnq, myseq 94, yourseen 66, DTE up
*Mar  1 01:18:18.763:  datagramstart = 0x20007C, datagramsize = 14
*Mar  1 01:18:18.763:  FR encap = 0x0001030800 75 95 01 01 00 03 02 5E 42 
*Mar  1 01:18:18.767: 
*Mar  1 01:18:18.815: Serial0(in): Status, myseq 94
*Mar  1 01:18:18.815: RT IE 1, length 1, type 0
*Mar  1 01:18:18.819: KA IE 3, length 2, yourseq 67, myseq 94
*Mar  1 01:18:18.819: PVC IE 0x7 , length 0x3 , dlci 980, status 0x2

Notare lo stato di "DLCI 980" nell'output precedente. Di seguito sono illustrati i possibili valori del campo di stato:

1. 0x0-Added/inactive indica che lo switch ha questo DLCI programmato ma che per qualche motivo (ad esempio, l'altra estremità di questo PVC è spenta), non è utilizzabile.

2. 0x2-Aggiunto/attivo significa che lo switch Frame Relay ha il DLCI e tutto è operativo. È possibile iniziare a inviare il traffico con questo DLCI nell'intestazione.

3. 0x3-0x3 è una combinazione di uno stato attivo (0x2) e dell'RNR (o r-bit) impostato (0x1). Ciò significa che lo switch, o una determinata coda sullo switch, per questo PVC è sottoposto a backup e che la trasmissione viene interrotta in caso di fuoriuscita di frame.

4. 0x4-Deleted indica che lo switch Frame Relay non ha questo DLCI programmato per il router. Ma è stato programmato ad un certo punto nel passato. Ciò può essere causato anche da un'inversione degli elementi DLCI sul router o dall'eliminazione del PVC da parte del telco nel cloud Frame Relay. La configurazione di un DLCI (che lo switch non possiede) verrà visualizzata come 0x4.

5. 0x8-Nuovo/inattivo

6. 0x0a-Nuovo/attivo

Caratteristiche Frame Relay

In questa sezione vengono illustrate diverse caratteristiche di Frame Relay di cui è necessario essere consapevoli.

Controllo orizzonte di divisione IP

Per impostazione predefinita, la verifica dello split-horizon IP è disabilitata per l'incapsulamento Frame Relay, in modo che gli aggiornamenti del routing entrino ed escano dalla stessa interfaccia. I router ricevono informazioni sugli identificatori di connessione (DLCI) che devono utilizzare dallo switch Frame Relay tramite gli aggiornamenti LMI (Local Management Interface). I router quindi utilizzano il protocollo ARP inverso per l'indirizzo IP remoto e creano una mappatura degli elementi DLCI locali e degli indirizzi IP remoti associati. Inoltre, alcuni protocolli come AppleTalk, transparent bridging e IPX non possono essere supportati sulle reti parzialmente mesh perché richiedono lo "split-horizon", in cui un pacchetto ricevuto su un'interfaccia non può essere trasmesso sulla stessa interfaccia, anche se il pacchetto viene ricevuto e trasmesso su circuiti virtuali diversi. La configurazione delle sottointerfacce Frame Relay garantisce che una singola interfaccia fisica venga considerata come più interfacce virtuali. Questa funzionalità consente di superare le regole della divisione degli orizzonti. I pacchetti ricevuti su un'interfaccia virtuale possono ora essere inoltrati su un'altra interfaccia virtuale, anche se sono configurati sulla stessa interfaccia fisica.

Esecuzione del ping del proprio indirizzo IP su un Frame Relay multipoint

Non è possibile eseguire il ping del proprio indirizzo IP su un'interfaccia Frame Relay multipoint. Infatti, a differenza delle interfacce Ethernet e point-to-point HDLC (High-Level Data Link Control), le interfacce multipoint (sub) Frame Relay sono non broadcast e sono sottointerfacce point-to-point Frame Relay.

Inoltre, non è possibile eseguire il ping da uno spoke all'altro in una configurazione hub e spoke. Ciò è dovuto al fatto che non esiste alcuna mappatura per il proprio indirizzo IP (e non ne è stata appresa alcuna tramite il protocollo ARP inverso). Tuttavia, se si configura una mappa statica (utilizzando il comando frame-relay map) per il proprio indirizzo IP (o per uno spoke remoto) in modo da utilizzare il DLCI locale, è possibile eseguire il ping sui dispositivi.

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

   aton#configure terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   aton(config)#interface serial 1
   aton(config-if)#frame-relay map ip 3.1.3.3 160
   aton(config-if)#

   aton#show frame-relay map
   Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
                    broadcast,, status defined, active
   Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,
                    CISCO, status defined, active
   Serial1 (up): ip 3.1.3.3 dlci 160(0xA0,0x2800), static,
                    CISCO, status defined, active
   aton#ping 3.1.3.3     
   
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 64/68/76 ms
   aton#
   aton#show running-config
   !
   interface Serial1
   ip address 3.1.3.3 255.255.255.0
   no ip directed-broadcast
   encapsulation frame-relay
   frame-relay map ip 3.1.3.2 160
   frame-relay map ip 3.1.3.3 160
   frame-relay interface-dlci 160
   !

La trasmissione con parole chiave

La parola chiave broadcast offre due funzioni: inoltra i broadcast quando il multicast non è abilitato e semplifica la configurazione di Open Shortest Path First (OSPF) per le reti non broadcast che utilizzano Frame Relay.

La parola chiave broadcast potrebbe essere richiesta anche per alcuni protocolli di routing, ad esempio AppleTalk, che dipendono da aggiornamenti regolari della tabella di routing, in particolare quando il router dell'estremità remota attende l'arrivo di un pacchetto di aggiornamento del routing prima di aggiungere il routing.

Richiedendo la selezione di un router designato, OSPF tratta una rete multi-accesso non broadcast, come Frame Relay, nello stesso modo in cui tratta una rete broadcast. Nelle versioni precedenti, questa operazione richiedeva l'assegnazione manuale nella configurazione OSPF utilizzando il comando neighbors interface router. quando il comando frame-relay map è incluso nella configurazione con la parola chiave broadcast e il comando ip ospf network (con la parola chiave broadcast) è configurato, non è necessario configurare manualmente alcun router adiacente. OSPF ora viene eseguito automaticamente sulla rete Frame Relay come rete di trasmissione. Per ulteriori informazioni, vedere il comando ip ospf network interface.

Nota: il meccanismo di trasmissione OSPF presuppone che gli indirizzi IP di classe D non vengano mai utilizzati per il traffico regolare su Frame Relay.

Esempio

L'esempio che segue mappa l'indirizzo IP di destinazione 172.16.123.1 a DLCI 100:

interface serial 0
 frame-relay map IP 172.16.123.1 100 broadcast 

OSPF utilizza DLCI 100 per trasmettere gli aggiornamenti.

Riconfigurazione di una sottointerfaccia

Dopo aver creato un tipo specifico di sottointerfaccia, non è possibile modificarla senza ricaricarla. Ad esempio, non è possibile creare un'interfaccia multipunto serial0.2, quindi modificarla in point-to-point. Per modificarlo, è necessario ricaricare il router o creare un'altra sottointerfaccia. Questo è il modo in cui funziona il codice Frame Relay nel software Cisco IOS®.

Limitazioni DLCI

Spazio indirizzi DLCI

È possibile configurare circa 1000 DLCI su un singolo collegamento fisico, in base a un indirizzo a 10 bit. Poiché alcuni DLCI sono riservati (dipendenti dall'implementazione del fornitore), il massimo è circa 1000. L'intervallo per un LMI Cisco è 16-1007. L'intervallo specificato per ANSI/ITU è 16-992. Si tratta dei DLCI che contengono i dati utente.

Tuttavia, quando si configurano i VC Frame Relay sulle sottointerfacce, è necessario prendere in considerazione un limite pratico noto come limite IDB. Il numero totale di interfacce e sottointerfacce per sistema è limitato dal numero di IDB (Interface Descriptor Block) supportati dalla versione in uso di Cisco IOS. Un IDB è una porzione della memoria che contiene informazioni sull'interfaccia quali contatori, stato dell'interfaccia e così via. IOS gestisce un IDB per ciascuna interfaccia presente su una piattaforma e mantiene un IDB per ciascuna sottointerfaccia. Le interfacce a velocità più elevata richiedono una maggiore quantità di memoria rispetto alle interfacce a velocità inferiore. Ogni piattaforma contiene quantità diverse di IDB massimi che possono variare a seconda della versione di Cisco IOS.

Per ulteriori informazioni, vedere Numero massimo di interfacce e sottointerfacce per piattaforme software Cisco IOS: limiti IDB.

Aggiornamento stato LMI

Il protocollo LMI richiede che tutti i report sullo stato del PVC (Permanent Virtual Circuit) rientrino in un singolo pacchetto e in genere limitino il numero di DLCI a meno di 800, a seconda delle dimensioni della MTU (Maximum Transmission Unit).

L'MTU predefinita sulle interfacce seriali è di 1500 byte, con un massimo di 296 DLCI per interfaccia. È possibile aumentare l'MTU per supportare un messaggio di aggiornamento dello stato completo più grande inviato dal Frame Relay switch. Se il messaggio di aggiornamento dello stato completo è più grande dell'MTU dell'interfaccia, il pacchetto viene scartato e il contatore del gigante dell'interfaccia viene incrementato. Quando si modifica l'MTU, verificare che sul router remoto e sui dispositivi di rete interessati sia configurato lo stesso valore.

Questi numeri variano leggermente a seconda del tipo di LMI. Di seguito sono elencate le linee guida relative al numero massimo di DLCI per piattaforma router (non di interfaccia), basate su estrapolazioni da dati empirici stabiliti su una piattaforma router Cisco 7000:

• Cisco 2500: 1 collegamento T1/E1 a 60 DLCI per interfaccia = 60 totali

• Cisco 4000: 1 collegamento T1/E1 a 120 DLCI per interfaccia = 120 totali

• Cisco 4500: 3 collegamenti T1/E1 a 120 DLCI per interfaccia = 360 totali

• Cisco 4700: 4 collegamenti T1/E1 a 120 DLCI per interfaccia = 480 totali

• Cisco 7000: 4 collegamenti X T1/E1/T3/E3 a 120 DLCI per interfaccia = 480 totali

• Cisco 7200: 5 collegamenti T1/E1/T3/E3 a 120 DLCI per interfaccia = 600 totali

• Cisco 7500: 6 collegamenti X T1/E1/T3/E3 a 120 DLCI per interfaccia = 720 totali

Nota: questi numeri sono solo linee guida e si presume che tutto il traffico sia a commutazione rapida.

Altre considerazioni

Il limite pratico del DLCI dipende anche dal fatto che i VC eseguano un protocollo di routing dinamico o statico. I protocolli di routing dinamico e altri protocolli come IPX SAP che scambiano tabelle di database inviano hellos e messaggi informativi di inoltro che devono essere visualizzati ed elaborati dalla CPU. In generale, l'utilizzo di route statiche consente di configurare un numero maggiore di VC su una singola interfaccia Frame Relay.

Indirizzo IP/IPX/AT

Se si utilizzano sottointerfacce, non inserire un indirizzo IP, IPX o AT sull'interfaccia principale. Assegnare i DLCI alle relative sottointerfacce prima di abilitare l'interfaccia principale per garantire il corretto funzionamento del frame relay inverse-arp. In caso di malfunzionamento, procedere come segue:

1. Disattivare il protocollo ARP (Inverse Address Resolution Protocol) per tale DLCI utilizzando i comandi no frame-relay inverse-arp ip 16 e clear frame-relay-inarp.

2. Correggere la configurazione.

3. Attivare di nuovo il comando frame-relay inverse-arp.

RIP e IGRP

Il flusso degli aggiornamenti RIP (Routing Information Protocol) viene aggiornato ogni 30 secondi. Ogni pacchetto RIP può contenere fino a 25 voci di route, per un totale di 536 byte; 36 byte di questo totale sono informazioni di intestazione e ogni voce di route è 20 byte. Pertanto, se si annunciano 1000 route su un collegamento Frame Relay configurato per 50 DLCI, il risultato sarà 1 MB di dati di aggiornamento del routing ogni 30 secondi o 285 kbps di larghezza di banda utilizzata. Su un collegamento T1, questa larghezza di banda rappresenta il 18,7% della larghezza di banda, con una durata di aggiornamento di 5,6 secondi. Questa quantità di sovraccarico è considerevole, ed è al limite accettabile, ma il tasso di informazioni impegnate (CIR, Committed Information Rate) dovrebbe essere nell'area della velocità di accesso. Ovviamente, un valore inferiore a un T1 comporterebbe un sovraccarico eccessivo. Ad esempio:

• 1000/25 = 40 pacchetti X 36 = 1440 byte di intestazione

• 1000 X 20 byte = 20.000 byte di voci di route

• Totale 21.440 byte X 50 DLCI = 1072 MB di aggiornamenti RIP ogni 30 secondi

• 1.072.000 byte / 30 sec X 8 bit = 285 kbps

Il protocollo IGRP (Interior Gateway Routing Protocol) aggiorna il flusso ogni 90 secondi (questo intervallo è configurabile). Ogni pacchetto IGRP può contenere 104 voci di route, per un totale di 1492 byte, 38 delle quali sono informazioni di intestazione, e ogni voce di route è 14 byte. Se si pubblicizzano 1000 route su un collegamento Frame Relay configurato con 50 DLCI, la richiesta corrisponde a circa 720 KB di dati di aggiornamento del routing ogni 90 secondi o a 64 kbps di larghezza di banda utilizzata. Su un collegamento T1, questa larghezza di banda rappresenterebbe il 4,2% della larghezza di banda, con una durata di aggiornamento di 3,7 secondi. Questo costo comune è un importo accettabile:

• 1000/104 = 9 pacchetti X 38 = 342 byte di intestazione

• 1000 X 14 = 14.000 byte di voci di route

• Totale = 14.342 byte X 50 DLCI = 717 KB di aggiornamenti IGRP ogni 90 secondi

• 717.000 byte / 90 X 8 bit = 63,7 kbps

Gli aggiornamenti del routing RTMP (Routing Table Maintenance Protocol) vengono eseguiti ogni 10 secondi (questo intervallo è configurabile). Ogni pacchetto RTMP può contenere fino a 94 voci di route estese, per un totale di 564 byte, 23 byte di informazioni di intestazione e ogni voce di route è 6 byte. Se si pubblicizzano 1000 reti AppleTalk su un collegamento Frame Relay configurato per 50 DLCI, il risultato sarà circa 313 KB di aggiornamenti RTMP ogni 10 secondi, o 250 kbps di larghezza di banda utilizzata. Per rimanere entro un livello accettabile di sovraccarico pari o inferiore al 15%), è necessario un tasso T1. Ad esempio:

• 1000/94 = 11 pacchetti X 23 byte = 253 byte di intestazione

• 1000 X 6 = 6000 byte di voci di route

• Totale = 6.253 X 50 DLCI = 313 KB di aggiornamenti RTMP ogni 10 secondi

• 313.000 / 10 sec X 8 bit = 250 kbps

Gli aggiornamenti dei pacchetti RIP IPX vengono eseguiti ogni 60 secondi (questo intervallo è configurabile). Ogni pacchetto RIP IPX può contenere fino a 50 voci di route per un totale di 536 byte, 38 byte di informazioni di intestazione e ogni voce di route è di 8 byte. Se si pubblicizzano 1000 route IPX su un collegamento Frame Relay configurato per 50 DLCI, il risultato sarà 536 KB di aggiornamenti IPX ogni 60 secondi o 58,4 kbps di larghezza di banda utilizzata. Per rimanere entro un livello accettabile di sovraccarico (15 per cento o meno), è necessaria una velocità di 512 kbps. Ad esempio:

• 1000/50 = 20 pacchetti X 38 byte = 760 byte di intestazione

• 1000 X 8 = 8000 byte di voci di route

• Totale = 8.760 X 50 DLCI = 438.000 byte di aggiornamenti IPX ogni 60 secondi

• 438.000 / 60 sec X 8 bit = 58,4 kbps

Gli aggiornamenti dei pacchetti SAP (Service Access Point) IPX vengono eseguiti ogni 60 secondi (questo intervallo è configurabile). Ogni pacchetto SAP IPX può contenere fino a sette voci pubblicitarie per un totale di 536 byte, 38 byte di informazioni di intestazione e ogni voce pubblicitaria è pari a 64 byte. Se si trasmettono annunci 1000 IPX su un collegamento Frame Relay configurato per 50 DLCI, si ottengono 536 KB di aggiornamenti IPX ogni 60 secondi, ovvero 58,4 kbps di larghezza di banda utilizzata. Per rimanere entro un livello accettabile di sovraccarico (15% o meno), è necessaria una velocità superiore a 2 Mbps. Ovviamente, in questo scenario è richiesto il filtro SAP. Rispetto a tutti gli altri protocolli menzionati in questa sezione, gli aggiornamenti SAP IPX richiedono la larghezza di banda più elevata:

• 1000/7 = 143 pacchetti X 38 byte = 5434 byte di intestazione

• 1000 X 64 = 64.000 byte di voci di route

• Totale = 69.434 X 50 DLCI = 3.471.700 byte di annunci di servizi IPX ogni 60 secondi

• 3.471.700 / 60 sec X 8 bit = 462 kbps

Mantenimento attività

In alcuni casi, il valore keepalive sul dispositivo Cisco deve essere impostato su un valore leggermente più breve (circa 8 secondi) rispetto a quello impostato sullo switch. Questa operazione è necessaria se l'interfaccia continua a spostarsi verso l'alto o verso il basso.

Interfacce seriali

Le interfacce seriali, che per impostazione predefinita sono multipunto, sono supporti non broadcast, mentre le sottointerfacce point-to-point sono broadcast. Se si utilizzano route statiche, è possibile puntare all'hop successivo o alla sottointerfaccia seriale. Per il multipoint, è necessario puntare all'hop successivo. Questo concetto è molto importante quando si esegue OSPF su Frame Relay. Il router deve sapere che si tratta di un'interfaccia di broadcast per il funzionamento di OSPF.

OSPF e multipoint

OSPF e multipoint possono causare problemi. Il protocollo OSPF richiede un router designato (DR). Se si inizia a perdere i PVC, alcuni router potrebbero perdere la connettività e cercare di diventare un DR anche se altri router continuano a vedere il vecchio DR. Il processo OSPF non funziona correttamente.

Il sovraccarico associato a OSPF non è così ovvio e prevedibile come quello dei protocolli tradizionali di routing dei vettori di distanza. L'imprevedibilità deriva dalla stabilità o meno dei collegamenti di rete OSPF. Se tutte le adiacenze di un router Frame Relay sono stabili, passeranno solo i pacchetti hello adiacenti (keepalive), ovvero un sovraccarico relativamente inferiore rispetto a quello generato da un protocollo di vettore di distanza (ad esempio RIP e IGRP). Se, tuttavia, i percorsi (adiacenze) sono instabili, si verificherà un allagamento dello stato del collegamento e la larghezza di banda potrà essere utilizzata rapidamente. OSPF richiede inoltre un utilizzo intensivo del processore durante l'esecuzione dell'algoritmo Dijkstra, utilizzato per l'elaborazione delle route.

Nelle versioni precedenti del software Cisco IOS, era necessario prestare particolare attenzione quando si configura OSPF su supporti non broadcast ad accesso multiplo come Frame Relay, X.25 e ATM. Il protocollo OSPF considera questi supporti come qualsiasi altro supporto di trasmissione come Ethernet. I cloud NBMA (Nonbroadcast multiaccess) sono in genere incorporati in una topologia hub e spoke. I PVC o i circuiti virtuali commutati (SVC) sono disposti in una mesh parziale e la topologia fisica non fornisce il multiaccesso che OSPF ritiene sia presente. Nel caso delle interfacce seriali point-to-point, OSPF forma sempre un'adiacenza tra le vicine. Le adiacenze OSPF scambiano informazioni sul database. Per ridurre al minimo la quantità di informazioni scambiate su un particolare segmento, l'interfaccia OSPF sceglie un router come DR e un router come BDR (Backup Designed Router) su ciascun segmento multiaccesso. Il BDR viene scelto come meccanismo di backup in caso il router designato diventasse inattivo.

L'idea alla base di questa configurazione è che i router hanno un punto di contatto centrale per lo scambio di informazioni. La selezione del DR è diventata un problema perché il DR e il BDR devono avere una connettività fisica completa con tutti i router esistenti sul cloud. Inoltre, a causa della mancanza di capacità di trasmissione, il DR e il BDR dovevano avere un elenco statico di tutti gli altri router collegati al cloud. Per eseguire questa configurazione, usare il comando neighbors:

indirizzo-ip router adiacente [numero priorità] [secondi intervallo di polling]

Nelle versioni più recenti del software Cisco IOS, è possibile utilizzare metodi diversi per evitare le complicazioni derivanti dalla configurazione di router adiacenti statici e dalla possibilità che router specifici diventino DR o BDR sul cloud non broadcast. Il metodo da utilizzare dipende dal fatto che la rete sia nuova o da un progetto esistente da modificare.

Una sottointerfaccia è un modo logico di definire un'interfaccia. La stessa interfaccia fisica può essere suddivisa in più interfacce logiche, ognuna delle quali definita point-to-point. Questo scenario è stato creato inizialmente per gestire meglio i problemi causati dalla divisione dell'orizzonte su NBMA e dai protocolli di routing basati su vettori.

Una sottointerfaccia point-to-point ha le proprietà di qualsiasi interfaccia point-to-point fisica. Per quanto riguarda il protocollo OSPF, si forma sempre una adiacenza su una sottointerfaccia point-to-point senza scelta di DR o BDR. OSPF considera il cloud un insieme di collegamenti point-to-point anziché una rete ad accesso multiplo. L'unico svantaggio del point-to-point è che ogni segmento appartiene a una subnet diversa. Questo scenario potrebbe non essere accettabile perché alcuni amministratori hanno già assegnato una subnet IP per l'intero cloud. Un'altra soluzione consiste nell'utilizzare interfacce IP non numerate sul cloud. Questo scenario potrebbe inoltre rappresentare un problema per alcuni amministratori che gestiscono la WAN in base agli indirizzi IP delle linee seriali.

Fonti

1. International Telegraph and Telephone Consultative Committee, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", CCITT Recommendation Q.922, 19 aprile 1991.

2. American National Standard For Telecommunications - Integrated Services Digital Network - Aspetti principali del protocollo Frame per l'uso con Frame Relay Bearer Service, ANSI T1.618-1991, 18 giugno 1991.

3. Tecnologia dell'informazione - Telecomunicazioni e scambio di informazioni tra sistemi - Identificazione del protocollo a livello di rete, ISO/IEC TR 9577: 1990 (E) 1990-10-15.

4. Standard internazionale, Sistemi di elaborazione delle informazioni - Reti locali - Controllo collegamento logico, ISO 8802-2: 1989 (E), IEEE Std 802.2-1989, 1989-12-31.

5. Panoramica sulla tecnologia di internetworking, ottobre 1994, Cisco Systems

6. Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, Stanford University, giugno 1984.

7. Postel, J. and Reynolds, J., "Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information Sciences Institute, febbraio 1988.

8. RFC 1490-1490 - Incapsulamento multiprotocollo

9. RFC 1315-Frame Relay MIB

10. RFC 1293-Frame Relay - ARP inverso

11. RFC 1144-Compressione header TCP/IP

12. Forum Frame Relay (FRF) 1.1-Interfaccia UNI (User-Network Interface)

13. FRF 2.1-Frame Relay Network-to-Network Interface (NNI)

14. FRF 3.1-Incapsulamento multiprotocollo

15. FRF 4-SVC

16. FRF 6-Frame Relay service customer network management (MIB)

17. Banda di quattro LMI

18. Q.922 Allegato A

19. ANSI T1.617 Allegato D

20. ANSI T1,618, T1,606

21. ITU-T Q.933, Q.922

22. Guida alla progettazione OSPF

23. Note sulla configurazione per l'implementazione migliorata del protocollo IGRP migliorato

Informazioni correlate

• Ulteriori informazioni sui comandi Frame Relay
• Ulteriori informazioni sulla configurazione di Frame Relay
• Ulteriori informazioni sui comandi di dial-backup
• Ulteriori informazioni sui comandi di debug ISDN
• Ulteriori informazioni sui comandi di debug PPP
• Ulteriori informazioni sui tipi, i codici e i valori degli switch ISDN
• Documentazione e supporto tecnico – Cisco Systems