WAN : Frame Relay

Guía exhaustiva al Configurando y Troubleshooting Frame Relay

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Traducción Manual (19 Mayo 2008) | Inglés (22 Agosto 2015) | Comentarios


Interactivo: Este documento ofrece un análisis personalizado de su dispositivo Cisco.


Contenido


Introducción

Frame Relay es un estándar de la industria, el protocolo de capa de link de datos conmutados que maneja varios circuitos virtuales mediante encapsulación HDLC (High-Level Data Link Control) entre los dispositivos conectados. En muchos casos, Frame Relay es más eficiente que X.25, protocolo del que generalmente se considera un sustituto. La siguiente figura ilustra una trama de Frame Relay (ANSI T1.618).

/image/gif/paws/16563/13a.gif

Observe en la figura antedicha, los direccionamientos Q.922, según lo definido actualmente, sea dos octetos y contenga un identificador de conexión de link de datos 10-bit (DLCI). En los direccionamientos de algunas redes Q.922 puede ser aumentado opcionalmente a tres o cuatro octetos.

Los campos del “indicador” delimitan el principio y el extremo del bastidor. Después del campo “indicador” principal son dos bytes de información de dirección. Diez bits de estos dos bytes componen el circuit id real (llamado el DLCI, para el identificador de conexión de link de datos).

El valor de DLCI 10-bit es el corazón del encabezado de Frame Relay. Identifica la conexión lógica que se multiplexa en el canal físico. En (es decir, no extendido por el [LMI] de la interfaz de administración local) el modo básico de dirección, los DLCI tienen importancia local; es decir, los dispositivos extremos en dos diversos extremos de una conexión pueden utilizar un diverso DLCI para referirse que la misma conexión.

Antes de comenzar

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

prerrequisitos

Para más información y definiciones para los términos usados en este documento, refiera por favor al glosario de Frame Relay.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Teoría Precedente

El Frame Relay fue concebido originalmente como protocolo para el uso sobre las interfaces de ISDN. Las ofertas iniciales a este efecto fueron sometidas al sector de estandarización de telecomunicación de la unión internacional de telecomunicaciones (ITU-T) (antes el Comité de consulta para la telegrafía y telefonía internacional [CCITT]) en 1984. El trabajo sobre el Frame Relay también fue emprendido en el comité regulatorio ANSI-acreditado T1S1 en los Estados Unidos.

En 1990, Cisco Systems, Stratacom, Northern Telecom, y Digital Equipment Corporation formaron un consorcio para enfocar el desarrollo de tecnología de Frame Relay y para acelerar la introducción de Productos operables interes del Frame Relay. Desarrollaron una especificación conforme al protocolo del Frame Relay básico que era discutido en el T1S1 y el ITU-T, pero ampliado le con las características que proporcionan los entornos de funcionamiento entre redes adicionales de las capacidades para complejo. Estas Extensiones del Frame Relay se refieren colectivamente como el LMI. Éste es el “Cisco” LMI en el router en comparación con el “ANSI” o el "q933a" LMI.

El Frame Relay proporciona una capacidad de conmutación de conjunto de bits de las comunicaciones de datos que se utilice a través de la interfaz entre los dispositivos del usuario (tales como Routers, Bridges, equipos del host) y el equipo de red (tal como nodos de Switching). Los dispositivos del usuario se refieren a menudo como equipo de terminal de datos (DTE), mientras que el equipo de red que interconecta al DTE se refiere a menudo como equipo circuito-terminal de los datos (DCE). La red que proporciona a la interfaz de Frame Relay puede ser portador-proporcionó a la red pública o a una red del equipo de propiedad privada que sirve una sola empresa.

El Frame Relay diferencia perceptiblemente del X.25 en sus funciones y formato. Particularmente, el Frame Relay es un protocolo más aerodinámico, facilitando el mayor rendimiento y la mayor eficacia.

Como interfaz entre el usuario y el equipo de red, el Frame Relay proporciona los medios para estadístico multiplexar muchas conversaciones de los datos lógicos (designadas los circuitos virtuales) sobre un solo link de transmisión físico. Esto pone en contraste con los sistemas que utilizan solamente las técnicas del time-division-multiplexing (TDM) para soportar las secuencias de datos múltiples. La multiplexión estadística del Frame Relay proporciona un uso más flexible y más eficiente del ancho de banda disponible. Puede ser utilizada sin las técnicas de TDM o encima de los canales proporcionados por los sistemas TDM.

Otra característica importante del Frame Relay es que explota los avances recientes en tecnología de transmisión del Red de área ancha (WAN). Protocolos anteriores WAN, tales como X.25, fueron desarrollados cuando los sistemas de transmisión analógica y los media de cobre eran predominantes. Estos links son mucho menos confiables que los medios de fibra/los links de la transmisión digital disponibles hoy. Sobre los links tales como éstos, los protocolos de la capa del link pueden renunciar los algoritmos largos de la corrección de errores, dejando éstos que se realizarán en capas del protocolo más altas. El mayores funcionamiento y eficacia es por lo tanto posibles sin sacrificar la integridad de los datos. El Frame Relay se diseña con este acercamiento en la mente. Incluye un algoritmo de la verificación por redundancia cíclica (CRC) para detectar los bits corrompidos (así que los datos puede ser desechado), pero no incluye ninguna mecanismos del protocolo para corregir los malos datos (por ejemplo, retransmitiéndolo a este nivel del protocolo).

Otra diferencia entre el Frame Relay y el X.25 es la ausencia de explícito, control de flujo del Per-Virtual Circuit en el Frame Relay. Ahora que muchos protocolos de la capa superiores están ejecutando con eficacia sus propios Algoritmos de control de flujo, la necesidad de estas funciones en la capa de link ha disminuido. El Frame Relay, por lo tanto, no incluye los procedimientos de control de flujo explícitos que duplican ésos en las capas superiores. En lugar, los mecanismos muy simples de la notificación de congestión se proporcionan para permitir que una red informe a un dispositivo del usuario que los recursos de red están cercanos a un estado de congestión. Esta notificación puede alertar los protocolos de capa más altas que el control de flujo puede ser necesario.

Configuración de Basic Frame Relay

Una vez que usted tiene conexiones confiables al switch de Frame Relay local en los ambos extremos del circuito virtual permanente (PVC), después es hora de comenzar a planear la configuración de Frame Relay. En este primer ejemplo, la Interfaz de administración local (LMI) - el tipo omite “Cisco” LMI en el Spicey. Una interfaz es por abandono una interfaz “de múltiples puntos” así pues, ARP-inverso del Frame Relay está prendido (para el Punto a punto, no hay ARP inverso). El marcar partido del horizonte IP se inhabilita por abandono para la Encapsulación de Frame Relay, así que las actualizaciones de ruteo vienen en y hacia fuera lo mismo interconectan. El Routers aprende que los identificadores de conexión de link de datos (DLCI) que él necesita utilizar del switch de Frame Relay vía las actualizaciones LMI. El Routers entonces ARP inverso para el IP Address remoto y crea un mapeo de DLCI local y sus IP Address remotos asociados.

Diagrama de la red

14.gif

Configuraciones

Spicey
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
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

Comandos debug y show

Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.

  • show frame-relay map

  • show frame-relay pvc

  • show frame-relay lmi

  • name> del <device del ping

  • 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

Configuración hub and spoke para Frame Relay

En este ejemplo, el router aprende qué identificadores de conexión de link de datos (DLCI) utiliza del switch de Frame Relay y asigna los a la interfaz principal. Entonces el router ARP inverso para el IP Address remoto.

Nota: Usted no podrá hacer ping la dirección IP serial de Prasit de Aton a menos que usted agregue explícitamente en las correspondencias del Frame Relay en cada extremo. Si rutea se configura correctamente, el tráfico que origina en los LAN no debe tener un problema. Usted podrá hacer ping si usted utiliza el Ethernet IP Address como la dirección de origen en un ping extendido.

Cuando se habilita el ARP-inverso del Frame Relay, el tráfico del IP de broadcast saldrá sobre la conexión por abandono.

Diagrama de la red

15a.gif

Configuraciones

Spicey
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
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
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

Comandos show

  • show frame-relay map

  • show frame-relay pvc

  • name> del <device del ping

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)

Conexión de radio a radio

Usted no puede hacer ping a partir de la uno habló a otro spoke en una configuración del hub and spoke usando las interfaces multipunto porque no hay asignación para los IP Addresses de los otros rayos. Solamente el direccionamiento del concentrador es docto vía el protocolo inverse address resolution (IARP). Si usted configura una correlación estática usando el comando frame-relay map para la dirección IP de una conexión remota de utilizar el Identificador de conexión del link de datos local (DLCI), usted puede hacer ping los direccionamientos del otro spokes.

/image/gif/paws/16563/15b.gif

Configuraciones

Prasit
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

Comandos show

  • show frame-relay map

  • name> del <device del ping

  • 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

Configuración de subinterfaces para Frame Relay

Las subinterfaces del Frame Relay proporcionan un mecanismo para soportar parcialmente las redes del frame relay de malla. La mayoría de los protocolos asumen la transitividad en una red lógica; es decir, si la estación A puede hablar para colocar B, y la estación B puede hablar para colocar el C, después coloca A debe poder hablar para colocar el C directamente. La transitividad es verdad en los LAN, pero no en las redes Frame Relay a menos que A esté conectada directamente con el C.

Además, ciertos protocolos, tales como APPLETALK y Puente transparente, no se pueden soportar en parcialmente las redes malladas porque requieren “parten el horizonte” en cuál no se puede transmitir un paquete recibido en una interfaz hacia fuera la misma interfaz incluso si el paquete se recibe y se transmite en diversos circuitos virtuales.

Configurar las subinterfaces del Frame Relay se asegura de que una sola interfaz física está tratada como interfaces virtuales múltiples. Esta capacidad permite que superemos las reglas de división del horizonte. Los paquetes recibidos en una interfaz virtual se pueden ahora remitir hacia fuera otra interfaz virtual, incluso si se configuran en la misma interfaz física.

Las subinterfaces dirigen las limitaciones de las redes Frame Relay proporcionando a una manera de subdividir parcialmente una red del frame relay de malla en varios (o Punto a punto) redes secundarios más pequeños, completamente enredados. Cada red secundario se asigna su propio network number y aparece a los protocolos como si sea accesible a través de una interfaz diferente. (Nota que las subinterfaces punto a punto pueden ser innumerables para el uso con el IP, reduciendo la carga de dirección que pudo de otra manera resultado).

Subinterfaces punto a punto

Diagrama de la red

16b.gif

Configuraciones

Spicey
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
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

Comandos show

  • show frame-relay map

  • 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

Subinterfaces hub y spoke

La configuración de muestra siguiente del hub and spoke muestra dos subinterfaces punto a punto y utiliza la resolución de dirección dinámica en un sitio remoto. Cada subinterfaz se proporciona una dirección de protocolo y un subnet mask individuales, y el comando interface-dlci asocia la subinterfaz a un identificador de conexión de link de datos especificado (DLCI). Los direccionamientos de los destinos remotos para cada subinterfaz punto a punto no se resuelven puesto que son de punto a punto y el tráfico se debe enviar al par en el otro extremo. El extremo remoto (Aton) utiliza el ARP inverso para su asignación y el eje de conexión principal responde por consiguiente con la dirección IP de la subinterfaz. Esto ocurre porque el Frame Relay ARP inverso está prendido por abandono para las interfaces multipunto.

Diagrama de la red

/image/gif/paws/16563/16a.gif

Configuraciones

Spicey
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
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
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

Comandos show

  • show frame-relay map

  • 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

Configuración de correspondencia dinámica y estática para subinterfaces multipunto

La correspondencia de direcciones dinámica utiliza el Frame Relay ARP inverso para pedir a la dirección de protocolo del salto siguiente para una conexión específica, dada un identificador de conexión de link de datos (DLCI). Las respuestas a las solicitudes de ARP inverso se ingresan en una tabla de mapping de dirección a DLCI en el router o el servidor de acceso; la tabla entonces se utiliza para suministrar la dirección de protocolo del salto siguiente o el DLCI para el tráfico saliente.

Puesto que la interfaz física ahora se configura como subinterfaces múltiples, usted debe proporcionar la información que distingue una subinterfaz de la interfaz física y asocia una subinterfaz específica a un DLCI específico.

El ARP inverso se habilita de forma predeterminada para todos los protocolos que soporta, pero se puede inhabilitar para los pares específicos DLCI del protocolo. Como resultado, puede utilizar mapping dinámico para algunos protocolos y mapping estático para otros protocolos en el mismo DLCI. Usted puede inhabilitar explícitamente el ARP inverso para un par protocolo-DLCI si usted sabe que el protocolo no está soportado en el otro extremo de la conexión. Porque el ARP inverso se habilita por abandono para todos los protocolos que soporte, no se requiere a ningún comando adicional configurar la correspondencia de direcciones dinámica en una subinterfaz. Una correlación estática conecta a una dirección de protocolo especificada del salto siguiente a un DLCI especificado. El mapping estático remueve la necesidad de solicitudes de ARP Inverso; cuando suministra un mapa estático, el ARP inverso se inhabilita automáticamente para el protocolo especificado en la DLCI especificada. Debe utilizar la asignación estática si el router del otro extremo no soporta ARP Inverso en absoluto o no soporta ARP Inverso para un protocolo específico que se desee utilizar sobre Frame Relay.

Diagrama de la red

Hemos visto ya cómo configurar a un router Cisco para hacer el ARP inverso. El siguiente ejemplo muestra cómo configurar las correlaciones estáticas en caso de que usted las necesite para las interfaces multipunto o las subinterfaces:

17.gif

Configuraciones

Aton
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
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
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

Comandos debug y show

  • show frame-relay map

  • 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

Para más información sobre estos comandos, vea por favor los comandos frame relay.

Configuración del Frame Relay sin números de IP

Si usted no tiene el espacio de IP Address para utilizar muchas subinterfaces, usted puede utilizar el IP innumerable en cada subinterfaz. Si éste es el caso, usted necesita utilizar las Static rutas o el Dynamic Routing para rutear su tráfico como de costumbre, y usted debe utilizar las subinterfaces punto a punto.

Diagrama de la red

El ejemplo abajo ilustra esto:

/image/gif/paws/16563/18.gif

Configuraciones

Spicey
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
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

Comandos show

  • show frame-relay map

  • 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

Configuración de respaldo para Frame Relay

Respaldo de retransmisión de tramas sobre ISDN

Usted puede querer sostener los circuitos de Frame Relay usando el ISDN. Hay varias maneras de hacer esto. El primer, y probablemente el mejor, es utilizar las Rutas estáticas flotantes que rutean el tráfico a una dirección IP del Basic Rate Interface (BRI) y utilizan una métrica de ruteo apropiada. Usted puede también utilizar una Interfaz de respaldo en la interfaz principal o sobre una base del Identificador de conexión del por-DATA-link (DLCI). Puede no ayudar a mucho para sostener la interfaz principal porque usted podría perder los circuitos virtuales permanentes (PVC) sin la interfaz principal que iba abajo. Recuerde, el protocolo se está intercambiando por el switch de Frame Relay local, no el router remoto.

/image/gif/paws/16563/wan_isdn_bu_fr.gif

Configuraciones

Router 1
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
!

Router 2
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
!

Comandos show

Para verificar si el ISDN está trabajando, utilice los comandos debug siguientes. Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.

  • debug isdn q931

  • debug ppp neg

  • debug ppp auth

Intente hacer una llamada ISDN de la parte que llama al lado central sin los comandos backup. Si esto es acertado, agregue los comandos backup a la parte que llama.

Nota: Para probar el respaldo, no utilice el comando shutdown en la interfaz serial sino emule a un problema en la línea serial real sacando el cable de la línea serial.

Configuración por copia de seguridad de DCLI

Ahora déjenos asumen que el Spicey es el lado central y que el Prasit es el lado que hace las conexiones al lado central (Spicey). Tome el cuidado que usted agrega solamente los comandos backup al lado que está llamando al lado central.

Nota:  La carga de backup no se soporta en las subinterfaces. Pues no seguimos los niveles de tráficog en las subinterfaces, no se calcula ninguna carga.

Diagrama de la red

19c.gif

Configuraciones

Spicey
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
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

Comandos show

  • show frame-relay map

  • show ip route

  • muestre el historial isdn

  • mostrar estado isdn

  • show interface bri0

  • muestre el active isdn

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 línea serial va abajo.

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 conexión en serie está detrás otra vez.

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

Red radial con perfiles de marcador

Aquí está un ejemplo de un hub and spoke por configuración de respaldo DLCI. Los routeres radiales están llamando al router de eje de conexión. Como usted puede ver, permitimos solamente un canal B por el lado usando la opción de link máximo en los recursos compartidos de dialers en el lado del eje de conexión.

Nota: La carga de backup no se soporta en las subinterfaces. Pues no seguimos los niveles de tráficog en las subinterfaces, no se calcula ninguna carga.

Diagrama de la red

19b.gif

Configuraciones

Aton
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
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
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

Comandos show

  • show frame-relay map

  • show ip route

  • show frame map

  • 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#   

El Serial1 va abajo.

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#

El Serial1 llega a ser activo otra vez

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

Ambas líneas seriales de las partes que llamas van abajo.

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#

Ambas líneas seriales están disponibles otra vez.

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#

El Serial1 va abajo.

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#

El Serial1 llega a ser activo otra vez.

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

Configuración del switching de Frame Relay

El Switching de Frame Relay es los medios de los paquetes de la transferencia basados en el identificador de conexión de link de datos (DLCI). Podemos mirar en esto como el equivalente del Frame Relay de un Media Access Control (MAC) Address. Usted realiza la transferencia configurando su router Cisco o servidor de acceso en una red Frame Relay. Hay dos porciones a una red Frame Relay:

  • Equipo de terminal de datos de Frame Relay (DTE) - el router o el servidor de acceso.

  • Switch circuito-terminal del equipo de los datos del Frame Relay (DCE).

Nota:  En el Cisco IOS Software Release 12.1(2)T y Posterior, al comando connect ha substituido al comando frame route.

Miremos una configuración de muestra. En la configuración abajo, estamos utilizando al router America como switch de Frame Relay. Estamos utilizando el Spicey como un router de eje de conexión y Prasit y Aton como routeres radiales. Los hemos conectado como sigue:

  • El número de serie de Prasit 1 (s1) DTE está conectado con el número de serie de EE. UU. 1/4 (s1/4) DCE.

  • El serial Spicey 0 (s0) DTE está conectado con el número de serie de EE. UU. 1/5 (s1/5) DCE.

  • El número de serie Aton 1 (s1) DTE está conectado con el número de serie de EE. UU. 3/4 (s3/4) DCE.

Diagrama de la red

Este documento se basa en la siguiente configuración:

/image/gif/paws/16563/fr_switching.gif

Configuraciones

Spicey
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
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
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

América
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
!

Comandos show

Utilice los comandos show siguientes de probar que su red está actuando correctamente:

  • show frame-relay map

  • show frame-relay pvc

La salida mostrada abajo es un resultado de ingresar estos comandos en los dispositivos que estamos utilizando en esta configuración de muestra.

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

Configuración de priorización DLCI de Frame Relay

El priorización del identificador de conexión de link de datos (DLCI) es el proceso por el que pongan a diversos tipos de tráfico sobre los DLCI separados de modo que una red Frame Relay pueda proporcionar un diverso committed information rate para cada tipo de tráfico. Puede ser utilizada conjuntamente con el formar la cola a medida o la cola prioritaria para proporcionar el control de administración de ancho de banda sobre el vínculo de acceso a la red Frame Relay. Además, algunos proveedores de servicios de Frame Relay y switches de Frame Relay (tales como el Switches del [IPX], IGX y BPX o de AXIS del Internetwork Packet Exchange del Stratacom) proporcionan realmente el priorización dentro de la nube de Frame Relay basada en esta Configuración de prioridad.

Consideraciones de Implementación

Al implementar la priorización DLCI, observe por favor las puntas siguientes:

  • Si va un DLCI secundario abajo, usted pierde el tráfico destinado para esa cola solamente.

  • Si usted pierde el DLCI primario, la subinterfaz va abajo y usted pierde todo el tráfico.

Diagrama de la red

dlci_prior.gif

Para utilizar esta configuración, usted necesita tener cuatro DLCI para el lado que utilizará la priorización DLCI. En este ejemplo, hemos configurado el Spicey para la prioridad que hacían cola como sigue:

  • El ping está en la cola de alta prioridad.

  • Telnet está en la cola de Prioridad media.

  • El File Transfer Protocol (FTP) está en la cola de prioridad normal.

  • El resto del tráfico IP está en la cola de baja prioridad.

Nota: Aseegurese le configurar los DLCI para corresponder con la lista de prioridad, o el sistema no utilizará la cola correcta.

Configuraciones

Spicey
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
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

Comandos debug y show

Utilice los comandos show and debug siguientes de probar que su red está actuando correctamente. Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.

  • show frame-relay pvc

  • show frame-relay map

  • muestre la prioridad de envío a cola

  • haga el debug de la prioridad

La salida mostrada abajo es un resultado de ingresar estos comandos en los dispositivos que estamos utilizando en esta configuración de muestra.

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         

Para verificar el priority queue, utilice el 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:

El otro tráfico IP pasa a través de la cola baja.

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#

Aquí está la salida de los debugs mostrada en el Spicey cuando usted utiliza el comando arriba al telnet al Spicey del 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)

Cola de transmisión de Frame Relay

La cola de broadcast es una característica importante que se utiliza en el media al IP o a las redes IPX grande en donde los broadcasts el rutear y del punto de acceso de servicio (SAP) deben fluir a través de la red Frame Relay. La cola de broadcast se maneja independientemente de la cola de la interfaz normal, tiene sus propios buffers, y tiene una tarifa del tamaño configurable y de servicio. Esta cola de broadcast no se utiliza para interligar las actualizaciones del atravesar-árbol (BPDU) debido a las sensibilidades de sincronización. Estos paquetes atravesarán las colas de administración del tráfico normales. El comando interface de habilitar la cola de broadcast sigue:

velocidad de paquetes de la velocidad de byte del tamaño de la cola de broadcast del Frame Relay

Una cola de broadcast se da un límite de la velocidad de transmisión máxima (producción) medido en los bytes por segundo y los paquetes por segundo. La cola se mantiene para asegurarse de que solamente este máximo está proporcionado. La cola de broadcast tiene prioridad cuando el transmitir a una tarifa debajo del Máximo configurado, y por lo tanto tiene una asignación de ancho de banda mínimo garantizada. Los dos límites de la velocidad de transmisión se piensan para evitar inundar la interfaz con los broadcasts. El límite real en cualquier segundo es el primer límite de velocidad se alcanza que. Dado la restricción de la velocidad de transmisión, el mitigar adicional se requiere para salvar los paquetes de broadcast. La cola de broadcast es configurable salvar un gran número de paquetes de broadcast. El tamaño de la cola se debe fijar para evitar la pérdida de paquetes de actualización de ruteo del broadcast. El tamaño exacto depende del protocolo que es utilizado y del número de paquetes requeridos para cada actualización. Para ser seguro, el tamaño de la cola debe ser fijado para poder salvar una actualización de ruteo completa de cada protocolo y para cada identificador de conexión de link de datos (DLCI). Como regla general, comienzo con 20 paquetes por el DLCI. La velocidad de byte debe ser menos que ambos siguiente:

  • El N/4 mide el tiempo de la tarifa de Acceso Remoto mínima (medida en los bytes por segundo), donde está el número N de DLCI a los cuales el broadcast deba ser replicado

  • 1/4 de la tarifa de Acceso local (medida en los bytes por segundo)

La velocidad de paquetes no es crítica si la velocidad de byte se fija conservador. Generalmente la velocidad de paquetes debe ser paquetes asumidos fijados del 250-byte. Los valores por defecto para las interfaces seriales son 64 tamaños de la cola, 256,000 bytes por segundo (2,048,000 BPS), y 36 pps. Los valores por defecto para las interfaces seriales de alta velocidad (HSSI) son el tamaño de la cola 256, 1,024,000 bytes por segundo (8,192,000 BPS), y 144 pps.

Modelado de tráfico

El modelado de tráfico utiliza un mecanismo de control de velocidad llamado un filtro de cubeta con fichas. Se fija este filtro de cubeta con fichas como sigue:

ráfaga en exceso más el committed burst (el Bc + sea) = velocidad máxima para el virtual circuit (VC)

El tráfico sobre la velocidad máxima está mitigado en una cola de modelado del tráfico que sea igual al tamaño de la cola justa cargada (WFQ). El filtro de cubeta con fichas no hace filtrar tráfico, sino controla la tarifa en la cual el tráfico se envía en la interfaz de salida. Para más información sobre los filtros de cubeta con fichas, vea por favor Descripción general de la regulación y diseño de tráfico.

Este documento proporciona una descripción del Control de tráfico genérico y del Control de tráfico de Frame Relay.

Parámetros de modelado de tráfico

Podemos utilizar los parámetros de modelado del tráfico siguientes:

  • CIR = committed information rate (= tiempo intermedio)

  • EIR = excess information rate

  • TB = token bucket (= el Bc + sea)

  • Bc = Committes Bursa Size (= tamaño de ráfaga continuo)

  • Sea = tamaño de ráfaga en exceso

  • DE = elección de descarte

  • Tc = intervalo de medición

  • AR = velocidad de acceso correspondiente al índice de la interfaz física (tan si usted utiliza un T1, el AR es aproximadamente 1.5 Mbps).

Miremos algunos de estos parámetros más detalladamente:

Access rate (AR)

El número máximo de bits por segundo que una estación terminal pueda transmitir en la red es limitado por la velocidad de acceso de la interfaz de red de usuario. La velocidad de línea de la conexión de red de usuario limita la velocidad de acceso. Usted puede establecer esto en su suscripción al proveedor de servicio.

Committes Bursa Size (Bc)

La cantidad máxima comprometida de datos que usted puede ofrecer a la red se define como Bc. El Bc es una medida para el volumen de datos para el cual la red garantiza la entrega de mensajes en condiciones normales. Se mide durante la velocidad comprometida Tc.

Tamaño de ráfagas en exceso (Be)

El número de bits NON-confiados (fuera del CIR) que todavía es validado por el switch de Frame Relay pero marcado como elegible ser desechado (DE).

El token bucket es un buffer “virtual”. Contiene varios tokens, habilitandole para enviar las cantidades limitadas de datos por el intervalo de tiempo. El token bucket se llena de los bits del Bc por el Tc. El tamaño máximo del compartimiento es Bc + sea. Si el es muy grande y, si en el t0 el compartimiento se llena del Bc + sea tokens, usted puede enviar el Bc + sea bits a la velocidad de acceso. Esto no es limitada por el Tc pero para el momento en que tome para enviar el. Ésta es una función de la velocidad de acceso.

Committed Information Rate (CIR)

El CIR es la cantidad permitida de datos que la red esté confiada para transferir en condiciones normales. La tarifa se hace un promedio sobre un incremento del tiempo Tc. El CIR también se refiere como el mínimo rendimiento de procesamiento aceptable. El Bc y sea se expresa en los bits, Tc en los segundos, y la velocidad de acceso y el CIR en los bits por segundo.

El Bc, sea, Tc y CIR se define por el identificador de conexión de link de datos (DLCI). Debido a esto, el filtro de cubeta con fichas controla la tarifa por el DLCI. La velocidad de acceso es válida por la interfaz de red de usuario. Por valores entrante y saliente del Bc, Be y CIR puede ser distinguido. Si la conexión es simétrica, los valores en las ambas direcciones son lo mismo. Para los circuitos virtuales permanentes, definimos el Bc, Be y CIR entrante y saliente en el tiempo de la suscripción.

  • Velocidad máxima del pico = DLCI. El ancho de banda para ese DLCI determinado.

  • Tc = Bc/CIR

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

Si el Tc es segundo entonces:

  • El pico = el CIR + sean = Bc + sean

  • El EIR = sea

21_new1.gif

En el ejemplo estamos utilizando aquí, el router envía el tráfico entre 48 kbps y 32 kbps dependiendo de la congestión en la red. Las redes pueden marcar las tramas sobre el Bc con el DE sino tener un montón de capacidad de repuesto de transportar la trama. El revés es también posible: pueden haber limitado la capacidad, con todo las tramas excesivas del descarte inmediatamente. Las redes pueden marcar las tramas sobre el Bc + estén con el DE, y transportarlas posiblemente, o apenas caiga las tramas según lo sugerido por sector de normalización de telecomunicaciones de la Unión internacional de telecomunicaciones la especificación ITU-T I.370. El modelado de tráfico estrangula el tráfico basado en los paquetes con Tag del Notificación explícita de la congestión hacia atrás (BECN) de la red de switch. Si usted recibe el 50 por ciento BECN, el router disminuye el tráfico por un octavo del ancho de banda transmitido actual para ese DLCI determinado.

Ejemplo:

La velocidad transmitida es el Kb 42. El router disminuye la velocidad a 42 menos 42 divididos por 8 (42 - 42/8), haciendo el Kb 36.75. Si la congestión disminuye después de que el cambio, el router reduzca el tráfico más lejos, cayendo a un octavo del ancho de banda transmitido actual. Se reduce el tráfico hasta que alcance el valor del CIR configurado. Sin embargo, la velocidad puede caer bajo el CIR cuando podemos todavía ver los BECN. Usted puede especificar un límite inferior, tal como CIR/2. La red se congestiona no más cuando todas las tramas recibidas de la red tienen no más un bit de notificación explícita de la congestión del reenvío para un período dado. el ms 200 es el valor predeterminado para este intervalo.

Modelado del tráfico genérico

La característica del Control de tráfico genérico es una herramienta de modelado del tráfico de encapsulado independiente y de medios que las ayudas reducen el flujo de tráfico saliente cuando hay congestión dentro de la nube, en el link, o en el router del punto final de recepción. Podemos fijarla en las interfaces o las subinterfaces dentro de un router.

El Control de tráfico genérico es útil en las situaciones siguientes:

  • Cuando usted tiene una topología de red que consista en (una conexión de alta velocidad de la velocidad de línea T1) en el sitio central y las conexiones de poca velocidad (de menos de 56 kbps) en la bifurcación o los emplazamientos de trabajador telecomunicado. Debido a la discrepancia de velocidad, un embotellamiento existe a menudo para el tráfico en la bifurcación o los emplazamientos de trabajador telecomunicado cuando el sitio central envía los datos a un ritmo más rápido que los sitios remotos pueden recibir. Esto da lugar a un embotellamiento en el Switch más reciente antes del router de la telecontrol-punta.

  • Si usted es un proveedor de servicio que ofrece los servicios de la tarifa secundaria, esta característica le permite para utilizar al router para dividir sus links T1 o T3, por ejemplo, en canales más pequeños. Usted puede configurar cada subinterfaz con un compartimiento simbólico del filtro que haga juego el servicio pedido por un cliente.

En su conexión de Frame Relay, usted puede quisiera que el router estrangulara el tráfico en vez de enviarlo en la red. Estrangular el tráfico limitaría la pérdida del paquete en la nube del proveedor de servicio. La capacidad que estrangula BECN-basada proporcionada esta característica permite que usted tenga el tráfico de la válvula reguladora del router dinámicamente basado en la recepción de los paquetes con Tag BECN de la red. Esto que estrangula sostiene los paquetes en los buffers del router para reducir el flujo de datos del router en la red Frame Relay. El router estrangula el tráfico en una base a una subinterfaz, y la tarifa también se aumenta cuando se reciben menos paquetes BECN-marcados con etiqueta.

Comandos para el Control de tráfico genérico

Para definir el control de velocidad, utilice este comando:

traffic-shape rate bit-rate [burst-size [excess-burst-size]] [group access-list]

Para estrangular los BECN en una interfaz de Frame Relay utilizan este comando:

[bit-rate] adaptante de la tráfico-dimensión de una variable

Para configurar una subinterfaz del Frame Relay para estimar el ancho de banda disponible cuando recibe los BECN, utilice el comando traffic-shape adaptive.

Nota: Usted debe habilitar el modelado de tráfico en la interfaz con el comando traffic-shape rate antes de que usted pueda utilizar el comando traffic-shape adaptive.

La velocidad de bits especificada para el comando traffic-shape rate es el límite superior, y la velocidad de bits especificada para el comando traffic-shape adaptive es el límite más bajo (generalmente el valor CIR) en el cual se forma el tráfico cuando la interfaz recibe los BECN. La tarifa usada realmente está normalmente entre estas dos tarifas. Usted debe configurar el comando traffic-shape adaptive en los ambos extremos del link, pues también configura el dispositivo en el extremo del flujo para reflejar las señales del Notificación explícita de la congestión del reenvío (FECN) como BECN. Esto permite al router en el extremo de alta velocidad para detectar y para adaptarse a la congestión incluso cuando el tráfico está fluyendo sobre todo en una dirección.

Ejemplo:

El siguiente ejemplo configura el modelado de tráfico en la interfaz 0.1 con un límite superior (generalmente el Bc + sea) del kbps 128 y un límite más bajo de 64 kbps. Esto permite que el link se ejecute a partir del 64 al kbps 128, dependiendo del nivel de congestión. Si el lado central tiene un límite superior del kbps 256, usted debe utilizar el valor más bajo del límite superior.

/image/gif/paws/16563/21_new3.gif

Aquí es lo que hemos configurado en este Routers:

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 

Diseño del Frame Relay

Con el Control de tráfico genérico usted puede especificar solamente una velocidad pico (límite superior) por la interfaz física y un valor CIR (un límite más bajo) por la subinterfaz. Con el Control de tráfico de Frame Relay, usted enciende un filtro de cubeta con fichas por el circuito virtual.

El modelado de tráfico sobre la característica de Frame Relay proporciona las capacidades siguientes:

  • De aplicación de la velocidad en a por VC: Usted puede configurar una velocidad pico para limitar el tráfico saliente al CIR o a un cierto otro valor definido tal como el excess information rate (EIR).

  • Soporte generalizado BECN en a por VC: El router puede monitorear los BECN y el tráfico de la válvula reguladora basados en la retroalimentación del paquete BECN-marcada de la red Frame Relay.

  • Asignación de colas de prioridad (PQ), Custom Queuing (CQ) o soporte WFQ en el VC llano. Esto permite la granularidad más fina en la priorización y los Datos en espera del tráfico, dándole más control sobre el flujo de tráfico en un VC individual. El modelado de tráfico sobre la característica de Frame Relay se aplica a los circuitos virtuales permanentes de Frame Relay (PVC) y a los circuitos virtuales conmutados (SVC).

Ejemplo:

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 
!

En este ejemplo el router agrega dos cubetas con ficha.

  • Uno se ejecuta entre 64000 (CIR) y 128000(Bc + sea).

  • El otro se ejecuta entre 16000 (CIR) y 64000 (el Bc + sea).

Si el tráfico entrante de los Ethernetes es más grande que el filtro de cubeta con fichas, el tráfico está mitigado para arriba en la cola del tráfico de Frame Relay.

Para ver un organigrama que muestra el flujo de paquetes cuando usted implementa el Control de tráfico de Frame Relay, vea por favor el diagrama de flujo de modelado del tráfico de Frame Relay. Para ver un organigrama específicamente usando un filtro de cubeta con fichas, vea por favor el Control de tráfico de Frame Relay - diagrama de flujo de cubeta con fichas.

Comandos de Frame Relay utilizados comúnmente

Esta sección describe dos comandos del ½ del ¿Â de Cisco IOSï que sean especialmente útiles al configurar el Frame Relay.

show frame-relay pvc

Este comando muestra el estatus del circuito virtual permanente (PVC), los paquetes adentro y hacia fuera, los paquetes perdidos si hay congestión en la línea vía el Notificación explícita de la congestión del reenvío (FECN) y el Notificación explícita de la congestión hacia atrás (BECN), y así sucesivamente. Para una descripción detallada de los campos usados con el comando show frame-relay pvc, haga clic aquí.

Si usted tiene la salida de un comando show frame-relay pvc de su dispositivo de Cisco, usted puede utilizar el Output Interpreter (clientes registrados solamente) para visualizar los problemas potenciales y los arreglos.

A continuación, se muestra el ejemplo de resultado:

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

El campo Uso de DLCI contiene una de las entradas siguientes:

  • CONMUTADO - utilizan al router o el servidor de acceso como Switch.

  • LOCAL - utilizan al router o el servidor de acceso como equipo de terminal de datos (DTE).

  • INUSITADO - el identificador de conexión de link de datos (DLCI) no es referido por los comandos configuration usuario-ingresados en el router.

El PVC puede tener cuatro estados posibles. Éstos son mostrados por el campo de ESTADO DEL PVC como sigue:

  • ACTIVO - El PVC es ascendente y de funcionamiento normalmente.

  • INACTIVO - El PVC no está encima de punta a punta. Esto puede ser porque no hay asignación (o mapeo incorrecto) para el DLCI local en la nube de Frame Relay o el extremo remoto del PVC se borra.

  • BORRADO - O la Interfaz de administración local (LMI) no se intercambia entre el router y el switch local, o el Switch no tiene DLCI configurado en el switch local.

  • ESTÁTICO - ningún keepalive configurado en la interfaz de Frame Relay del router.

show frame-relay map

Utilice este comando de determinar si el ARP-inverso del Frame Relay resolvió un IP Address remoto al DLCI local. Este comando no se habilita para las subinterfaces punto a punto. Es útil para las interfaces multipunto y las subinterfaces solamente. A continuación, se muestra el ejemplo de resultado:

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

Para una descripción detallada de los campos usados con el comando show frame-relay map, vea por favor la documentación encendido

Si usted tiene la salida de un comando show frame-relay map de su dispositivo de Cisco, usted puede utilizar el Output Interpreter (clientes registrados solamente) para visualizar los problemas potenciales y los arreglos.

Frame Relay y puentes

Los mensajes de configuración llamados las Unidades (BPDU) se utilizan en los Spanning Tree Protocol soportados en los Cisco Bridge y el Routers. Éstos fluyen a intervalos regulares entre los Bridges y constituyen una cantidad significativa de tráfico debido a su suceso de aparición con frecuente. Hay dos tipos de Spanning Tree Protocol en Puente transparente. Primero introducido por Digital Equipment Corporation (DEC), el algoritmo fue revisado por el comité del IEEE 802 y publicado posteriormente en la especificación del IEEE 802.1D. El Spanning-Tree Protocol de DEC publica los BPDU en los intervalos del segundo, mientras que el IEEE publica los BPDU en los dos-segundos intervalos. Cada paquete es 41 bytes, que incluye un mensaje del BPDU de configuración 35-byte, un encabezado de Frame Relay 2-byte, 2-byte el Ethertype, y un 2-byte FCS.

Frame Relay y memoria

La consumición de la memoria para los recursos del Frame Relay ocurre en cuatro áreas:

  1. Cada identificador de conexión de link de datos (DLCI): 216 bytes

  2. Cada sentencia de correspondencia: 96 bytes (o correspondencia dinámicamente construida)

  3. Cada IDB (retransmisión de la interfaz de hardware + de Frame encapsulado): 5040 + 8346 = 13,386 bytes

  4. Cada IDB (subinterfaz del software): 2260 bytes

Por ejemplo, un Cisco 2501 usando dos interfaces de Frame Relay, cada uno con cuatro subinterfaces, con un total de ocho DLCI, y las correspondencias asociadas necesita el siguiente:

  • IDB x 13,386 = 26,772 del hardware 2-interface

  • 8-subinterface IDB subinterfaces de x 2260 = 18,080

  • 8 DLCI DLCI de x 216 = 1728

  • 8 sentencias de correspondencia dinámica de x 96 = 768 sentencias de correspondencia o

El total es igual a 47,348 bytes de RAM usados.

Nota: Los valores usados aquí son válidos para el Cisco IOS Release 11.1, el software 12.0 y 12.1.

Resolución de problemas de Frame Relay

Esta sección contiene a las porciones de comando show interface posible le hizo salir puede encontrar mientras que resuelve problemas. Las explicaciones de la salida se proporcionan también.

“Serial0 está inactivo, el protocolo de línea está inactivo”

Esta salida significa que usted tiene un problema con el cable, la unidad de servicio de canal/unidad de servicio de datos (CSU/DSU), o la línea serial. Usted necesita resolver problemas el problema con una prueba de Loopback. Para hacer una prueba de Loopback, siga los pasos abajo:

  1. Fije el encapsulado de línea serial al HDLC y el keepalive a 10 segundos. Para hacer así pues, publique los comandos encapsulation hdlc y keepalive 10 bajo interfaz serial.

  2. Coloque el CSU/DSU o el módem en el Local Loop Mode. Si sube el Line Protocol cuando el CSU, el DSU o el módem está en el Local Loopback Mode (indicado por “Line Protocol está encima (colocado)” de mensaje), sugiere que el problema esté ocurriendo más allá del CSU/DSU local. Si la línea del estado no cambia los estados, hay posiblemente un problema en el router, el cable de conexión, el CSU/DSU o el módem. En la mayoría de los casos, el problema está con el CSU/DSU o el módem.

  3. Haga ping su propia dirección IP con el CSU/DSU o el módem colocado. No debe haber ninguna faltas. Un ping extendido de 0x0000 es útil en los problemas de línea de resolución puesto que un T1 o E1 deriva el reloj de los datos y requiere una transición cada 8 bits. El B8ZS asegura eso. Un patrón de datos de muchos ceros ayuda a determinar si las transiciones se fuerzan apropiadamente en el trunk. Pesado modelan se utiliza para simular apropiadamente una carga del cero alto en caso de que haya pares de inversores de los datos en la trayectoria. El patrón alterno (0x5555) representa a un patrón de datos “típico”. Si sus ping fallan o si usted consigue los errores de la verificación por redundancia cíclica (CRC), un probador de tasa de error en los bits (BERT) con un analizador apropiado de la compañía telefónica es necesario.

  4. Cuando usted es prueba acabada, aseegurese le volver la encapsulación al Frame Relay.

Serial0 activo, protocolo de línea no funciona

Esta línea en la salida significa que el router está consiguiendo una señal de la portadora del CSU/DSU o del módem. Marque para aseegurarse el proveedor de servicios de Frame Relay ha activado su puerto y eso que sus configuraciones de la Interfaz de administración local (LMI) hacen juego. Generalmente, el switch de Frame Relay ignora el equipo de terminal de datos (DTE) a menos que vea el LMI correcto (el valor por defecto de Cisco del uso a “Cisco” LMI). Marque para aseegurarse al router Cisco está transmitiendo los datos. Usted necesitará muy probablemente marcar la línea integridad usando las pruebas de Loop en las diversas ubicaciones empezando por el CSU local y el trabajo de su salida hasta que usted consiga al switch de Frame Relay del proveedor. Vea la sección anterior para que cómo realice una prueba de Loopback.

“Serial0 está activo, el protocolo de línea está activo”

Si usted no apagó el Keepalives, esta línea de salida significa que el router está hablando con el Switch del proveedor de servicios de Frame Relay. Usted debe ver un intercambio satisfactorio de tráfico de dos sentidos en la interfaz serial sin los errores CRC. El Keepalives es necesario en el Frame Relay porque él es el mecanismo que las aplicaciones del router “aprenden” que los identificadores de conexión de link de datos (DLCI) el proveedor tienen aprovisionado. Para mirar el intercambio, usted puede utilizar con seguridad el LMI de Frame Relay del debug en casi todas las situaciones. El comando debug frame-relay lmi genera muy pocos mensajes y puede proporcionar las respuestas a las preguntas por ejemplo:

  1. ¿El router Cisco está hablando con el switch de Frame Relay local?

  2. ¿El router está consiguiendo los mensajes de estado completos LMI para los circuitos virtuales permanentes inscritos (PVC) del proveedor de servicios de Frame Relay?

  3. ¿Están los DLCI correctos?

Aquí está algún LMI de Frame Relay del debug de la muestra hecho salir de una conexión satisfactoria:

*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

Note el estatus de “DLCI el 980" en la salida arriba. A continuación, se explican los valores posibles del campo de estado:

  1. 0x0-Added/inactive significa que el Switch tiene este DLCI programado pero por alguna razón (por ejemplo el otro extremo de este PVC está abajo), él no es usable.

  2. 0x2-Added/active significa que el switch de Frame Relay tiene el DLCI y todo es operativo. Usted puede comenzar a enviarle el tráfico con este DLCI en la encabezado.

  3. el 0x3-0x3 es una combinación de un estado activo (0x2) y el RNR (o r-bit) se fija que (0x1). Esto significa que el Switch - o una cola particular en el Switch - para este PVC está sostenido, y usted para el transmitir en caso de que se derramen las tramas.

  4. 0x4-Deleted significa que el switch de Frame Relay no tiene este DLCI programado para el router. Pero fue programado en algún momento del pasado. Esto se podía también causar por los DLCI que eran invertidos en el router, o por el PVC que era borrado por la compañía telefónica en la nube de Frame Relay. Configurar un DLCI (que el Switch no tenga) aparecerá como 0x4.

  5. 0x8-New/inactive

  6. 0x0a-New/active

Características de Frame Relay

Esta sección explica varias características de Frame Relay cuyo usted debe ser consciente.

Verificación mediante la técnica de división del horizonte de IP

El marcar partido del horizonte IP se inhabilita por abandono para la Encapsulación de Frame Relay así que las actualizaciones de ruteo vendrán en y hacia fuera lo mismo interconectan. El Routers aprende que los identificadores de conexión de link de datos (DLCI) que él necesita utilizar del switch de Frame Relay vía las actualizaciones de la Interfaz de administración local (LMI). El Routers después utiliza el ARP inverso para el IP Address remoto y crea un mapeo de DLCI local y sus IP Address remotos asociados. Además, ciertos protocolos tales como APPLETALK, Puente transparente, y el IPX no se pueden soportar en parcialmente las redes malladas porque requieren “parten el horizonte,” en cuál no se puede transmitir un paquete recibido en una interfaz hacia fuera la misma interfaz, incluso si el paquete se recibe y se transmite en diversos circuitos virtuales. Configurar las subinterfaces del Frame Relay se asegura de que una sola interfaz física está tratada como interfaces virtuales múltiples. Esta capacidad permite que superemos las reglas de división del horizonte. Los paquetes recibidos en una interfaz virtual se pueden ahora remitir hacia fuera otra interfaz virtual, incluso si se configuran en la misma interfaz física.

Hacer ping en su propia dirección IP en un relé de tramas multipunto

Usted no puede hacer ping su propia dirección IP en una interfaz de puntos múltiples de Frame Relay. Éste es porque las interfaces (sub) de múltiples puntos del Frame Relay son no-broadcast, ([HDLC] del High-Level Data Link Control de los a diferencia de Ethernetes y de las interfaces Point-to-Point), y las subinterfaces Frame Relay Point-to-Point.

Además, usted no puede hacer ping a partir de la uno habló a otro spoke en una configuración del hub and spoke. Esto es porque no hay asignación para su propia dirección IP (y ninguna eran docto vía el ARP inverso). Pero si usted configura una correlación estática (usando el comando frame-relay map) para su propia dirección IP (o una para la conexión remota) para utilizar el DLCI local, usted puede entonces hacer ping sus dispositivos.

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 palabra clave broadcast (difusión)

La palabra clave del broadcast proporciona dos funciones: adelante transmite cuando el multicasting no se habilita, y simplifica la configuración del Open Shortest Path First (OSPF) para las redes sin broadcast que utilizan el Frame Relay.

La palabra clave del broadcast se pudo también requerir para algunos Routing Protocol -- por ejemplo, APPLETALK -- eso depende de las actualizaciones de la tabla de ruteo regulares, especialmente cuando el router en el extremo remoto está esperando un paquete de actualización de ruteo para llegar antes de agregar la ruta.

Requiriendo la selección de un router designado, el OSPF trata un no-broadcast, red de acceso múltiple tal como Frame Relay de la misma forma que trata una red de broadcast. En las versiones anteriores, esta asignación manual requerida en la configuración de OSPF usando el comando neighbor interface router. Cuando incluyen al comando frame-relay map en la configuración con la palabra clave del broadcast, y configuran al comando ip ospf network (con la palabra clave del broadcast), no hay necesidad de configurar a ningunos vecinos manualmente. El OSPF ahora funciona con automáticamente encima la red Frame Relay como red de broadcast. (Véase el comando ip ospf network interface para más detalle.)

Nota: El mecanismo de broadcast OSPF asume que los direccionamientos de la clase IP D nunca están utilizados para el tráfico normal sobre el Frame Relay.

Ejemplo:

El siguiente ejemplo asocia el IP Address de destino 172.16.123.1 al DLCI 100:

interface serial 0
 frame-relay map IP 172.16.123.1 100 broadcast 

El OSPF utiliza el DLCI 100 para transmitir las actualizaciones.

Reconfiguración de una subinterfaz

Una vez que usted crea un tipo específico de subinterfaz, usted no puede cambiarla sin una recarga. Por ejemplo, usted no puede crear una subinterfaz de multipunto serial0.2, después la cambia al Punto a punto. Para cambiarlo, usted necesita recargar al router o crear otra subinterfaz. Ésta es la manera que el código del Frame Relay trabaja en el software del ½ del ¿Â de Cisco IOSïÂ.

Limitaciones de DLCI

Espacio del DLCI Address

Aproximadamente 1000 DLCI se pueden configurar en un solo vículo físico, dado un direccionamiento 10-bit. Porque ciertos DLCI son reservados (vendor-implementation-dependent), el máximo es cerca de 1000. El rango para Cisco LMI es 16-1007. El rango expuesto para el ANSI/ITU es 16-992. Éstos son los DLCI que llevan los useres data.

Sin embargo, al configurar el Frame Relay VCs en las subinterfaces, usted necesita considerar un límite práctico conocido como el límite del IDB. El número total de interfaces y subinterfaces por el sistema es limitado por el número de bloques del descriptor de la interfaz (IDBs) que su versión del Cisco IOS soporte. Un IDB es una porción de memoria que lleve a cabo la información sobre la interfaz tal como contadores, estatus de la interfaz, y así sucesivamente. El IOS mantiene un IDB para cada interfaz presente en una plataforma y mantiene un IDB para cada subinterfaz. Las interfaces de velocidad superior requieren más memoria que las interfaces de velocidad más baja. Cada plataforma contiene diversas cantidades de IDBs máximo y estos límites pueden cambiar con cada Cisco IOS Release.

Para más información, vea la cantidad máxima de interfaz y las subinterfaces para las Plataformas del Cisco IOS Software: Límites del IDB.

Actualización del estado de LMI

El protocolo LMI requiere que todos los informes sobre el estado del circuito virtual permanente (PVC) formen un solo paquete y, en general, restringe el número de DLCI a menos de 800, en función del tamaño de la unidad máxima de transmisión (MTU).

/image/gif/paws/16563/equation.gif

El MTU predeterminado en las interfaces seriales es 1500 bytes, rindiendo un máximo de 296 DLCI por la interfaz. Usted puede aumentar el MTU para soportar un mensaje de actualización más grande del estado completo del switch de Frame Relay. Si el mensaje de actualización del estado completo es más grande que el MTU de interfaz, se cae el paquete, y incrementan al contador gigante de la interfaz. Al cambiar el MTU, asegúrese que el mismo valor está configurado en los dispositivos del router remoto y de la red intermedia.

Observe por favor que estos números varían levemente, dependiendo del tipo LMI. El máximo DLCI por la pauta de plataforma del router (no interfaz), sobre la base de la extrapolación de las informaciones empíricas establecidas en una plataforma del Cisco 7000 Router, es mencionado abajo:

  • Cisco2500: 1 link X T1/E1 @ 60 DLCI por la interfaz = 60 totales

  • Cisco 4000: 1 link X T1/E1 @ 120 DLCI por la interfaz = 120 totales

  • Cisco4500: 3 links X T1/E1 @ 120 DLCI por la interfaz = 360 totales

  • Cisco 4700: 4 links X T1/E1 @ 120 DLCI por la interfaz = 480 totales

  • 7000 de Cisco: 4 links X T1/E1/T3/E3 @ 120 DLCI por la interfaz = 480 totales

  • Cisco 7200 5 links X T1/E1/T3/E3 @ 120 DLCI por la interfaz = 600 totales

  • Cisco 7500 6 links X T1/E1/T3/E3 @ 120 DLCI por la interfaz = 720 totales

Nota: Estos números son guías de consulta solamente, y asumen que todo el tráfico es Fast-Switched.

Otras consideraciones

Un limite DLCI práctico también depende encendido si el VCs está ejecutando un dinámico o el Static Routing Protocol. Los Dynamic Routing Protocol, y otros protocolos como IPX SAP que intercambian las tablas de base de datos, envían el hellos y los mensajes de información de reenvío que se deben considerar y procesar por el CPU. Como regla general, usando las Static rutas permitirá que usted configure un número más grande de VCs en una interfaz de Frame Relay.

Dirección IP/IPX/AT

Si usted está utilizando las subinterfaces, no ponga un IP, IPX o EN el direccionamiento en la interfaz principal. Asigne los DLCI a sus subinterfaces antes de que usted permita a la interfaz principal para asegurarse de que el ARP-inverso del Frame Relay trabaja correctamente. En caso de que funcione incorrectamente, siga los pasos abajo:

  1. Apague el (ARP) del protocolo inverse address resolution para ese DLCI usando el no frame-relay inverse-arp ip 16 y los comandos clear frame-relay-inarp.

  2. Repare su configuración.

  3. Gire el comando frame-relay inverse-arp otra vez.

RIP y IGRP

Las actualizaciones del Routing Information Protocol (RIP) fluyen cada 30 segundos. Cada paquete RIP puede contener hasta 25 entradas de la ruta, para un total de 536 bytes; 36 bytes de este total son información de encabezado, y cada entrada de la ruta es 20 bytes. Por lo tanto, si usted hace publicidad de 1000 rutas sobre un link de Frame Relay configurado para 50 DLCI, el resultado es 1 MB de los datos de actualización de ruteo cada 30 segundos, o 285 kbps del ancho de banda consumidos. En un link T1, este ancho de banda representa el 18.7 por ciento del ancho de banda, con cada duración de la actualización siendo 5.6 segundos. Esta cantidad de gastos indirectos es considerable, y es frontera aceptable, pero la Velocidad de información comprometida (CIR) tendría que estar en la región de la velocidad de acceso. Obviamente, cualquier cosa menos que un T1 incurriría en demasiados gastos indirectos. Por ejemplo:

  • 1000/25 = 40 paquetes X 36 = 1440 bytes de encabezado

  • 1000 x 20 bytes = 20,000 bytes de entradas de Route

  • El total 21,440 bytes X 50 los DLCI = 1072 MB del RIP pone al día cada 30 segundos

  • sec 1,072,000 bytes/30 X 8 bits = 285 kbps

Las actualizaciones del Interior Gateway Routing Protocol (IGRP) fluyen cada 90 segundos (este intervalo es configurable). Cada paquete IGRP puede contener 104 entradas de la ruta, para un total de 1492 bytes, 38 cuyo es la información de encabezado, y cada entrada de la ruta es 14 bytes. Si usted hace publicidad de 1000 rutas sobre un link de Frame Relay configurado con 50 DLCI, la petición es aproximadamente 720 KB de los datos de actualización de ruteo cada 90 segundos, o 64 kbps del ancho de banda consumidos. En un link T1, este ancho de banda representaría el 4.2 por ciento del ancho de banda, con cada duración de la actualización siendo 3.7 segundos. Estos gastos indirectos son una cantidad aceptable:

  • 1000/104 = 9 paquetes X 38 = 342 bytes de encabezado

  • 1000 x 14 = 14,000 bytes de entradas de Route

  • Total = 14,342 bytes X 50 DLCI = 717 KB de las actualizaciones de IGRP cada 90 segundos

  • 717,000 bits de los bytes/90 x 8 = 63.7 kbps

Las actualizaciones de ruteo del Routing Table Maintenance Protocol (RTMP) ocurren cada 10 segundos (este intervalo es configurable). Cada paquete RTMP puede contener hasta 94 entradas extendidas de la ruta, para un total de 564 bytes, información de 23 bytes de encabezamiento, y cada entrada de la ruta es 6 bytes. Si usted hace publicidad de 1000 redes Appletalk sobre un link de Frame Relay configurado para 50 DLCI, el resultado es aproximadamente 313 KB de RTMP pone al día cada 10 segundos, o 250 kbps del ancho de banda consumidos. Para seguir siendo dentro de un nivel aceptable de gastos indirectos el 15 por ciento o menos), se requiere una tarifa T1. Por ejemplo:

  • 1000/94 = 11 paquetes X 23 bytes = 253 bytes de encabezado

  • 1000 x 6 = 6000 bytes de entradas de Route

  • El total = 6253 x 50 los DLCI = 313 KB de RTMP pone al día cada 10 segundos

  • sec 313,000/10 X 8 bits = 250 kbps

Las actualizaciones del paquete RIP IPX ocurren cada 60 segundos (este intervalo es configurable). Cada paquete RIP IPX puede contener hasta 50 entradas de la ruta para un total de 536 bytes, información de 38 bytes de encabezamiento, y cada entrada de la ruta es 8 bytes. Si usted hace publicidad de 1000 rutas de IPX sobre un link de Frame Relay configurado para 50 DLCI, el resultado es 536 KB de IPX pone al día cada 60 segundos, o 58.4 kbps del ancho de banda consumidos. Para dentro de un nivel aceptable de gastos indirectos (el 15 por ciento o menos), sigue habiendo un índice de 512 kbps se requiere. Por ejemplo:

  • 1000/50 = 20 paquetes X 38 bytes = 760 bytes de encabezamiento

  • 1000 x 8 = 8000 bytes de entradas de Route

  • El total = 8760 x 50 los DLCI = 438,000 bytes de IPX pone al día cada 60 segundos

  • sec 438,000/60 X 8 bits = 58.4 kbps

Las actualizaciones de paquetes del punto de acceso de servicio IPX (SAP) ocurren cada 60 segundos (este intervalo es configurable). Cada Paquete IPX SAP puede contener hasta siete entradas de anuncio para un total de 536 bytes, información de 38 bytes de encabezamiento, y cada entradas de anuncio son 64 bytes. Si usted transmita 1000 anuncios IPX sobre un link de Frame Relay configurado para 50 DLCI, usted terminaría para arriba con 536 KB de IPX pone al día cada 60 segundos, o 58.4 kbps del ancho de banda consumidos. Para dentro de un nivel aceptable de gastos indirectos (el 15 por ciento o menos), sigue habiendo un índice de mayor que el 2 Mbps se requiere. Obviamente, la filtración de SAP se requiere en este escenario. Comparado al resto de los protocolos mencionados en esta sección, las actualizaciones IPX SAP requieren la mayoría del ancho de banda:

  • 1000/7 = 143 paquetes X 38 bytes = 5434 bytes de encabezamiento

  • 1000 x 64 = 64,000 bytes de entradas de Route

  • Total = 69,434 x 50 DLCI = 3,471,700 bytes de los anuncios del servicio IPX cada 60 segundos

  • sec 3,471,700/60 X 8 bits = 462 kbps

Keepalive

En algunos casos, el keepalive en el dispositivo de Cisco necesita ser fijado levemente más corto (cerca de 8 segundos) que el keepalive en el Switch. Usted verá la necesidad de esto si la interfaz guarda el subir y abajo.

Interfaces en serie

Las interfaces seriales, que son por abandono de múltiples puntos, son medios no aptos para broadcast, mientras que se transmiten las subinterfaces punto a punto. Si usted está utilizando las Static rutas, usted puede señalar al salto siguiente o al Subinterfaz serial. Para de múltiples puntos, usted necesita señalar al salto siguiente. Este concepto es muy importante al hacer el OSPF sobre el Frame Relay. El router necesita saber que esto sea una interfaz de broadcast para que el OSPF trabaje.

OSPF y multipunto

El OSPF y de múltiples puntos pueden ser muy molestos. El OSPF necesita un router designado (DR). Si usted comienza a perder los PVC, un poco de Routers puede perder la Conectividad e intentar hacer un DR aunque el otro Routers todavía ve el DR viejo. Esto hace el proceso OSPF funcionar incorrectamente.

Por encima no se asocia al OSPF tan obvio y fiable como eso con los Routing Protocol tradicionales del vector de distancia. La imprevisión viene de independientemente de si los links de la red OSPF son estables. Si todas las adyacencias a un router de Frame Relay son estables, sólo fluirán los paquetes de saludo de vecino (Keepalives), que es comparativamente mucho menos gastos indirectos que eso incurrieron en con un protocolo del vector distancia (tal como RIP y IGRP). Si, sin embargo, ocurren las rutas (adyacencias) son inestables, inundación del estado de los links, y el ancho de banda puede ser consumido rápidamente. El OSPF también es muy uso intensivo del procesador al funcionar con el algoritmo Dijkstra, que se utiliza para computar las rutas.

En las versiones anteriores del Cisco IOS Software, el particular cuidado tuvo que ser tomado al configurar el OSPF sobre los medios multiaccesos del nonbroadcast tales como Frame Relay, X.25, y atmósfera. El protocolo OSPF considera estos media como cualquier otro medio de broadcast tal como Ethernetes. Las nubes del acceso múltiple sin broadcast (NBMA) se construyen típicamente en un topologia Hub y Spoke. Los PVC o los circuitos virtuales conmutados (SVC) se presentan en una Interconexión parcial y la topología física no proporcionan el multiacceso que las creencias OSPF son allí. Para la caja de interfaces serial Point-to-Point, el OSPF forma siempre una adyacencia entre los vecinos. Información de la base de datos del intercambio de las adyacencias OSPF. Para minimizar la cantidad de información intercambiada en un segmento en particular, el OSPF elige un router para ser un DR, y a un router para ser un router designado de backup (BDR) en cada segmento de multiacceso. Se elige el BDR como mecanismo de respaldo en caso de que falle el DR.

La idea detrás de esta configuración es que el Routers tiene un punto central de contacto para el intercambio de información. La selección del DR se convirtió en un problema porque el DR y el BDR necesitaron tener conectividad física completa con todo el Routers que existe en la nube. También, debido a la falta de capacidades de broadcast, el DR y el BDR necesitaron tener una lista estática del resto del Routers asociado a la nube. Esta configuración se alcanza usando el comando neighbor:

neighbor ip-address [priority number] [poll-interval seconds]

En versiones posteriores del Cisco IOS Software, los métodos distintos se pueden utilizar para evitar las complicaciones de configurar vecinos estáticos y tener el Routers específico DR o BDR que se convierten en la nube del nonbroadcast. Por qué método utilizar es influenciado si la red es nueva o un diseño existente que necesita la modificación.

Una subinterfaz es una manera lógica de definir una interfaz. Es posible dividir una misma interfaz física en varias interfaces lógicas y cada una de las subinterfaces, a su vez, definirla como punto a punto. Este escenario fue creado originalmente para manejar mejor los problemas causados por el horizonte de la fractura sobre el NBMA y el vector basó los Routing Protocol.

Una subinterfaz punto a punto tiene las propiedades de cualquier interfaz punto a punto física. En lo que respecta a OSPF, una adyacencia siempre se forma sobre una subinterfaz punto a punto sin elección de DR ni BDR. El OSPF considera la nube los conjuntos de links Point-to-Point bastante que una red de acceso múltiple. La única desventaja para el Punto a punto es que cada segmento pertenece a una diversa subred. Este escenario no pudo ser aceptable porque algunos administradores han asignado ya una subred IP para la nube completa. Otra solución alternativa es utilizar las interfaces sin numerar de IP en la nube. Este escenario también pudo ser un problema para algunos administradores que manejan WAN basado en los IP Addresses de las líneas seriales.

Fuentes

  1. Comité consultor de telegrafía y telefonía internacional, “especificación de la capa del link de datos ISDN para los servicios portadores de voz del modo de trama”, recomendación CCITT Q.922, el 19 de abril 1991.

  2. American National Standard para las telecomunicaciones - Integrated Services Digital Network - Quite el corazón a los aspectos del protocolo del capítulo para el uso con el servicio portador de voz del Frame Relay, ANSI T1.618-1991, el 18 de junio 1991.

  3. Information Technology - Telecomunicaciones y intercambio de información entre los sistemas - Identificación del protocolo en la capa de red, ISO/IEC TR 9577: (e) 1990 1990-10-15.

  4. Norma internacional, sistemas de procesamiento de información - Redes de área local - Logical Link Control, ISO 8802-2: (e) 1989, IEEE Std 802.2-1989, 1989-12-31.

  5. Descripción de tecnología de conexión entre redes, octubre de 1994, Cisco Systems

  6. Finlayson, R., Mann, R., portalámparas gigante, J., y M. Theimer, “protocolo reverse address resolution”, STD 38, RFC 903, Stanford University, junio de 1984.

  7. Postel, J. y Reynolds, J., “estándar para la transmisión de los datagramas IP sobre las redes del IEEE 802”, RFC 1042, ciencias instituto USC/Information, febrero de 1988.

  8. Encapsulación RFC 1490-Multiprotocol leavingcisco.com

  9. Retransmisión MIB RFC 1315-Frame leavingcisco.com

  10. Retransmisión ARP inverso RFC 1293-Frame leavingcisco.com

  11. Compresión del encabezamiento RFC 1144-TCP/IP

  12. Interfaz del foro de Frame Relay (FRF) 1.1-User-Network (UNI)

  13. Interfaz de red a red (NNI) de la retransmisión FRF 2.1-Frame

  14. Encapsulación FRF 3.1-Multiprotocol

  15. FRF 4-SVCs

  16. Administración de la red del cliente del servicio de la retransmisión FRF 6-Frame (MIB)

  17. Cuadrilla de cuatro LMI

  18. El Q.922 adjunta A

  19. Anexo D ANSI T1.617

  20. ANSI T1.618, T1.606

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

  22. Guía de diseño de OSPF

  23. Notas de configuración para la instrumentación mejorada del IGRP mejorado


Información Relacionada


Document ID: 16563