WAN : Frame Relay

Configuración y resolución de problemas del Frame Relay

19 Mayo 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (2 Noviembre 2005) | Comentarios

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


Contenidos

Introducción
Antes de comenzar
     Convenciones
     Requisitos previos
     Componentes utilizados
     Teoría precedente
Configuración de Basic Frame Relay
     Diagrama de la red
     Configuraciones
     comandos debug y show
Configuración de retransmisión de tramas de eje de conexión y radio
     Diagrama de la red
     Configuraciones
     Comandos show
     Conexión de radio a radio
     Configuraciones
     Comandos show
Configuración de subinterfaces para Frame Relay
     Subinterfaces punto a punto
     Comandos show
     Subinterfaces hub y spoke
     Comandos show
Configuración de correspondencia dinámica y estática para subinterfaces multipunto
     Diagrama de la red
     Configuraciones
     comandos debug y show
Configuración del Frame Relay sin números de IP
     Diagrama de la red
     Configuraciones
     Comandos show
Configuración de respaldo para Frame Relay
     Respaldo de retransmisión de tramas sobre ISDN
     Configuración por copia de seguridad de DCLI
     Red radial con Dialer Profiles
Configuración de conmutación del Frame Relay
     Diagrama de la red
     Configuraciones
     Comandos show
Configuración de priorización DLCI de Frame Relay
     Consideraciones de Implementación
     Diagrama de la red
     Configuraciones
     comandos debug y show
Cola de transmisión de Frame Relay
Modelado de tráfico
     Parámetros de modelado de tráfico
     Modelado del tráfico genérico
     Diseño del Frame Relay
Comandos de Frame Relay utilizados comúnmente
     show frame-relay pvc
     show frame-relay map
Transmisión de tramas y conexión en bridge
Retransmisión de tramas y memoria
Resolución de problemas de Frame Relay
     “Serial0 está inactivo, el protocolo de línea está inactivo”
     Serial0 activo, protocolo de línea no funciona
     “Serial0 está activo, el protocolo de línea está activo”
Características de Frame Relay
     Verificación mediante la técnica de división del horizonte de IP
     Hacer ping en su propia dirección IP en un relé de tramas multipunto
     La palabra clave broadcast (difusión)
     Reconfiguración de una subinterfaz
     Limitaciones de DLCI
     Dirección IP/IPX/AT
     RIP y IGRP
     Keepalive
     Interfaces en serie
     OSPF y multipunto
Fuentes
Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Frame Relay es un protocolo de capa de enlace de datos conmutados, de estándar industrial, que maneja múltiples circuitos virtuales con encapsulación de Control de enlace de datos de alto nivel (HDLC) entre dispositivos conectados. En muchos casos, Frame Relay es más eficiente que X.25, el protocolo del cual usualmente es considerado como su reemplazo. La siguiente figura ilustra un protocolo Frame Relay (ANSI T1.618).

13a.gif

En la figura de arriba, las direcciones Q.922, tal como se definen en el presente material, son dos octetos y contienen un identificador de conexión de enlace de datos (DLCI) de 10 bits. En algunas redes Q.922, las direcciones pueden aumentarse de manera opcional a tres o cuatro octetos.

Los campos del “indicador” delimitan el comienzo y la finalización de la trama. El siguiente campo destacado “indicador” son dos bytes de información de direcciones. Diez bits de estos dos bytes conforman el circuito ID (llamado DLCI, por identificador de conexión de enlace de datos).

El valor del DLCI de 10 bits es el centro del encabezado Frame Relay. Identifica la conexión lógica que se multiplexa en el canal físico. En lo básico (es decir, cuando no es ampliado por el modo de direccionamiento de Interfaz Local de Administración [LMI]), los DLCI son importantes a nivel local; es decir, los dispositivos extremos en dos terminaciones diferentes de una conexión pueden utilizar un DLCI distinto para referirse a esa misma conexión.

Antes de comenzar

Convenciones

Si desea obtener más información sobre las convenciones del documento, consulte las Convenciones de consejos técnicos de Cisco.

Requisitos previos

Si desea obtener más información y definiciones sobre los términos empleados en este documento, consulte el 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 creó a partir de los dispositivos en un entorno específico de laboratorio. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración despejada (predeterminada). Si está trabajando en una red activa, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Teoría precedente

Frame Relay fue concebido en un principio como un protocolo para utilizar sobre las interfaces ISDN. Las propuestas iniciales para crearlo fueron presentadas ante el sector de estandarización de las telecomunicaciones de la Unión internacional de Telecomunicaciones (ITU-T) (denominado en sus comienzos en 1984 Comité consultor de telegrafía y telefonía internacional [CCITT]). El trabajo sobre Frame Relay fue también presentado en ANSI-comité acreditado de estándares T1S1 en Estados Unidos.

En 1990, Cisco Systems, StrataCom, Northern Telecom y Digital Equipment Corporation formaron un consorcio para centrarse en el desarrollo de la tecnología en Frame Relay y acelerar la introducción de productos interoperables de Frame Relay. Desarrollaron una especificación conforme al protocolo básico de Frame Relay tratado en T1S1 y ITU-T, aunque ampliado con características que ofrecen capacidades adicionales para ambientes complejos de funcionamientos entre redes. Estas extensiones Frame Relay se conocen en su conjunto como LMI. Esta es la "cisco" LMI en el router, en contraposición a la "ansi" o la "q933a" LMI.

Frame Relay ofrece la capacidad de comunicaciones de información en un paquete de conmutación utilizado en la interfaz entre los dispositivos de los usuarios (como routers , Bridges, máquinas host) y equipos que funcionan en res (como nodos de conmutación). A los dispositivos de usuario se les conoce usualmente como Equipo terminal de datos (DTE), mientras que a los equipos que funcionan en red en interfase con DTE, son generalmente denominados equipo de terminal de circuito de datos (DCE). La red que ofrece la interfaz Frame Relay puede ser un proveedor de red pública o un equipo de propiedad privada que funcione como empresa individual.

Frame Relay presenta marcadas diferencias con X.25 en cuanto a funcionalidad y formato. En particular, Frame Relay es un protocolo más funcional que facilita mayor desempeño y más eficiencia.

Como una interfaz entre el usuario y el equipo en red, Frame Relay ofrece un medio para multiplexar estadísticamente varias conversaciones de datos lógicos (denominados circuitos virtuales) por un único enlace de transmisión física. Esto contrasta con los sistemas que utilizan únicamente técnicas de multiplexión por división de tiempo (TDM) para aceptar múltiples secuencias de datos. La multiplexión estadística de Frame Relay ofrece una utilización más flexible y eficiente del ancho de banda disponible. Puede ser utilizado sin las técnicas TDM o sobre los canales que ofrecen los sistemas TDM.

Otra característica importante de Frame Relay es que saca provecho de los últimos avances recientes en la tecnología de transmisión de red de área ancha (WAN). Los anteriores protocolos WAN, como el X.25, fueron desarrollados cuando los sistemas de transmisión analógica y y los dispositivos de cobre predominaban. Estos enlaces son mucho menos confiables que los enlaces de transmisión por dispositivos de fibra/digital en existencia actualmente. Sobre los enlaces como estos, los protocolos de capas de enlace pueden preceder a los algoritmos de corrección de errores que demandan tiempo, dejando que esto sea realizado en capas superiores de protocolos. Por ende, es posible lograr mayor desempeño y eficiencia sin sacrificar la integridad de los datos. Frame Relay ha sido diseñado considerando esta perspectiva. Esto incluye el algoritmo de verificación por redundancia cíclica (CRC) para detectar bits corruptos (de manera que los datos puedan ser descartados), aunque no incluye mecanismo alguno de protocolo para corregir los datos defectuosos (por ejemplo, retransmitiéndolos a este nivel de protocolo).

Otra de las diferencias entre Frame Relay y X.25 es la ausencia de control explícito del flujo por circuito virtual en Frame Relay. Ahora que son muchos los protocolos de capa superior que están efectivamente ejecutando sus propios algoritmos de control de flujo, ha disminuido la necesidad de contar con esta funcionalidad en la capa de vínculos. Por lo tanto, Frame Relay, no incluye procedimientos de control explícito de flujo que duplique a aquellos en las capas superiores. En su lugar, mecanismos muy sencillos de notificación de congestión han sido creados para permitirle a una red que le informe a un dispositivo de usuario que los recursos de red se encuentran próximos a un estado de congestión. Esta notificación puede alertar a los protocolos de capa superior sobre la posible necesidad de controlar el flujo.

Configuración de Basic Frame Relay

Cuando cuente con conexiones confiables al switch local de Frame Relay en ambos extremos del circuito virtual permanente (PVC) podrá comenzar a planificar la configuración de Frame Relay En este primer ejemplo, la Interfaz de administración local (LMI) predetermina a “cisco” LMI sobre Spicey. Una interfaz es, de manera predeterminada, una interfaz “multipunto”, por lo tanto frame-relay inverse-arp está activada (para punto a punto no existe ARP inverso). De manera predeterminada, la verificación de división de horizonte IP no está habilitada para encapsulación Frame Relay, de modo que las actualizaciones del router entran y salen de la misma interfaz. Los routers reconocen a los identificadores de conexiones de enlaces a información (DLCI) que necesitan usar del switch de Frame Relay a través de las actualizaciones LMI. Luego los routers invierten el ARP para la dirección IP remota. y crean una asignación de DLCI locales y sus direcciones IP remotas asociadas.

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 los comandos debug, consulte Información importante sobre Comandos de depuración.

  • show frame-relay map

  • show frame-relay pvc

  • show frame-relay lmi

  • ping <device name>

  • 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 de retransmisión de tramas de eje de conexión y radio

En este ejemplo, el router reconoce cuáles son los identificadores de conexiones de enlaces de datos que usa del switch de Frame Relay y los asigna a la interfaz principal. Luego los routers invierten el ARP para la dirección IP remota.

Nota: No podrá hacerle ping a una dirección en serie IP de Prasit desde Aton a menos que le agregue explícitamente mapas de Frame Relay en cada final. Si el ruteo se configura de manera correcta, el tráfico que se origine en LAN no debería presentar problemas. Podrá hacerle ping si usa a una dirección IP de Ethernet como la la dirección de origen de un ping extendido.

Cuando la opción frame-relay inverse-arp esté activada, la difusión del tráfico IP saldrá por la conexión forma predeterminada.

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

  • ping <device name>

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

No puede hacer ping de una radio a otra en una configuración de tipo radial utilizando interfaces de multipuntos porque no existe asignación para las demás direcciones IP de las radios. Sólo la dirección de concentrador puede ser reconocida a través del Protocolo de resolución de direcciones inversas (IARP). Si configura un mapa estático utilizando el comando de mapas de frame-relay para las direcciones IP de una radio remota para emplear el identificador de conexión de enlaces de datos local, (DLCI), puede hacer ping en las direcciones de otras radios.

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

  • ping <device name>

  • 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 de Frame Relay ofrecen un mecanismo para soportar de manera parcial las redes malladas de Frame Relay. La mayoría de los protocolos suponen la transitividad sobre una red lógica; es decir, si la estación A puede hablarle a la estación B y la estación B puede hablarle a la estación C, entonces la estación A debería poder hablarle a la C directamente. La transitividad existe en las redes de LAN pero no en las de Frame Relay a menos que A se encuentre directamente conectada a C.

Además, determinados protocolos como el AppleTalk y la conexión transparente en bridge no pueden ser soportados en redes parcialmente malladas ya que requieren un "horizonte dividido" en el cual un paquete recibido en una interfaz no pueda ser transmitido desde la misma interfaz incluso si el paquete es recibido y transmitido en distintos circuitos virtuales.

La configuración de las subinterfaces de Frame Relay aseguran que una sola interfaz física sea tratada como múltiples interfaces virtuales. Esta capacidad nos permite superar las reglas de división del horizonte. Los paquetes recibidos a través de una interfaz virtual pueden ahora ser enviados a otra interfaz virtual, incluso si están configurados en la misma interfaz física.

Las subinterfaces se ocupan de las limitaciones de las redes Frame Relay brindando un modo de subdividir una red parcialmente mallada de Frame Relay en un número de subredes más pequeñas y completamente malladas (o punto a punto). Cada subred tiene asignado su propio número de red y aparece ante los protocolos como si pudiese ser alcanzada a través de una interfaz distinta. (Las subinterfaces punto a punto pueden ser no numeradas para usar con IP, reduciendo así la carga de direccionamientos que de lo contrario podría suceder).

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 siguiente configuración de ejemplo de conexión y radio muestra dos subinterfaces punto a punto y utiliza una resolución dinámica de direcciones en un sitio remoto. Cada subinterfaz está acompañada por una dirección individual de protocolo y máscara de subred, y el comando interface-dlci asocia a la subinterfaz con un identificador de conexión de enlace de datos (DLCI) especificado. Las direcciones de destinos remotos para cada subinterfaz punto a punto no son resueltas debido a que son punto a punto y el tráfico debe ser enviado al par en el otro final. El final remoto (Aton) utiliza ARP Inverso para su asignación y el concentrador principal responde de acuerdo con la dirección IP de la subinterfaz. Esto ocurre porque el ARP Inverso de Frame Relay está activo, de manera predeterminada, por interfaces multipuntos.

Diagrama de la red

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 asignación dinámica de direcciones utiliza el ARP Inverso de Frame Relay para solicitarle al siguiente salto (next hop) de dirección de protocolo una conexión específica, dado un identificador de conexión de enlace de datos (DLCI). Las solicitudes de respuestas del ARP Inverso se entran en una tabla de asignación de dirección a DLCI en el router o en el servidor de acceso, luego la tabla se utiliza para proveer el siguiente salto (next hop) de dirección de protocolo o el DLCI para el tráfico saliente.

Como la interfaz física se encuentra ahora configurada como subinterfaces múltiples, debe ingresar información que distinga una subinterfaz de la interfaz física y asocie una subinterfaz específica con un DLCI específico.

El ARP Inverso se activa de manera predeterminada para todos los protocolos que soporta, aunque puede desactivarse para pares específicos de protocolos-DLCI. Como consecuencia, puede utilizar asignación dinámica para algunos protocolos y asignación estática para otros en el mismo DLCI. Explícitamente puede desactivar el ARP Inverso para un par de protocolos DLCI en caso de no saber si el protocolo es soportado en el otro final de la conexión.. Como el ARP Inverso se activa de manera predeterminada para todos los protocolos que soporta, no se requiere un comando adicional para configurar la asignación dinámica de direcciones en una subinterfaz. Una correlación estática enlaza un siguiente salto (next hop) específico de dirección de protocolo con un DLCI especificado. La asignación estática elimina la necesidad de solicitudes de ARP Inverso. Cuando se entra una correlación estática, automáticamente se desactiva el ARP Inverso por el protocolo especificado en el DLCI especificado. Debe utilizar correlación estática si el router en el otro final no soporta el ARP Inverso de ningún modo o no soporta el ARP Inverso para un protocolo específico que se desee emplear en Frame Relay.

Diagrama de la red

Ya hemos visto cómo se configura un router Cisco para hacer ARP Inverso. El siguiente ejemplo muestra cómo se configuran las correlaciones estáticas en caso de que las necesite para interfaces multipunto o 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 obtener más información sobre estos comandos, diríjase a Comandos de Frame Relay.

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

Si no posee el espacio de dirección IP para usar varias subinterfaces, puede utilizar el IP no numerado en cada subinterfaz. En este caso, deberá usar rutas estáticas o ruteo dinámico para que su tráfico sea enrutado como lo es usualmente y deberá utilizar subinterfaces punto a punto.

Diagrama de la red

El ejemplo que aparece a continuación lo ilustra:

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

Es posible que desee realizar una copia de respaldo de los circuitos Frame Relay empleando ISDN. Existen varias formas de hacerlo. La primera, y probablemente la mejor, es utilizar rutas estáticas flotantes para enrutar a una dirección IP de Interfaz de Velocidad Básica (BRI) y emplear una métrica de ruteo adecuada. También puede utilizar una interfaz de respaldo en la interfaz principal o hacerlo mediante un identificador de conexión de enlace de datos (DLCI). Probablemente no sea demasiado útil respaldar la interfaz principal ya que puede perder circuitos virtuales permanentes (PVC) sin que se desconecte la interfaz principal. Recuerde que el protocolo está siendo intercambiado con el switch local Frame Relay y no con el router.

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

!--- Ruta estática flotante.

!

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

!--- Ruta estática flotante.

!

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á funcionando, utilice los siguientes comandos debug. Antes de ejecutar comandos debug, diríjase a Información importante sobre Comandos de depuración.

  • debug isdn q931

  • debug ppp neg

  • debug ppp auth

Intente realizar una llamada ISDN desde el lado de llamada al lado central sin los comandos de respaldo. Si esto tiene éxito, agregue los comandos de respaldo al lado de llamada.

Nota: Para probar el respaldo, no use el comando shutdown en la interfaz en serie. Emule un problema real de línea en serie quitando el cable de la línea en serie.

Configuración por copia de seguridad de DCLI

Supongamos que Spicey es el lado central y que Prasit es el lado que realiza las conexiones al lado central (Spicey). Asegúrese de que sólo agrega los comandos de respaldo al lado que está llamando al lado central.

Nota:  La carga de respaldo no se soporta en subinterfaces. Como no rastreamos los niveles de tráfico en las subinterfaces, no se calcula carga alguna.

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

  • show isdn history

  • show isdn status

  • show interface bri 0

  • show isdn active

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 en serie deja de funcionar.

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 se desactiva nuevamente..

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 Dialer Profiles

A continuación se presenta un ejemplo de eje de conexión y radio por configuración de respaldo de DLCI. Los routers radiales están llamando al router de eje de conexión. Tal como puede verse, sólo permitimos un canal B por lado utilizando la opción de enlace máximo en el agrupamiento de marcadores en el lado del concentrador.

Nota: La carga de respaldo no es soportada en subinterfaces. Como no rastreamos los niveles de tráfico en las subinterfaces, no se calcula carga alguna.

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#  

Serial 1 deja de funcionar.

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#

Serial 1 se activa nuevamente

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

Las dos líneas en serie de los lados de llamada dejan de funcionar.

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#

Se reestablecen nuevamente las dos líneas en serie.

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#

Serial 1 deja de funcionar.

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#

Serial 1 se activa nuevamente.

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 de conmutación del Frame Relay

La conmutación de Frame Relay es un medio de conmutar paquetes basados en el identificador de conexión de enlace de datos (DLCI). Podemos considerarlo como el equivalente Frame Relay de la dirección de Control de acceso a medios (MAC). La conmutación se realiza configurando su router Cisco o servidor de acceso en una red de Frame Relay. Existen dos partes de una red de Frame Relay:

  • El equipo Terminal de datos (DTE) de Frame Relay - el router o servidor de Cisco.

  • Switch de Equipo de terminación del circuito de datos (DCE) de Frame Relay.

Nota:  En el software Cisco IOS versión 12.1(2)T y posteriores, el frame route comando ha sido reemplazado por el connect.

Veamos un ejemplo de configuración. En la configuración que se muestra a continuación estamos usando el router America como un switch de Frame Relay. Estamos utilizando Spicey como un router de eje de conexión y Prasit y Aton como routers radiales. Los hemos conectado como aparece a continuación:

  • Número de serie 1 de Prasit (s1) DTE está conectado al número de serie 1/4 (s1/4) de America DCE.

  • El número de serie 0 de Spicey 0 (s0) DTE está conectado al número de serie 1/5 (s1/5) de America DCE.

  • El número de serie 1 de Aton (s1) DTE está conectado al número de serie 3/4 (s3/4) DCE de America.

Diagrama de la red

Este documento se basa en la siguiente configuración:

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

America

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 siguientes comandos para probar si su red está funcionando correctamente:

  • show frame-relay map

  • show frame-relay pvc

La salida que aparece a continuación es el resultado de haber entrado estos comandos en los dispositivos que estamos utilizando en esta configuración de ejemplo.

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

La priorización del identificador de conexión de enlace de datos (DLCI) es el proceso mediante el cual distintos tipos de tráfico se ubican en DLCI separados de modo tal que una red Frame Relay pueda brindar una velocidad de información comprometida diferente para cada tipo de tráfico. Puede utilizarse junto con custom queuing o priority queuing para ofrecer control de la administración del ancho de banda sobre el enlace de acceso a la red Frame Relay. Además, algunos proveedores del servicio Frame Relay y switches Frame Relay (como el Intercambio de paquetes entre redes de Stratacom [IPX], IGX y los switches BPX o AXIS) otorgan en realidad priorización dentro de la nube de Frame Relay según esta configuración de priorización.

Consideraciones de Implementación

Al implementar la priorización DLCI observe los siguientes puntos:

  • Si un DLCI secundario se desactiva, pierde el tráfico destinado sólo para esa cola.

  • Si pierde el DLCI primario, se desconecta la subinterfaz y pierde todo el tráfico.

Diagrama de la red

dlci_prior.gif

Para poder utilizar esta configuración, necesita contar con cuatro DLCI para el lado que usará la priorización DLCI. En este ejemplo, hemos configurado Spicey para priority queueing tal como se muestra a continuación:

  • Ping está en la cola prioritaria.

  • Telnet se encuentra en la cola de prioridad media.

  • El Protocolo transferencia de archivos (FTP) se encuentra en la cola de prioridad normal.

  • Todo el otro tráfico IP se encuentra en la cola de prioridad baja.

Nota: Asegúrese de configurar los DLCI para que coincidan con la lista de prioridad. En caso contrario, el sistema no empleará 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 siguientes comandos show y debug para probar que su red esté funcionando correctamente. Antes de ejecutar los comandos debug, consulte Información importante sobre los comandos de depuración.

  • show frame-relay pvc

  • show frame-relay map

  • show queueing priority

  • debug priority

La salida que aparece a continuación es el resultado de haber entrado estos comandos en los dispositivos que estamos utilizando en esta configuración de ejemplo.

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 comprobar la cola de prioridad, 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 va por la cola de prioridad 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#

Esta es la salida de depuración que se muestra en Spicey cuando utiliza el comando arriba mencionado para telnet a Spicey desde 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 difusión es una importante característica que se utiliza en redes IP o IPX medianas o grandes donde el ruteo y las difusiones del punto de acceso al servicio (SAP) deben fluir por la red de Frame Relay. La cola de transmisión se maneja independientemente de la cola normal de interfaz, posee sus propias memorias y cuenta con un tamaño y una velocidad de servicio que pueden ser configurados. Esta cola de transmisión no se utiliza para conectar en bridge las actualizaciones del árbol de expansión (BPDU) debido a las sensibilidades de sincronización. Estos paquetes fluirán a través de las colas normales. El comando de la interfaz para habilitar la cola de transmisión es el siguiente:

frame-relay broadcast-queue size byte-rate packet-rate

Se le otorga a una cola de transmisión un límite de velocidad máxima de transmisión (desempeño de procesamiento) medido en bytes por segundo y paquetes por segundo. La cola es mantenida para asegurar que sólo se ofrece el máximo. La cola de transmisión tiene prioridad cuando transmite a una velocidad por debajo del máximo configurado, y por lo tanto posee una asignación mínima garantizada de ancho de banda. Los dos límites de velocidad de transmisión tienen en el propósito de evitar que la interfaz se inunde con las transmisiones. El verdadero límite en cualquier segundo es el primer límite de velocidad que se alcanza. Dada la restricción de velocidad de transmisión, se requiere almacenamiento de memoria intermedia adicional para almacenar los paquetes de transmisión. La cola de transmisión se configura para almacenar números importantes de paquetes de transmisión. Debe configurarse el tamaño de la cola para evitar la pérdida de paquetes de actualización de routers de transmisión. El tamaño exacto depende del protocolo que se está usando y del número de paquetes que se requiere para cada actualización. Para asegurarse, el tamaño de la cola debe ser configurado de modo tal que pueda almacenarse una actualización completa de router de cada protocolo y para cada identificador de conexión de enlace de datos (DLCI). Como regla general, comience con 20 paquetes por DLCI. La velocidad de bytes debe ser menor que las dos siguientes:

  • N/4 veces la velocidad mínima de acceso remoto (medida en bytes por segundo), siendo N el número de DLCI por el cual se debe duplicar la transmisión.

  • 1/4 la velocidad de acceso (medida en bytes por segundo)

La velocidad de paquetes no es crítica si la velocidad del bit se configura de manera conservadora. En general, la velocidad de paquetes debería configurarse suponiendo paquetes de 250 bytes. Los valores predeterminados para las interfaces en serie son un tamaño de cola de 64, 256,000 bytes por segundo (2,048,000 bps) y 36 pps. Los valores predeterminados para la Interfaz en serie de alta velocidad (HSSI) son un tamaño de cola de 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 denominado filtro de cubeta con fichas. Este filtro de cubeta con fichas se configura de la siguiente manera:

ráfaga en exceso más ráfaga comprometida (Bc + Be) = velocidad máxima para el circuito virtual (VC)

El tráfico por encima de la velocidad máxima se almacena en una cola modeladora de tráfico que es igual al tamaño de la Weighted Fair Queuing (WFQ). El filtro de la cubeta con fichas no filtra el tráfico pero controla la velocidad a la que el tráfico se envía en la interfaz de salida. Para obtener más información sobre los filtros de cubeta con fichas, diríjase a Control de tráfico e Información general de modelado.

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

Parámetros de modelado de tráfico

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

  • CIR = velocidad de información comprometida (=tiempo medio)

  • EIR = excess information rate (velocidad de información en exceso)

  • TB = cubeta con fichas (= Bc + Be)

  • Bc = tamaño de ráfaga comprometido (= tamaño de ráfaga sostenido)

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

  • DE = calificado para descarte

  • Tc = intervalo de medición

  • AR = velocidad de acceso correspondiente a la velocidad de la interfaz física (entonces, si utiliza una T1, la AR es de aproximadamente 1.5 Mbps).

Veamos algunos de estos parámetros con mayor detalle:

Velocidad de acceso (AR)

El máximo número de bytes por segundo que una estación final puede transmitir en la red está delimitado por la velocidad de acceso de la interfaz de la red del usuario. La velocidad de línea de la conexión de la red de usuario limita la velocidad de acceso. Puede establecer esto en su suscripción con el proveedor del servicio.

Tamaño de ráfaga comprometida (Bc)

La cantidad máxima comprometida de datos que usted puede ofrecer a la red se define como Bc. Bc es una medida para el volumen de datos para los cuales 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 bytes no comprometidos (fuera de CIR) que aún son aceptados por el switch de Frame Relay pero están marcados como elegidos para descartar (DE).

La cubeta con fichas es un búfer 'virtual'. Contiene un número de fichas que le permiten enviar una cantidad limitada de datos por intervalo de tiempo. La cubeta con fichas se llena con bits Bc por Tc. El tamaño máximo de la cubeta es Bc + Be. Si Be es muy grande y si a T0 la cubeta se llena con Bc + Be , puede enviar bits Bc + Be. Esto no está limitado por Tc sino por el tiempo que lleva enviar el Be. Esta es una función de velocidad de acceso.

Committed Information Rate (CIR)

CIR es la cantidad de datos permitida que la red está comprometida a transferir en condiciones normales. La velocidad se calcula en promedio sobre un incremento de tiempo Tc. La CIRes también definida como el mínimo desempeño de procesamiento. Bc y Be se expresan en bits, Tc en segundos y la velocidad de acceso y CIR en bits por segundo.

Bc, Be, Tc y CIR se definen por identificador de conexión de enlace de datos (DLCI). Debido a esto, el filtro de cubeta con fichas controla la velocidad por DLCI. La velocidad de acceso es válida por interfaz de red de usuario. Para los valores Bc, Be y CIR entrantes y salientes puedan ser distinguidos. Si la conexión es simétrica, los valores en ambas direcciones son iguales. Para los circuitos virtuales permanentes, definimos a Bc, Be y CIR entrantes y salientes al momento de la suscripción.

  • Pico = Velocidad máxima de DLCI. El ancho de banda para ese DLCI particular.

  • Tc = Bc / CIR.

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

Si el Tc es un segundo, entonces:

  • Pico = CIR + Be = Bc + Be

  • EIR = Be

21_new1.gif

En el ejemplo aquí utilizado, el router envía tráfico entre 48 Kbps y 32 Kbps según la congestión existente en la red. Las redes pueden marcar tramas por encima de Bc con DE pero cuentan con amplia capacidad de repuesto para transportar la trama. Lo contrario también es posible : pueden tener capacidad limitada y descartar de manera inmediata las tramas en exceso. Las redes pueden marcar tramas por encima de Bc + Be con DE y posiblemente transportarla o simplemente dejar caer las tramas tal como lo sugiere el sector de estandarización de las telecomunicaciones de la Unión internacional de Telecomunicaciones , especificación ITU-T I.370. El modelador de tráfico disminuye la velocidad de tráfico basándose en la notificación explícita de la congestión retrospectiva (BECN) en los paquetes con etiquetas de la red del switch. Si usted recibe 50 por ciento de BECN, el router disminuye el tráfico a un octavo del ancho de banda actual para ese DLCI en particular.

Ejemplo:

La velocidad transmitida es de 42 Kb. El router disminuye la velocidad a 42 menos 42 dividido por 8 (42 - 42/8), lo que da como resultado 36.75 Kb. Si la congestión disminuye después del cambio, el router reduce más aún el tráfico, descendiendo a un octavo del ancho de banda actual transmitido. El tráfico se reduce hasta alcanzar el valor CIR configurado. No obstante, la velocidad puede disminuir por debajo del CIR aún cuando podamos ver los BECN. Puede especificar un límite inferior, como CIR/2. La red ya no está congestionada cuando todas las tramas recibidas desde la red dejan de poseer un bit BECN para un período dado. El valor predeterminado es 200 ms para este intervalo.

Modelado del tráfico genérico

La característica de Modelado de tráfico genérico es una herramienta de modelado de tráfico independiente de encapsulación y medios que contribuye en la reducción del flujo de tráfico saliente cuando existe congestión dentro de la nube, en el enlace o en el router final receptor. Podemos configurarlo en interfaces o subinterfaces dentro un router.

El modelado de tráfico genérico es práctico en las siguientes situaciones:

  • Cuando se tiene una topología de red que consiste en una conexión de alta velocidad (velocidad de línea T1) en el sitio central y conexiones de baja velocidad (menos de 56 kbps) en la rama o sitios de teletrabajadores. Debido a la discrepancia de velocidad, existe con frecuencia un cuello de botella para el tráfico en la rama o sitios de teletrabajadores donde el lado central envía datos a una velocidad mayor de la que los sitios remotos pueden recibir. Esto da como resultado un cuello de botella en el último switch antes del router de punto remoto.

  • Si usted es un proveedor de servicios que ofrece servicios a velocidades menores, esta característica le permite utilizar el router para particionar sus enlaces T1 o T3, por ejemplo, en canales de menor tamaño. Puede configurar cada subinterfaz con un filtro de cubeta con fichas que coincida con el servicio solicitado por un cliente.

Probablemente desee que en su conexión Frame Relay el router disminuya la velocidad del tráfico en lugar de enviarlo dentro de la red. Disminuir la velocidad del tráfico limitaría la pérdida del paquete en la nube del proveedor del servicio. La capacidad basada en BECN de disminuir la velocidad que acompaña esta característica le permite tener al router disminuyendo la velocidad del tráfico de manera dinámica, recibiendo paquetes con etiquetas BECN de la red. Esta disminución de la velocidad mantiene los paquetes en las memorias intermedias del router para reducir el flujo de datos desde el router a la red de Frame Relay. El router disminuye la velocidad del tráfico en una base de subinterfaz y la velocidad también aumenta cuando se recibe menor cantidad de paquetes con etiquetas BECN.

Comandos del modelado 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 disminuir la velocidad BECN en una interfaz de Frame Relay utilice este comando:

traffic-shape adaptive [bit-rate]

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

Nota: Debe activar el modelado de tráfico en la interfaz con el comando traffic-shape rate antes de que pueda usar el comando traffic-shape adaptive.

La velocidad de bits especificada para los comandos traffic-shape rate es el límite superior y la velocidad de bits especificada para el comando es el límite traffic-shape adaptive inferior (generalmente el valor CIR value) en el cual el tráfico se modela cuando la interfaz recibe BECN. La velocidad que se usa en realidad normalmente se encuentra entre estas dos. Es posible configurar el comando traffic-shape adaptive. en los dos extremos del enlace, ya que también esto configura el dispositivo en el final de flujo para reflejar las señales de la notificación explícita de la congestión en el reenvío (FECN) como BECN. Esto le permite al router en un final de alta velocidad detectar y adaptarse a la congestión incluso cuando el tráfico fluye principalmente en una dirección.

Ejemplo:

El siguiente ejemplo configura el modelado de tráfico en interfaz 0.1 con. un límite superior (generalmente Bc + Be) de 128 kbps y un límite inferior de 64 kbps. Esto le permite al enlace ejecutar desde 64 a 128 kbps, según el nivel de congestión. Si el lado central posee un límite superior de 256 kbps, debe usar el límite superior más bajo en cuanto a su valor.

21_new3.gif

Aquí se muestra lo que hemos configurado en estos 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 modelado genérico de tráfico, sólo se puede especificar una velocidad pico (límite superior) por interfaz física y un valor CIR (límite inferior) por subinterfaz. Con el modelado de tráfico de Frame Relay , se inicia un filtro de cubeta con fichas por circuito virtual.

La función del modelador de tráfico sobre Frame Relay brinda las siguientes capacidades:

  • Cumplimiento de velocidad sobre una base VC: Puede configurar una velocidad pico para limitar el tráfico saliente a CIR o algún otro valor definido como la velocidad excesiva de información (EIR).

  • Soporte de BECN generalizado por base VC: El router puede supervisar los BECN y disminuir la velocidad del tráfico según una respuesta de paquete marcado BECN desde la red de Frame Relay.

  • Soporte priority queuing (PQ), custom queuing (CQ) o WFQ en el nivel VC. Esto permite una granularidad más fina en la priorización y cola del tráfico, otorgándole más control sobre el flujo de tráfico sobre un VC individual. La función del modelador de tráfico sobre Frame Relay se aplica a los circuitos virtuales permanentes (PVC) de Frame Relay y 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 fichas.

  • Una funciona entre 64000 (CIR) y 128000(Bc + Be).

  • La otra funciona entre 16000 (CIR) y 64000 (Bc + Be).

Si el tráfico entrante desde Ethernet es mayor que el filtro de cubeta con fichas, el tráfico se almacena en la memoria intermedia en la cola de tráfico de frame-relay.

Para ver una tabla de flujo que muestre el flujo del paquete cuando se implementa el modelador de tráfico de Frame Relay, consulte Diseño del Frame Relay Frame Relay Traffic Flowchart (diagrama de flujo del diseño de Frame Relay). Para ver un diagrama de flujo usando específicamente un filtro de cubeta con fichas, consulte Frame Relay Traffic Shaping - Token Bucket Flowchart (modelador de tráfico de Frame Relay: diagrama de flujo de cubeta con fichas).

Comandos de Frame Relay utilizados comúnmente

En esta sección se describen dos comandos de Cisco IOS® que son especialmente útiles a la hora de configurar Frame Relay.

show frame-relay pvc

Este comando muestra el estado del circuito virtual permanente (PVC), paquetes dentro y fuera, paquetes descartados si hay congestión en la línea a través de notificación explícita de la congestión en el reenvío (FECN) y notificación explícita de la congestión retrospectiva (BECN), etc. Para una descripción detallada de los campos utilizados con el comando show frame-relay pvc, haga clic aquí.

Si tiene el resultado de un comando show frame-relay pvc del dispositivo Cisco, podrá utilizar la herramienta Output Interpreter (solamente clientes registrados) para mostrar posibles problemas y sus soluciones.

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 DLCI USAGE contiene una de las siguientes entradas:

  • SWITCHED: el router o servidor de acceso se utiliza como switch.

  • LOCAL: el router o servidor de acceso se utiliza como equipo de terminal. de datos (DTE).

  • UNUSED: no se hace referencia al identificador de conexión de enlace de datos (DLCI) en los comandos de configuración introducidos por el usuario en el router.

El PVC puede tener cuatro posibles estados, que aparecen en el campo PVC STATUS tal como se muestra a continuación:

  • ACTIVE: el PVC está activo y funciona normalmente.

  • INACTIVE: el PVC no se encuentra activo de extremo a extremo. Esto puede deberse a que no existe asignación (o asignación incorrecta) para el DLCI local en la nube de retransmisión de tramas o el final remoto de PVC se ha eliminado.

  • DELETED: la Interfaz de administración local (LMI) no se ha intercambiado entre el router y el switch local o el switch no posee DLCI configurado en el switch local.

  • STATIC: no existe señal de mantenimiento configurada en la interfaz de retransmisión de tramas del router.

show frame-relay map

Utilice este comando para determinar si frame-relay inverse-arp resolvió una dirección IP remota a un DLCI local. Este comando no está habilitado para subinterfaces punto a punto. Esto resulta útil únicamente para interfaces multipunto y subinterfaces. 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 obtener una descripción detallada de los campos utilizados con el comando show frame-relay map, consulte Documentación sobre comandos frame relay .

Si tiene el resultado de un comando show frame-relay map del dispositivo Cisco, podrá utilizar la herramienta Output Interpreter (solamente clientes registrados) para mostrar posibles problemas y sus soluciones.

Transmisión de tramas y conexión en bridge

Los mensajes de configuración denominados unidades de datos del protocolo del bridge (BPDU) se utilizan en los protocolos del árbol de expansión soportados por los bridges y routers de Cisco. Éstos fluyen a intervalos regulares entre bridges y constituyen una significativa cantidad de tráfico debido a su ocurrencia frecuente. Existen dos tipos de protocolos de árbol de expansión en el uso de bridges transparentes. Introducido por primera vez por Digital Equipment Corporation (DEC), el algoritmo fue luego revisado por el comité IEEE 802 y publicado en la especificación IEEE 802.1d. El Spanning Tree Protocol de DEC emite BPDU a intervalos de un segundo, mientras que el IEEE lo hace a intervalos de dos segundos. Cada paquete posee 41 bytes, que incluyen un mensaje BPDU de configuración de 35 bytes, un encabezado de retransmisión de tramas de 2 bytes, Ethertype de 2 bytes y FCS de 2 bytes.

Retransmisión de tramas y memoria

El consumo de memoria para los recursos de Frame Relay se produce en cuatro áreas:

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

  2. Cada sentencia de correspondencia: 96 bytes (o mapa construido de manera dinámica)

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

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

Por ejemplo, un Cisco 2501 que utiliza dos interfaces de Frame Relay, cada una con cuatro subinterfaces, con un total de ocho DLCI y mapas asociados necesita lo siguiente:

  • 2 hardware de interfaces IDB x 13.386 = 26.772

  • 8 subinterfaces IDB x 2260 = 18.080 subinterfaces

  • 8 DLCI x 216 = 1728 DLCI

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

El total es de 47.348 bits de RAM utilizada.

Nota: Los valores utilizados son válidos para las versiones 11.1, 12.0 y 12.1 del software Cisco IOS.

Resolución de problemas de Frame Relay

Esta sección contiene partes de resultados posibles del comando show interface que pueden obtenerse al resolver problemas. También se brindan explicaciones sobre el resultado.

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

Este resultado significa que tiene un problema con el cable, la unidad de servicio del canal/unidad de servicio de datos (CSU/DSU) o la línea en serie. Necesita resolver el problema con una prueba de bucle de retorno. Para hacerlo, siga los pasos indicados a continuación:

  1. Configure la encapsulación de la línea en serie a HDLC y el mantenimiento a 10 segundos. Para hacerlo, ejecute los comandos encapsulation hdlc y keepalive 10 bajo la interfaz en serie

  2. Coloque el CSU/DSU o módem en el modo de bucle local. Si el protocolo de línea aparece cuando el CSU, DSU o módem se encuentran en el modo de bucle de retorno local [indicado por un mensaje de “line protocol is up (looped)” (protocolo de línea activado (en bucle))], esto sugiere que el problema está produciéndose más allá del CSU/DSU local. Si la línea de estado no cambia los estados, posiblemente exista 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 es con el CSU/DSU o módem.

  3. Haga ping a su propia dirección IP con el CSU/DSU o módem en bucle. No debería haber pérdidas. Una extensión de ping de 0x0000 es útil para resolver problemas de la línea ya que un T1 o E1 derivan el reloj de los datos y requieren una transición cada 8 bits. B8ZS lo asegura. Un patrón de datos de muchos ceros ayuda a determinar si las transiciones se fuerzan debidamente en la troncal. Un patrón de muchos unos se utiliza para simular correctamente una gran carga cero en caso de que existan un par de inversores en el trayecto. El patrón alterno (0x5555) representa un patrón de datos “típico”. Si sus pings fallan o le aparecen errores de verificación de redundancia cíclica (CRC), lo que necesita es un probador de índice de error de bit (BERT) con un analizador apropiado.

  4. Al finalizar la prueba, asegúrese de que retorna la encapsulación a Frame Relay.

Serial0 activo, protocolo de línea no funciona

Esta línea en el resultado significa que el router está obteniendo una señal portadora del CSU/DSU o módem. Verifíquelo para asegurarse de que el proveedor de Frame Relay ha activado su puerto y que las configuraciones de la interfaz de administración local (LMI) coinciden. Generalmente, el switch de Frame Relay ignora el equipo terminal de datos (DTE) a menos que vea la LMI correcta (utilice la configuración predeterminada de Cisco en LMI "cisco"). Asegúrese de que el router de Cisco esté transmitiendo datos. Es muy probable que necesite verificar la integridad de la línea mediante pruebas de bucles en varias ubicaciones comenzando con el CSU local y dirigiéndose hasta llegar al switch del proveedor de Frame Relay. Diríjase a la sección anterior para ver cómo se realiza una prueba de bucle de retorno.

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

Si no apagó las señales de mantenimiento, esta línea de resultado significa que el router está hablando con el switch del proveedor de Frame Relay. Debería estar viendo un intercambio exitoso de tráfico de dos vías en la interfaz en serie sin errores CRC. Las señales de mantenimiento son necesarias en Frame Relay debido a que son el mecanismo que el router utiliza para “aprender” cuáles son los identificadores de conexiones de enlaces de datos (DLCI) que el proveedor ha suministrado. Para observar el intercambio, puede utilizar de manera segura debug frame-relay lmi en prácticamente todas las situaciones. El comando debug frame-relay lmi genera muy pocos mensajes y puede proporcionar respuestas a preguntas tales como:

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

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

  3. ¿Son correctos los DLCI?

A continuación se muestran algunos resultados de ejemplo de debug frame-relay lmi desde una conexión exitosa:

*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, estado 0x2

Observe el estado de "DLCI 980" en el resultado anterior. Los valores posibles del campo de estado se explican a continuación:

  1. 0x0: Agregado/inactivo significa que el switch tiene este DLCI programado por alguna razón (como el otro final de este PVC está desactivado), no puede utilizarse.

  2. 0x2: Agregado/activo significa que el switch de Frame Relay tiene el DLCI y todo está en funcionamiento. Puede empezar a enviarle tráfico con este DLCI en el encabezado.

  3. 0x3: 0x3 es una combinación de un estado activo (0x2) y el RNR (o bit-r) que está configurado (0x1). Esto significa que el switch, o una cola determinada en el switch, para este PVC posee una copia de respaldo y usted detiene la transmisión en caso de que las tramas se desborden.

  4. 0x4: Eliminado significa que el switch de Frame Relay no cuenta con este DLCI programado para el router. Sin embargo, fue programado en algún momento anterior. Esto también pudo haber sido causado al invertir los DLCI en el router o al eliminar el PVC en la nube de transmisión de tramas por parte de la compañía telefónica. La configuración de un DLCI (que el switch no posee) aparecerá como un 0x4.

  5. 0x8: Nuevo/inactivo

  6. 0x0a: Nuevo/activo

Características de Frame Relay

En esta sección se explican varias características de Frame Relay sobre las cuales usted debería tener conocimiento.

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

De manera predeterminada, la verificación de división de horizonte IP no está habilitada para la encapsulación de Frame Relay, de modo que las actualizaciones del router entran y salen de la misma interfaz. Los routers conocen los identificadores de conexiones de enlace de datos (DLCI) que necesitan utilizar del switch de Frame Relay a través de las actualizaciones de la interfaz de administración local (LMI). Los routers usan el ARP inverso para la dirección IP remota y crean una asignación de DLCI locales y sus direcciones IP remotas. Además, algunos protocolos como el AppleTalk, la conexión en bridge transparente e IPX no pueden soportarse en redes parcialmente malladas, ya que requieren “división de horizonte” en la cual un paquete recibido en una interfaz no puede transmitirse hacia fuera desde la misma interfaz, aunque el paquete reciba y transmita en distintos circuitos virtuales. La configuración de las subinterfaces de Frame Relay asegura que una sola interfaz física sea tratada como múltiples interfaces virtuales. Esta capacidad nos permite superar las reglas de división del horizonte. Los paquetes recibidos en una interfaz virtual ahora pueden enviarse a otra interfaz virtual, incluso si están configurados en la misma interfaz física.

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

No puede hacer ping en su propia dirección IP en una interfaz multipunto de Frame Relay. Esto ocurre porque las (sub)interfaces multipunto de Frame Relay no son difundidas (a diferencia de las interfaces Ethernet y las punto a punto del Control de enlace de datos de alto nivel [HDLC]) y las subinterfaces punto a punto Frame Relay.

Asimismo, tampoco puede hacer ping desde una radio a otra en una configuración radial. Esto ocurre porque no hay asignación para su propia dirección IP (y no se aprendió ninguna a través del ARP Inverso). Sin embargo, si configura una correlación estática (mediante el comando frame-relay map) para su propia dirección IP (o uno para la radio remota) para usar el DLCI local, entonces puede hacer ping en 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

   !

   interfaz 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 broadcast brinda dos funciones: envía difusiones cuando la multidifusión no está activada, y simplifica la configuración Open Shortest Path First (OSPF) para las redes sin difusión que utilizan Frame Relay.

También puede requerirse la palabra clave broadcast para algunos protocolos de ruteo (por ejemplo, AppleTalk) que dependen de actualizaciones regulares de tablas de ruteo, especialmente cuando el router en el final remoto está esperando que llegue un paquete de actualización de ruteo antes de agregar la ruta.

Al requerir la selección de un router designado, OSPF trata a una red de accesos múltiples y sin difusión como la de Frame Relay de la misma manera como trata a una red de difusión. En versiones anteriores, ésta requería una asignación manual en la configuración OSPF mediante el comando neighbor interface router. Si el comando frame-relay map está incluido en la configuración con la palabra clave broadcast y el comandoip ospf network (con la palabra clave broadcast ) está configurado, no es necesario configurar ningún vecino manualmente. OSPF ahora se ejecuta automáticamente sobre la red de Frame Relay como una red de difusión. (Consulte el comando ip ospf network interface para obtener más detalles.)

Nota: El mecanismo de difusión de OSPF supone que las direcciones IP clase D jamás se utilizan para el tráfico normal en Frame Relay.

Ejemplo:

El siguiente ejemplo asigna la dirección IP de destino 172.16.123.1 a DLCI 100:

interface serial 0

 frame-relay map IP 172.16.123.1 100 broadcast 

OSPF usa DLCI 100 para difundir actualizaciones.

Reconfiguración de una subinterfaz

Una vez que se crea un tipo específico de subinterfaz, no se puede cambiar sin una recarga. Por ejemplo, no puede crear una subinterfaz multipunto en serie 0,2 y luego cambiarla a punto a punto. Para cambiarla, es necesario recargar el router o crear otra subinterfaz. Este es el modo en que el código de Frame Relay funciona en el software Cisco IOS®.

Limitaciones de DLCI

Espacio de dirección DLCI

Aproximadamente 1000 DLCI pueden configurarse en un solo enlace físico, dada una dirección de 10 bits. Debido a que algunos DLCI están reservados (dependientes de la implementación del proveedor), el máximo es de aproximadamente 1000. El rango para un Cisco LMI es 16-1007. El rango establecido para ANSI/ITU es 16-992. Estos son los transportadores de datos de usuarios DLCI.

Sin embargo, al confirmar los VC de Frame Relay en subinterfaces, es necesario considerar un límite práctico conocido como el límite IDB. El número total de interfaces y subinterfaces por sistema está limitado por el número de bloques de descriptores de interfaces (IDB) que soporta su versión de Cisco IOS. Un IDB es una porción de memoria que mantiene información sobre la interfaz tal como contadores, estado de la interfaz, etc. IOS mantiene un IDB para cada interfaz presente en la plataforma y un IDB por cada subinterfaz. Las interfaces de mayor velocidad requieren más memoria que las de menor velocidad. Cada plataforma contiene distintas cantidades de IDB máximos y estos límites pueden cambiar con cada versión de Cisco IOS.

Para obtener más información, consulte Cantidad máxima de interfaces y subinterfaces para plataformas con el software del IOS de Cisco: Límites IDB.

Actualización del estado de LMI

El protocolo LMI requiere que todos los informes de estado de los circuitos virtuales permanentes (PVC) se acomoden en un solo paquete y normalmente limita el número de DLCI a menos de 800, según el tamaño de la unidad máxima de transmisión (MTU).

equation.gif

La configuración predeterminada MTU para las interfaces en serie es de 1500 bytes, llegando a un máximo de 296 DLCI por interfaz. Puede aumentar el MTU para soportar un mensaje de actualización de estado completo mayor del switch de Frame Relay. Si el mensaje de actualización de estado completo es mayor que la interfaz MTU, el paquete se pierde y se aumenta el contador de interfaces gigantes. Al cambiar la MTU, asegúrese de que se configure el mismo valor en el router remoto y en los dispositivos de red participantes.

Observe que estos números varían levemente, según el tipo de LMI. Los DLCI máximos por guía de plataforma (no interfaz) de router, basado en la extrapolación desde los datos empíricos establecidos en una plataforma de router Cisco 7000 aparecen a continuación:

  • 2500 de Cisco: 1 X T1/E1 enlace a 60 DLCI por interfaz = 60 total

  • 4000 de Cisco: 1 X T1/E1 enlace a 120 DLCI por interfaz = 120 total

  • 4500 de Cisco: 3 X T1/E1 enlaces a 120 DLCI por interfaz = 360 total

  • 4700 de Cisco: 4 X T1/E1 enlaces a 120 DLCI por interfaz = 480 total

  • 7000 de Cisco: 4 X T1/E1/T3/E3 enlaces a 120 DLCI por interfaz = 480 total

  • Cisco 7200 5 X T1/E1/T3/E3 enlaces a 120 DLCI por interfaz = 600 total

  • 7500 de Cisco: 6 X T1/E1/T3/E3 enlaces a 120 DLCI por interfaz = 720 total

Nota: Estos números sólo representan pautas y suponen que todo el tráfico es de conmutación rápida.

Otras consideraciones

Un límite DLCI práctico depende también de si los VC están funcionando con un protocolo de ruteo dinámico o estático. Los protocolos de ruteo dinámicos y otros protocolos como el IPX SAP que intercambian tablas de bases de datos, envían saludos y mensajes con información de reenvío que deben ser vistos y procesados por la CPU. Como regla general, la utilización de routers estáticos le permitirán configurar un número mayor de VC en una sola interfaz de Frame Relay.

Dirección IP/IPX/AT

Si está utilizando subinterfaces, no ponga una dirección IP, IPX o AT en la interfaz principal. Asigne DLCI a sus interfaces antes de habilitar la interfaz principal para asegurarse de que frame-relay inverse-arp funciona adecuadamente. En caso de que no funcione bien, realice los pasos que aparecen a continuación:

  1. Desactive el protocolo de resolución de dirección inversa (ARP) para ese DLCI mediante los comandos no frame-relay inverse-arp ip 16 y clear frame-relay-inarp.

  2. Corrija su configuración.

  3. Active el comando frame-relay inverse-arp nuevamente.

RIP y IGRP

Las actualizaciones del Routing Information Protocol (RIP) fluyen cada 30 segundos. Cada paquete RIP puede contener hasta 25 entradas de ruta, para un total de 536 bytes; 36 bytes de este total son la información del encabezado y cada entrada de ruta posee 20 bytes. Por lo tanto, si usted difunde 1000 routers a través de un enlace de Frame Relay configurado para 50 DLCI, el resultado es 1 MB de datos actualizados de router cada 30 segundos o 285 kbps de ancho de banda consumido. En un enlace T1, este ancho de banda representa el 18,7 por ciento del ancho de banda, con una duración de cada actualización de 5,6 segundos. Esta cantidad de gastos es considerable y se encuentra al límite de lo aceptable, pero la velocidad de información comprometida (CIR) debería estar en la región de velocidad de acceso. Obviamente, nada menor a T1 incurriría en tanto gasto. Por ejemplo:

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

  • 1000 X 20 bytes = 20.000 bytes de entradas de ruta

  • Total 21.440 bytes X 50 DLCI = 1072 MB de actualizaciones RIP cada 30 segundos.

  • 1.072.000 bytes / 30 segundos X 8 bits = 285 kbps

El Interior Gateway Routing Protocol (IGRP) actualiza el flujo cada 90 segundos (este intervalo se puede configurar). Cada paquete IGRP puede contener 104 entradas de ruta, para un total de 1492 bytes, 38 de las cuales son información de encabezado y cada entrada de ruta es de 14 bytes. Si usted difunde 1000 routers a través de un enlace de Frame Relay configurado con 50 DLCI, la solicitud es de aproximadamente 720 KB de actualización de datos de ruteo cada 90 segundos o 64 kbps de ancho de banda consumido. En un enlace T1, este ancho de banda representaría el 4,2 por ciento del ancho de banda, siendo cada duración de actualización de 3,7 segundos. Este consumo es un monto aceptable:

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

  • 1000 X 14 = 14.000 bytes de entradas de ruta

  • Total = 14.342 bits X 50 DLCI = 717 KB de IGRP actualiza cada 90 segundos.

  • 717.000 bytes / 90 X 8 bits = 63,7 kbps

Las actualizaciones de ruteo del Protocolo de la tabla de mantenimiento del ruteo (RTMP) se producen cada 10 segundos (este intervalo se puede configurar). Cada paquete RTMP puede contener hasta 94 entradas ampliadas de ruta, para un total de 564 bytes, 23 bytes de información de encabezado y cada entrada de ruta es de 6 bytes. Si usted difunde 1000 redes AppleTalk a través de un enlace de Frame Relay configurado para 50 DLCI, el resultado es de aproximadamente 313 KB de actualizaciones RTMP cada 10 segundos o 250 kbps de ancho de banda consumido. Para permanecer dentro de un nivel aceptable de consumo del 15 por ciento o menos), se requiere una velocidad T1. Por ejemplo:

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

  • 1000 X 6 = 6000 bytes de entradas de ruta

  • Total = 6253 X 50 DLCI = 313 KB de actualizaciones RTMP cada 10 segundos

  • 313.000 / 10 segundos X 8 bits = 250 kbps

Las actualizaciones del paquete IPX RIP se producen cada 60 segundos (este intervalo se puede configurar). Cada paquete IPX RIP puede contener hasta 50 entradas de ruta, para un total de 536 bytes, 38 bytes de información del encabezado y cada entrada de ruta posee 8 bytes. Si usted difunde 1000 routers IPX a través de un enlace de Frame Relay configurado para 50 DLCI, el resultado es de 536 KB de actualizaciones de IPX cada 60 segundos o 58,4 kbps de ancho de banda consumido. Para permanecer dentro de un nivel aceptable de consumo (15 por ciento o menos), se requiere una velocidad de 512 kpbs. Por ejemplo:

  • 1000/50 = 20 paquetes X 38 bytes = 760 bytes del encabezado

  • 1000 X 8 = 8000 bytes de entradas de ruta

  • Total = 8760 X 50 DLCI = 438.000 bytes de actualizaciones de IPX cada 60 segundos.

  • 438.000 / 60 segundos X 8 bits = 58,4 kbps

Las actualizaciones del paquete IPX de punto de acceso al servicio (SAP) se producen cada 60 segundos (este intervalo se puede configurar). Cada paquete IPX SAP puede contener hasta siete entradas de difusión para un total de 536 bytes, 38 de los cuales son información de encabezado y cada entrada difundida posee 64 bytes. Si difunde 1000 avisos IPX a través de un enlace de Frame Relay configurado para 50 DLCI, finalizará con 536 KB de actualizaciones de IPX cada 60 segundos o 58,4 kbps de ancho de banda consumidos. Para permanecer dentro de un nivel aceptable de consumo (el 15 por ciento o menos), se requiere una velocidad mayor a 2 Mbps. Claramente se requiere aquí un filtro SAP. Comparándolo con todos los otros protocolos mencionados en esta sección, las actualizaciones de IPX SAP requieren el máximo de ancho de banda:

  • 1000/7 = 143 paquetes X 38 bytes = 5434 bytes del encabezado

  • 1000 X 64 = 64.000 bytes de entradas de ruta

  • Total = 69.434 X 50 DLCI = 3.471.700 bytes de servicio IPX avisos cada 60 segundos

  • 3.471.700 / 60 segundo X 8 bits = 462 kbps

Keepalive

En algunos casos, la señal de mantenimiento en el dispositivo Cisco necesita una configuración ligeramente menor (aproximadamente 8 segundos) que la señal de mantenimiento en el switch. Verá la necesidad de ello si la interfaz asciende y desciende constantemente.

Interfaces en serie

Las interfaces en serie, que de manera predeterminada son multipunto, son medios de no transmisión, mientras que las subinterfaces punto a punto son de transmisión. Si está usando rutas estáticas, puede apuntar al siguiente salto (next hop) o a la subinterfaz en serie. Para multipunto, necesita apuntar al siguiente salto (next hop). Este concepto es muy importante al realizar OSPF sobre Frame Relay. El router necesita saber que esto es una Interfaz de difusión para que OSPF funcione.

OSPF y multipunto

OSPF y multipunto pueden presentar muchos problemas. OSPF necesita un router designado (DR). Si comienza a perder PVC, algunos routers pueden perder conectividad y tratar de convertirse en un DR a pesar de que otros routers aún vean el antiguo DR. Esto hace que el proceso OSPF funcione incorrectamente.

El consumo asociado con OSPF no es obvio ni puede predecirse como los protocolos tradicionales de ruteo del vector de distancia. Lo imprevisible surge de si los enlaces a redes OSPF son o no estables. Si todas las adyacencias a un router Frame Relay son estables, sólo los paquetes vecinos de saludos (señales de mantenimiento) fluirán, lo que resulta ser un consumo comparativamente menor que el incurrido con un protocolo del vector de distancia (como el RIP y el IGRP). No obstante, si las rutas (adyacencias) no son estables, se producirá una inundación del estado de los enlaces y el ancho de banda puede consumirse rápidamente. OSPF también consume intensamente el procesador al ejecutar el algoritmo Dijkstra, usado para calcular rutas.

En las versiones anteriores del software Cisco IOS, se debía tener especial cuidado al configurar OSPF sobre medios de acceso múltiple sin difusión (OSPF) como Frame Relay, X.25 y ATM. Este protocolo OSPF considera a estos medios como a cualquier otro medio de difusión como Ethernet. Las nubes de acceso múltiple sin difusión (NBMA) generalmente se construyen en una topología radial. Los PVC o los circuitos virtuales conmutados (SVC) se elaboran sobre una malla parcial y la topología física no proporciona el acceso múltiple que OSPF cree que hay allí. Para el caso de interfaces en serie punto a punto, OSPF siempre forma una adyacencia entre los vecinos. Las adyacencias OSPF (Abrir la ruta más corta en primer lugar) intercambian información de la base de datos. Para reducir la cantidad de intercambio de información en un segmento determinado, OSPF selecciona un router para que sea DR y uno como router designado de respaldo (BDR) en cada segmento de acceso múltiple. 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 los routers tengan un punto central de contacto para el intercambio de la información. La selección de DR se convierte en un problema debido a que el DR y el BDR necesitan una conectividad física total con todos los routers que existen en la nube. Además, debido a la falta de capacidades de transmisión, el DR y BDR necesitan tener una lista estática de todos los otros routers conectados a la nube. Esta configuración se logra a través del comando neighbor:

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

En las versiones posteriores del software Cisco IOS, pueden usarse diferentes métodos para evitar las complicaciones de configurar vecinos estáticos y tener routers específicos convirtiéndose en DR o BDR en la nube sin difusión. El método que se usa depende de si la red es nueva o un diseño ya existente que necesita 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 definir cada una de las subinterfaces como punto a punto. Originalmente, esto se creó para manejar mejor los problemas ocasionados por un horizonte dividido de NBMA y los protocolos de ruteo basados en vectores.

Una subinterfaz punto a punto tiene las propiedades de toda interfaz punto a punto física. En lo que respecta a OSPF, siempre se forma una adyacencia sobre una subinterfaz punto a punto sin elección de DR ni BDR. OSPF (Abrir la ruta más corta en primer lugar) considera a la nube como un conjunto de enlaces punto a punto más que como una red de acceso. múltiple. El único inconveniente del punto a punto es que cada segmento pertenece a una subred diferente. Es posible que esto no se acepte, ya que algunos administradores ya tienen asignada una subred IP para la nube completa. Otra solución alternativa es utilizar las interfaces IP sin numerar en la nube. Esto también puede presentar un problema para algunos administradores que administran la WAN basada en en direcciones IP de las líneas en serie.

Fuentes

  1. Comité consultor de telegrafía y telefonía internacional, “ISDN Data Link Layer Specification for Frame Mode Bearer Services”, Recomendación de CCITT Q.922, del 19 de abril de 1991.

  2. Normas Nacionales Estadounidenses para Telecomunicaciones, Integradas Services Digital Network - Core Aspects of Frame Protocol for Use with Frame Relay Bearer Service (Services Digital Network: aspectos centrales del protocolo de tramas para usar con los servicios de FrameRelay), ANSI T1.618-1991, 18 de junio de 1991.

  3. Tecnología de la información – Intercambio de información y telecomunicaciones entre sistemas: Identificación de protocolo en la Capa de Red, ISO/IEC TR 9577: 1990 (E) 15-10-1990.

  4. International Standard, Information Processing Systems - Local Area Networks - Logical Link Control, ISO 8802-2: 1989 (E), IEEE Std 802.2-1989, 1989-12-31.

  5. Internetworking Technology Overview, octubre de 1994, Cisco Systems

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

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

  8. RFC 1490-Multiprotocol encapsulationleavingcisco.com

  9. RFC 1315-Frame Relay MIBleavingcisco.com

  10. RFC 1293-Frame Relay Inverse ARPleavingcisco.com

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

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

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

  14. FRF 3.1-Multiprotocol encapsulation

  15. FRF 4-SVC

  16. FRF 6-Administración de red de usuarios adheridos al servicio de Frame Relay (MIB)

  17. Grupo de cuatro LMI

  18. P.922 Anexo A

  19. ANSI T1.617 Anexo D

  20. ANSI T1.618, T1.606

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

  22. OSPF, Guía de Diseño

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


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 16563