Contenido

Introducción

Antes de comenzar

Convenciones

Prerequisites

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 perfiles de marcador

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 puente

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

Información Relacionada

Introducción

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

En la figura anterior, las direcciones Q.922, tal como se definen actualmente, son dos octetos y contienen un identificador de conexión de enlace de datos (DLCI) de 10 bits. En algunas redes, las direcciones Q.922 pueden aumentarse opcionalmente a tres o cuatro octetos.

Los campos "indicador" delimitan el principio y el final del marco. A continuación del campo "indicador" principal se muestran dos bytes de información de dirección. Diez bits de estos dos bytes constituyen el ID de circuito real (denominado DLCI, para el identificador de conexión de link de datos).

El valor DLCI de 10 bits es el corazón del encabezado de Frame Relay. Identifica la conexión lógica que se multiplexa en el canal físico. En el modo básico de direccionamiento (es decir, no extendido por la interfaz de administración local [LMI]), los DLCI tienen importancia local; es decir, los dispositivos finales en dos extremos diferentes de una conexión pueden utilizar un DLCI diferente para hacer referencia a esa misma conexión.

Antes de comenzar

Convenciones

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

Prerequisites

Para obtener más información y definiciones de los términos utilizados 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 originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Teoría Precedente

Frame Relay se concibió originalmente como un protocolo para su uso sobre interfaces ISDN. Las propuestas iniciales a tal efecto se presentaron al Sector de Normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones (UIT-T) (antes Comité Consultivo para Telégrafos y Teléfonos Internacionales [CCITT]) en 1984. El trabajo sobre Frame Relay también se llevó a cabo en el comité de normas T1S1 acreditado por ANSI en Estados Unidos.

En 1990, Cisco Systems, StrataCom, Northern Telecom y Digital Equipment Corporation formaron un consorcio para centrar el desarrollo de tecnología Frame Relay y acelerar la introducción de productos de Frame Relay interoperables. Desarrollaron una especificación conforme al protocolo básico Frame Relay que se discute en T1S1 e ITU-T, pero la ampliaron con funciones que proporcionan capacidades adicionales para entornos de interconexión entre redes complejos. Estas extensiones de Frame Relay se denominan colectivamente LMI. Este es el LMI "cisco" en el router en lugar del LMI "ansi" o "q933a".

Frame Relay proporciona una capacidad de comunicación de datos de conmutación de paquetes que se utiliza a través de la interfaz entre los dispositivos de usuario (como routers, puentes, máquinas host) y el equipo de red (como nodos de conmutación). A los dispositivos de usuario se les suele llamar equipo de terminal de datos (DTE), mientras que a los equipos de red que interactúan con DTE se les suele llamar equipo de terminación de circuito de datos (DCE). La red que proporciona la interfaz de Frame Relay puede ser una red pública provista por el operador o una red de equipos privados que atienden a una única empresa.

Frame Relay difiere significativamente de X.25 en su funcionalidad y formato. En particular, Frame Relay es un protocolo más simplificado que facilita un mayor rendimiento y una mayor eficiencia.

Como interfaz entre el usuario y el equipo de red, Frame Relay proporciona un medio para multiplexar estadísticamente muchas conversaciones de datos lógicos (llamadas circuitos virtuales) en un único enlace de transmisión física. Esto contrasta con los sistemas que utilizan únicamente técnicas de multiplexación por división de tiempo (TDM) para admitir varias secuencias de datos. La multiplexación estadística de Frame Relay proporciona un uso más flexible y eficiente del ancho de banda disponible. Se puede utilizar sin técnicas TDM o sobre los canales proporcionados por los sistemas TDM.

Otra característica importante de Frame Relay es que aprovecha los recientes avances en la tecnología de transmisión de red de área extensa (WAN). Los protocolos WAN anteriores, como X.25, se desarrollaron cuando predominaban los sistemas de transmisión analógicos y los medios de cobre. Estos enlaces son mucho menos fiables que los enlaces de transmisión digital/medios de fibra disponibles en la actualidad. En links como estos, los protocolos de capa de link pueden prescindir de algoritmos de corrección de errores que requieren mucho tiempo, lo que los deja en capas de protocolo más altas. Por lo tanto, es posible lograr un mayor rendimiento y eficacia sin sacrificar la integridad de los datos. Frame Relay está diseñado teniendo en cuenta este enfoque. Incluye un algoritmo de verificación por redundancia cíclica (CRC) para detectar bits dañados (de modo que se puedan descartar los datos), pero no incluye ningún mecanismo de protocolo para corregir datos incorrectos (por ejemplo, retransmitirlos a este nivel de protocolo).

Otra diferencia entre Frame Relay y X.25 es la ausencia de control de flujo explícito por circuito virtual en Frame Relay. Ahora que muchos protocolos de capa superior están ejecutando de manera efectiva sus propios algoritmos de control de flujo, la necesidad de esta funcionalidad en la capa de link ha disminuido. Por lo tanto, Frame Relay no incluye procedimientos de control de flujo explícitos que dupliquen los de capas superiores. En su lugar, se proporcionan mecanismos de notificación de congestión muy simples para permitir que una red informe a un dispositivo de usuario que los recursos de red están cerca de un estado congestionado. Esta notificación puede alertar a los protocolos de capa superior de que puede ser necesario el control de flujo.

Configuración de Basic Frame Relay

Una vez que tenga conexiones confiables al switch de Frame Relay local en ambos extremos del circuito virtual permanente (PVC), es el momento de comenzar a planificar la configuración de Frame Relay. En este primer ejemplo, el tipo LMI (Local Management Interface, LMI) de forma predeterminada es LMI "cisco" en Spicey. Una interfaz es de forma predeterminada una interfaz "multipunto", por lo que frame-relay inverse-arp está activada (para punto a punto, no hay ARP inverso). La verificación del horizonte dividido de IP está inhabilitada de forma predeterminada para la encapsulación de Frame Relay, por lo que las actualizaciones de ruteo entran y salen de la misma interfaz. Los routers aprenden los identificadores de conexión de link de datos (DLCI) que necesitan utilizar desde el switch Frame Relay a través de las actualizaciones LMI. Los routers luego Inverse ARP para la dirección IP remota y crean un mapping de DLCI locales y sus direcciones IP remotas asociadas.

Diagrama de la red

Configuraciones

- Spicey

- Prasit

Spicey

Spicey#show running-config

Building configuration...

Current configuration : 1705 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 3.1.3.1 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 140

!

!

router rip

network 3.0.0.0

network 124.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1499 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

!

interface Serial1

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 150

!

!

router rip

network 3.0.0.0

network 123.0.0.0

!

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Comandos debug y show

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

- show frame-relay map

- show frame-relay pvc

- show frame-relay lmi

- ping <nombre del dispositivo>

- show ip route

Spicey

Spicey#show frame-relay map

Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,

broadcast,, status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 83            output pkts 87           in bytes 8144

out bytes 8408           dropped pkts 0           in FECN pkts0

in BECN pkts 0           out FECN pkts 0          out BECN pkts0

in DE pkts 0             out DE pkts 0

out bcast pkts 41         out bcast bytes 3652

pvc create time 01:31:50, last time pvc status changed 01:28:28

Spicey#show frame-relay lmi

LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO

Invalid Unnumbered info 0             Invalid Prot Disc 0

Invalid dummy Call Ref 0              Invalid Msg Type 0

Invalid Status Message 0              Invalid Lock Shift 0

Invalid Information ID 0              Invalid Report IE Len 0

Invalid Report Request 0              Invalid Keep IE Len 0

Num Status Enq. Sent 550              Num Status msgs Rcvd 552

Num Update Status Rcvd 0              Num Status Timeouts 0

Spicey#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms

Spicey#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnets

C       3.1.3.0 is directly connected, Serial0

124.0.0.0/24 is subnetted, 1 subnets

C       124.124.124.0 is directly connected, Ethernet0

R    123.0.0.0/8 [120/1] via 3.1.3.2, 00:00:08, Serial0

Prasit

Prasit#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,

broadcast,, status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 87            output pkts 83           in bytes 8408

out bytes 8144           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 38         out bcast bytes 3464

pvc create time 01:34:29, last time pvc status changed 01:28:05

Prasit#show frame-relay lmi

LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = CISCO

Invalid Unnumbered info 0             Invalid Prot Disc 0

Invalid dummy Call Ref 0              Invalid Msg Type 0

Invalid Status Message 0              Invalid Lock Shift 0

Invalid Information ID 0              Invalid Report IE Len 0

Invalid Report Request 0              Invalid Keep IE Len 0

Num Status Enq. Sent 569              Num Status msgs Rcvd 570

Num Update Status Rcvd 0              Num Status Timeouts 0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Prasit#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnets

C       3.1.3.0 is directly connected, Serial1

R    124.0.0.0/8 [120/1] via 3.1.3.1, 00:00:19, Serial1

123.0.0.0/24 is subnetted, 1 subnets

C       123.123.123.0 is directly connected, Ethernet0

Configuración de retransmisión de tramas de eje de conexión y radio

En este ejemplo, el router detecta qué identificadores de conexión de link de datos (DLCI) utiliza del switch Frame Relay y los asigna a la interfaz principal. A continuación, el router invertirá ARP para la dirección IP remota.

Nota: No podrá hacer ping a la dirección IP serial de Prasit desde Aton a menos que agregue explícitamente mapas de Frame Relay en cada extremo. Si el ruteo se configura correctamente, el tráfico que se origina en las LAN no debería tener un problema. Podrá hacer ping si utiliza la dirección IP Ethernet como dirección de origen en un ping extendido.

Cuando frame-relay inverse-arp está habilitado, el tráfico IP de broadcast se apagará por la conexión de forma predeterminada.

Diagrama de la red

Configuraciones

- Spicey

- Prasit

- Aton

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 <nombre del dispositivo>

Spicey

spicey#show frame-relay map

Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,

broadcast,, status defined, active

Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,

broadcast,, status defined, active

spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          2            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 32            output pkts 40           in bytes 3370

out bytes 3928           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 30         out bcast bytes 2888

pvc create time 00:15:46, last time pvc status changed 00:10:42

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

input pkts 282           output pkts 291          in bytes 25070

out bytes 27876          dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 223        out bcast bytes 20884

pvc create time 02:28:36, last time pvc status changed 02:25:14

spicey#

spicey#ping 3.1.3.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

spicey#ping 3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

Prasit

prasit#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,

broadcast,, status defined, active

prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 311           output pkts 233          in bytes 28562

out bytes 22648          dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 162        out bcast bytes 15748

pvc create time 02:31:39, last time pvc status changed 02:25:14

prasit#ping 3.1.3.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

prasit#ping 3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Aton

aton#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,

broadcast,, status defined, active

aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 35            output pkts 32           in bytes 3758

out bytes 3366           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 27         out bcast bytes 2846

pvc create time 00:10:53, last time pvc status changed 00:10:53

aton#ping 3.1.3.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

aton#ping 3.1.3.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Conexión de radio a radio

No puede hacer ping de un spoke a otro spoke en una configuración de hub y spoke usando interfaces multipunto porque no hay mapeo para las direcciones IP de los otros spokes. Sólo la dirección del hub se detecta a través del protocolo de resolución de direcciones inversas (IARP). Si configura un mapa estático utilizando el comando frame-relay map para la dirección IP de un radio remoto para utilizar el identificador de conexión de link de datos local (DLCI), puede hacer ping a las direcciones de otros radios.

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 <nombre del dispositivo>

- show running-config

Prasit

prasit#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,

broadcast,, status defined, active

Serial1 (up): ip 3.1.3.3 dlci 150(0x96,0x2460), static,

CISCO, status defined, active

prasit#ping 3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/80 ms

prasit#ping 122.122.122.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/76 ms

Aton

aton#show running-config

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

no ip directed-broadcast

encapsulation frame-relay

frame-relay map ip 3.1.3.2 160

frame-relay interface-dlci 160

aton#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,

broadcast,, status defined, active

Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,

CISCO, status defined, active

aton#ping 3.1.3.2

Type escape sequence to abort

Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

aton#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/80 ms

Configuración de subinterfaces para Frame Relay

Las subinterfaces Frame Relay proporcionan un mecanismo para soportar redes Frame Relay parcialmente malladas. La mayoría de los protocolos asumen transitividad en una red lógica; es decir, si la estación A puede hablar con la estación B y la estación B puede hablar con la estación C, la estación A debe poder hablar directamente con la estación C. La transitividad es cierta en las LAN, pero no en las redes Frame Relay a menos que A esté conectado directamente a C.

Además, ciertos protocolos, como AppleTalk y el bridging transparente, no se pueden soportar en redes de malla parcial porque requieren "horizonte dividido" en el que un paquete recibido en una interfaz no se puede transmitir desde la misma interfaz incluso si el paquete se recibe y se transmite en diferentes circuitos virtuales.

La configuración de subinterfaces Frame Relay garantiza que una sola interfaz física se trate como interfaces virtuales múltiples. Esta capacidad nos permite superar las reglas de horizonte dividido. Los paquetes recibidos en una interfaz virtual ahora se pueden reenviar a otra interfaz virtual, incluso si están configurados en la misma interfaz física.

Las subinterfaces abordan las limitaciones de las redes Frame Relay proporcionando una manera de subdividir una red Frame Relay parcialmente mallada en una serie de subredes más pequeñas, de malla completa (o punto a punto). A cada subred se le asigna su propio número de red y aparece en los protocolos como si se pudiera alcanzar a través de una interfaz independiente. (Tenga en cuenta que las subinterfaces punto a punto pueden no estar numeradas para su uso con IP, lo que reduce la carga de direccionamiento que podría resultar de otra manera).

Subinterfaces punto a punto

Diagrama de la red

Configuraciones

- Spicey

- Prasit

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 hub y spoke muestra dos subinterfaces punto a punto y utiliza resolución de direcciones dinámica en un sitio remoto. Cada subinterfaz se proporciona con una dirección de protocolo individual y una máscara de subred, y el comando interface-dlci asocia la subinterfaz con un identificador de conexión de link de datos (DLCI) especificado. Las direcciones de destinos remotos para cada subinterfaz punto a punto no se resuelven porque son punto a punto y el tráfico se debe enviar al par en el otro extremo. El extremo remoto (Aton) utiliza ARP inverso para su asignación y el hub principal responde en consecuencia con la dirección IP de la subinterfaz. Esto ocurre porque el ARP inverso de Frame Relay está activado de forma predeterminada para las interfaces multipunto.

Diagrama de la red

Configuraciones

- Spicey

- Prasit

- Aton

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 Frame Relay Inverse ARP para solicitar la dirección del protocolo de salto siguiente para una conexión específica, dado un identificador de conexión de link de datos (DLCI). Las respuestas a las solicitudes de ARP inverso se ingresan en una tabla de mapping de dirección a DLCI en el router o el servidor de acceso; a continuación, la tabla se utiliza para suministrar la dirección del protocolo de salto siguiente o el DLCI para el tráfico saliente.

Dado que la interfaz física ahora está configurada como subinterfaces múltiples, debe proporcionar 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 habilita de forma predeterminada para todos los protocolos que soporta, pero se puede inhabilitar para los pares específicos DLCI del protocolo. Como resultado, puede utilizar mapping dinámico para algunos protocolos y mapping estático para otros protocolos en el mismo DLCI. Puede inhabilitar explícitamente el ARP inverso para un par DLCI-protocolo si sabe que el protocolo no es soportado en el otro extremo de la conexión. Dado que Inverse ARP está habilitado de forma predeterminada para todos los protocolos que soporta, no se requiere ningún comando adicional para configurar la asignación de direcciones dinámicas en una subinterfaz. Un mapa estático enlaza una dirección de protocolo de salto siguiente especificada a un DLCI especificado. El mapping estático remueve la necesidad de solicitudes de ARP Inverso; cuando suministra un mapa estático, el ARP inverso se inhabilita automáticamente para el protocolo especificado en la DLCI especificada. Debe utilizar la asignación estática si el router del otro extremo no soporta ARP Inverso en absoluto o no soporta ARP Inverso para un protocolo específico que se desee utilizar sobre Frame Relay.

Diagrama de la red

Ya hemos visto cómo configurar un router Cisco para hacer ARP inverso. El siguiente ejemplo muestra cómo configurar mapas estáticos en caso de que los necesite para interfaces multipunto o subinterfaces:

Configuraciones

- Aton

- Spicey

- Prasit

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, vea Comandos Frame Relay.

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

Si no tiene el espacio de dirección IP para utilizar muchas subinterfaces, puede utilizar IP sin numerar en cada subinterfaz. Si este es el caso, debe utilizar rutas estáticas o ruteo dinámico para que el tráfico se rutee de la forma habitual y debe utilizar subinterfaces punto a punto.

Diagrama de la red

El siguiente ejemplo ilustra lo siguiente:

Configuraciones

- Spicey

- Prasit

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 seguridad de los circuitos de Frame Relay mediante ISDN. Hay varias maneras de hacerlo. La primera, y probablemente la mejor, es utilizar rutas estáticas flotantes que enruten el tráfico a una dirección IP de Interfaz de velocidad básica (BRI) y utilizar una métrica de routing adecuada. También puede utilizar una interfaz de copia de seguridad en la interfaz principal o en una base de identificador de conexión por enlace de datos (DLCI). Puede que no sea de gran ayuda realizar una copia de seguridad de la interfaz principal porque podría perder los circuitos virtuales permanentes (PVC) sin que la interfaz principal se desactivara. Recuerde que el protocolo se está intercambiando con el switch de Frame Relay local, no con el router remoto.

Configuraciones

- Router 1

- Router 2

Router 1

ROUTER1#

!

hostname ROUTER1

!

username ROUTER2 password same

isdn switch-type basic-dms100

!

interface Ethernet 0

ip address 172.16.15.1 255.255.255.248

!

interface serial 0

ip address 172.16.24.129 255.255.255.128

encapsulation FRAME-RELAY

!

interface BRI0

description Backup ISDN for frame-relay

ip address 172.16.12.1 255.255.255.128

encapsulation PPP

dialer idle-timeout 240

dialer wait-for-carrier-time 60

dialer map IP 172.16.12.2 name ROUTER2 broadcast 7086639706

ppp authentication chap

dialer-group 1

isdn spid1 0127280320 2728032

isdn spid2 0127295120 2729512

!

router igrp 1

network 172.16.0.0

!

ip route 172.16.15.16 255.255.255.248 172.16.12.2 150

!--- Floating static route.

!

access-list 101 deny   igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

dialer-list 1 LIST 101

!

Router 2

ROUTER2#

!

hostname ROUTER2

!

username ROUTER1 password same

isdn switch-type basic-dms100

!

interface Ethernet 0

ip address 172.16.15.17 255.255.255.248

!

interface Serial 0

ip address 172.16.24.130 255.255.255.128

encapsulation FRAME-RELAY

!

interface BRI0

description ISDN backup interface for frame-relay

ip address 172.16.12.2 255.255.255.128

encapsulation PPP

dialer idle-timeout 240

dialer map IP 172.16.12.1 name ROUTER1 broadcast

ppp authentication chap

pulse-time 1

dialer-group 1

isdn spid1 0191933333 4445555

isdn spid2 0191933334 4445556

!

router igrp 1

network 172.16.0.0

!

ip route 172.16.15.0 255.255.255.248 172.16.12.1 150

!--- Floating static route.

!

access-list 101 deny   igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 162.27.9.0 0.0.0.255

dialer-list 1 LIST 101

!

Comandos show

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

- debug isdn q931

- debug ppp neg

- debug ppp auth

Intente realizar una llamada ISDN desde el lado que llama al lado central sin los comandos de respaldo. Si esto es exitoso, agregue los comandos de respaldo al lado que llama.

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

Configuración por copia de seguridad de DCLI

Ahora supongamos que Spicey es el lado central y que Prasit es el lado que hace conexiones con el lado central (Spicey). Tenga cuidado de agregar solamente los comandos de respaldo al lado que llama al lado central.

Nota: La carga de respaldo no se soporta en las subinterfaces. Como no hacemos un seguimiento de los niveles de tráfico en las subinterfaces, no se calcula ninguna carga.

Diagrama de la red

Configuraciones

- Spicey

- Prasit

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

- mostrar estado isdn

- 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 serial se cae.

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 serial vuelve a estar.

Prasit#show isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface    ISDN Switchtype = basic-net3

Layer 1 Status:

DEACTIVATED

Layer 2 Status:

Layer 2 NOT Activated

Layer 3 Status:

0 Active Layer    3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask:  0x80000003

Total Allocated ISDN CCBs = 0

Prasit#show interface bri 0

BRI0 is standby mode, line protocol is down

Hardware is BRI

Internet address is 3.1.6.2/24

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Last input 00:01:00, output 00:01:00, output hang never

Last clearing of "show interface" counters 01:28:16

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations  0/1/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

128 packets input, 601 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

132 packets output, 687 bytes, 0 underruns

0 output errors, 0 collisions, 10 interface resets

0 output buffer failures, 0 output buffers swapped out

14 carrier transitions

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Red radial con perfiles de marcador

Este es un ejemplo de una configuración de respaldo de hub y spoke por DLCI. Los routers radiales llaman al router hub. Como puede ver, permitimos solamente un canal B por lado usando la opción max-link en el conjunto de marcadores en el lado del hub.

Nota: La carga de respaldo no se soporta en las subinterfaces. Como no hacemos un seguimiento de los niveles de tráfico en las subinterfaces, no se calcula ninguna carga.

Diagrama de la red

Configuraciones

- Aton

- Spicey

- Prasit

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Aton

!

!

username Spicey password 0 cisco

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

ip address 3.1.3.3 255.255.255.0

backup delay 5 10

backup interface BRI0

frame-relay interface-dlci 160

!

interface BRI0

ip address 155.155.155.3 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer map ip 155.155.155.2 name Spicey broadcast 6106

dialer-group 1

isdn switch-type basic-net3

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 122.0.0.0

network 155.155.0.0

!

ip route 124.124.124.0 255.255.255.0 155.155.155.2 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Spicey

Spicey#show running-config

Building configuration...

Current configuration : 1887 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

username Prasit password 0 cisco

username Aton password 0 cisco

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip address 4.0.1.1 255.255.255.0

frame-relay interface-dlci 140

!

interface Serial0.2 point-to-point

ip address 3.1.3.1 255.255.255.0

frame-relay interface-dlci 130

!

interface BRI0

no ip address

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool-member 2 max-link 1

dialer pool-member 1 max-link 1

isdn switch-type basic-net3

no peer default ip address

no cdp enable

ppp authentication chap

!

interface Dialer1

ip address 160.160.160.1 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool 1

dialer remote-name Prasit

dialer-group 1

ppp authentication chap

!

interface Dialer2

ip address 155.155.155.2 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool 2

dialer remote-name Aton

dialer-group 1

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 4.0.0.0

network 124.0.0.0

network 155.155.0.0

network 160.160.0.0

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1267 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

username Spicey password 0 cisco

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

backup delay 5 10

backup interface BRI0

ip address 4.0.1.2 255.255.255.0

frame-relay interface-dlci 150

!

interface BRI0

ip address 160.160.160.2 255.255.255.0

encapsulation ppp

dialer map ip 160.160.160.1 name Spicey broadcast 6106

dialer-group 1

isdn switch-type basic-net3

ppp authentication chap

!

router igrp 2

network 4.0.0.0

network 123.0.0.0

network 160.160.0.0

!

ip route 124.124.124.0 255.255.255.0 160.160.160.1 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Comandos show

- show frame-relay map

- show ip route

- show frame map

- show frame-relay pvc

Aton

Aton#show frame-relay map

Serial1.1 (up): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast

status defined, active

Aton#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Aton#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR, P - periodic downloaded static route

T - traffic engineered route

Gateway of last resort is not set

I    155.155.0.0/16 [100/182571] via 3.1.3.1, Serial1.1

3.0.0.0/24 is subnetted, 1 subnets

C    3.1.3.0 is directly connected, Serial1.1

I    4.0.0.0/8 [100/10476] via 3.1.3.1, Serial1.1

I    160.160.0.0/16 [100/182571] via 3.1.3.1, Serial1.1

124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

S    124.124.124.0/24 [250/0] via 155.155.155.2

I    124.0.0.0/8 [100/8576] via 3.1.3.1, Serial1.1

I    123.0.0.0/8 [100/10576] via 3.1.3.1, Serial1.1

122.0.0.0/24 is subnetted, 1 subnets

C    122.122.122.0 is directly connected, Ethernet0

Aton#

El Serial 1 se está reduciendo.

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 vuelve a activar

Aton#

01:24:02: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected from 6106

Spicey, call lasted 149 seconds

01:24:02: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

01:24:03: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,

changed state to down

Aton#show frame map

Serial1.1 (down): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast

status deleted

Aton#

01:26:35: %LINK-3-UPDOWN: Interface Serial1, changed state to up

01:26:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,

changed state to up

01:26:56: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0, TEI 64 changed

to down

01:26:56: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI 64 changed

to down

01:26:56: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode

01:26:56: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

01:26:56: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

Aton#show frame map

Serial1.1 (up): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast

status defined, active

Aton#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Aton#ping 124.124.124.1

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          1               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

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

Serial1.1

input pkts 60               output pkts 69           in    bytes 9694

out bytes 10811             dropped pkts 0           in    FECN pkts 0

in BECN pkts 0              out FECN pkts 0          out BECN pkts 0

in DE pkts 0                out DE pkts 0

out bcast pkts 44         out    bcast bytes 7565

pvc create time 01:28:35, last time pvc status changed 00:02:19

Spicey

Spicey#show frame-relay map

Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, active

Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast

status defined, active

Spicey#ping 122.122.122.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

Spicey#ping 123.123.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Spicey#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS    level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static    route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

155.155.0.0/24 is subnetted, 1 subnets

C    155.155.155.0 is directly connected, Dialer2

3.0.0.0/24 is subnetted, 1 subnets

C    3.1.3.0 is directly connected, Serial0.2

4.0.0.0/24 is subnetted, 1 subnets

C    4.0.1.0 is directly connected, Serial0.1

160.160.0.0/24 is subnetted, 1 subnets

C    160.160.160.0 is directly connected, Dialer1

124.0.0.0/24 is subnetted, 1 subnets

C    124.124.124.0 is directly connected, Ethernet0

I    123.0.0.0/8 [100/8576] via 4.0.1.2, 00:00:55, Serial0.1

I    122.0.0.0/8 [100/8576] via 3.1.3.3, 00:00:35, Serial0.2

Ambas líneas seriales de los lados que llaman están cayendo.

Spicey#

*Mar  1 01:21:30.171: %LINK-3-UPDOWN: Interface BRI0:1, changed state toup

*Mar  1 01:21:30.627: %DIALER-6-BIND: Interface BR0:1 bound to profile Di2

*Mar  1 01:21:31.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to up

*Mar  1 01:21:36.191: %ISDN-6-CONNECT: Interface BRI0:1 is now connected

to 6104 Aton

*Mar  1 01:21:40.923: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up

*Mar  1 01:21:41.359: %DIALER-6-BIND: Interface BR0:2 bound to profile Di1

*Mar  1 01:21:42.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:2, changed state to up

*Mar  1 01:21:46.943: %ISDN-6-CONNECT: Interface BRI0:2 is now connected

to 6105 Prasit

*Mar  1 01:23:59.819: %DIALER-6-UNBIND: Interface BR0:1 unbound from

profile Di2

*Mar  1 01:23:59.831: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected

from 6104 Aton, call lasted 149 seconds

*Mar  1 01:23:59.927: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar  1 01:24:00.923: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to down

*Mar  1 01:24:03.015: %DIALER-6-UNBIND: Interface BR0:2 unbound from

profile Di1

*Mar  1 01:24:03.023: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected

from 6105 Prasit, call lasted 142 seconds

*Mar  1 01:24:03.107: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

*Mar  1 01:24:04.107: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:2, changed state to down

Spicey#show frame map

Serial0.1 (down): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, inactive

Serial0.2 (down): point-to-point dlci, dlci 130(0x82,0x2020), broadcast

status defined, inactive

Spicey#

Ambas líneas seriales están disponibles de nuevo.

Spicey#show frame pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          2               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

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

Serial0.2

input pkts 54               output pkts 61           in    bytes 7014

out bytes 9975              dropped pkts 3           in    FECN pkts 0

in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0

in DE pkts 0                out DE pkts 0

out bcast pkts 40         out    bcast bytes 7803

pvc create time 01:28:14, last time pvc status changed 00:02:38

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

Serial0.1

input pkts 56               output pkts 60           in    bytes 7604

out bytes 10114             dropped pkts 2           in    FECN pkts 0

in BECN pkts 0              out FECN pkts 0          out BECN    pkts 0

in DE pkts 0                out DE pkts 0

out bcast pkts 39           out    bcast bytes 7928

pvc create time 01:28:15, last time pvc status changed 00:02:29

Prasit

Prasit#show frame-relay map

Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast

status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms

Prasit#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS    level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static    route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

I    155.155.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1

I    3.0.0.0/8 [100/10476] via 4.0.1.1, 00:00:41, Serial1.1

4.0.0.0/24 is subnetted, 1 subnets

C    4.0.1.0 is directly connected, Serial1.1

I    160.160.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1

124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

S    124.124.124.0/24 [250/0] via 160.160.160.1

I    124.0.0.0/8 [100/8576] via 4.0.1.1, 00:00:41, Serial1.1

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

I    122.0.0.0/8 [100/10576] via 4.0.1.1, 00:00:42, Serial1.1

Prasit#

El Serial 1 se desactiva.

Prasit#

*Mar  1 01:16:08.287: %LINK-3-UPDOWN: Interface Serial1, changed state to down

*Mar  1 01:16:09.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface

Serial1, changed state to down

*Mar  1 01:16:11.803: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

*Mar  1 01:16:11.819: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

*Mar  1 01:16:11.855: %LINK-3-UPDOWN: Interface BRI0, changed state to up

*Mar  1 01:16:15.967: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI

64 changed to up

Prasit#show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF,    IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF    NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external    type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS    level-2, ia - IS-IS

inter area

* - candidate default, U - per-user static    route, o - ODR

P - periodic downloaded static route

Gateway of last resort is not set

160.160.0.0/24 is subnetted, 1 subnets

C    160.160.160.0 is directly connected, BRI0

124.0.0.0/24 is subnetted, 1 subnets

S    124.124.124.0 [250/0] via 160.160.160.1

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

*Mar  1 01:21:38.967: %LINK-3-UPDOWN: Interface BRI0:1, changed state to

up.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms

Prasit#

*Mar  1 01:21:40.063: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to up

*Mar  1 01:21:44.991: %ISDN-6-CONNECT: Interface BRI0:1 is now connected

to 6106 Spicey

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

Prasit#

El Serial 1 se vuelve a activar.

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 conmutación de paquetes basada en el identificador de conexión de link de datos (DLCI). Podemos considerar esto como el equivalente de Frame Relay de una dirección de control de acceso a medios (MAC). Para realizar la conmutación, configure el router de Cisco o el servidor de acceso en una red Frame Relay. Hay dos partes en una red Frame Relay:

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

- Switch de equipo de terminación de circuitos de datos (DCE) de Frame Relay.

Nota: En Cisco IOS Software Release 12.1(2)T y posteriores, el comando frame route ha sido reemplazado por el comando connect.

Veamos una configuración de ejemplo. En la siguiente configuración, estamos utilizando el router América como un switch Frame Relay. Utilizamos Spicey como router hub y Prasit y Aton como routers radiales. Los hemos conectado de la siguiente manera:

- El DTE serial 1 (s1) de Prasit está conectado al DCE serial 1/4 (s1/4) de América.

- El DTE de serie Spicey 0 (s0) está conectado al DCE serial 1/5 (s1/5) de América.

- Un DTE serial 1 (s1) está conectado a América serial 3/4 (s3/4) DCE.

Diagrama de la red

Este documento se basa en la siguiente configuración:

Configuraciones

- Spicey

- Prasit

- Aton

- América

Spicey

Spicey#show running-config

Building configuration...

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 3.1.3.1 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 130

frame-relay interface-dlci 140

!

!

router rip

network 3.0.0.0

network 124.0.0.0

!

line con 0

!

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1499 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 150

!

!

router rip

network 3.0.0.0

network 123.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Aton

!

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 160

!

router rip

network 3.0.0.0

network 122.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

América

america#show running-config

Building configuration...

Current configuration:

!

!

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname america

!

frame-relay switching

!

!

interface Serial1/4

description *** static DCE connection to s1 Prasit

no ip address

encapsulation frame-relay

clockrate 2000000

frame-relay intf-type dce

frame-relay route 150 interface Serial1/5 140

!

interface Serial1/5

description *** static DCE connection to s0 spicy

no ip address

encapsulation frame-relay

bandwidth 1000000

tx-queue-limit 100

frame-relay intf-type dce

frame-relay route 130 interface Serial3/4 160

frame-relay route 140 interface Serial1/4 150

transmitter-delay 10

!

interface Serial3/4

description *** static DCE connection to s1 Aton

encapsulation frame-relay

no ip mroute-cache

clockrate 2000000

frame-relay intf-type dce

frame-relay route 160 interface Serial1/5 130

!

Comandos show

Utilice los siguientes comandos show para probar que su red funciona correctamente:

- show frame-relay map

- show frame-relay pvc

El resultado que se muestra a continuación surge de ingresar estos comandos en los dispositivos que estamos utilizando en esta configuración de muestra.

Spicey

Spicey#show frame-relay map

Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,

broadcast,, status defined, active

Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,

broadcast,, status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted            Static

Local          2                 0            0                 0

Switched       0                 0            0                 0

Unused         0                 0            0                 0

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

input pkts 32                 output pkts 40                in bytes 3370

out bytes 3928                dropped pkts 0                in FECN pkts 0

in BECN pkts 0                out FECN pkts 0               out BECN pkts 0

in DE pkts 0                  out DE pkts 0

out bcast pkts 30             out bcast bytes 2888

pvc create time 00:15:46, last time pvc status changed 00:10:42

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

input pkts 282                output pkts 291          in bytes 25070

out bytes 27876               dropped pkts 0           in FECN pkts 0

in BECN pkts 0                out FECN pkts 0          out BECN pkts 0

in DE pkts 0                  out DE pkts 0

out bcast pkts 223            out bcast bytes 20884

pvc create time 02:28:36, last time pvc status changed 02:25:14

Prasit

Prasit#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,

broadcast,, status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted            Static

Local          1                 0            0                 0

Switched       0                 0            0                 0

Unused         0                 0            0

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

input pkts 311                output pkts 233          in bytes 28562

out bytes 22648               dropped pkts 0           in FECN pkts 0

in BECN pkts 0                out FECN pkts 0          out BECN pkts 0

in DE pkts 0                  out DE pkts 0

out bcast pkts 162            out bcast bytes 15748

pvc create time 02:31:39, last time pvc status changed 02:25:14

Aton

Aton#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic, broadcast, status defined, active

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted            Static

Local          1                 0            0                 0

Switched       0                 0            0                 0

Unused         0                 0            0                 0

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

input pkts 35                 output pkts 32                in bytes 3758

out bytes 3366                dropped pkts 0                in FECN pkt 0

in BECN pkts 0                out FECN pkts 0               out BECN pkts 0

in DE pkts 0                  out DE pkts 0

out bcast pkts 27 out bcast bytes 2846

pvc create time 00:10:53, last time pvc status changed 00:10:53

Configuración de priorización DLCI de Frame Relay

La priorización del identificador de conexión de enlace de datos (DLCI) es el proceso mediante el cual se colocan diferentes tipos de tráfico en DLCI separados para que una red Frame Relay pueda proporcionar una velocidad de información comprometida diferente para cada tipo de tráfico. Se puede utilizar junto con la colocación en cola personalizada o la colocación en cola prioritaria para proporcionar control de administración del ancho de banda sobre el link de acceso a la red Frame Relay. Además, algunos proveedores de servicios de Frame Relay y switches de Frame Relay (como los switches Stratacom Internetwork Packet Exchange [IPX], IGX y BPX o AXIS) realmente proporcionan prioridad dentro de la nube de Frame Relay en función de esta configuración de prioridad.

Consideraciones de Implementación

Al implementar la priorización de DLCI, tenga en cuenta los siguientes puntos:

- Si se desactiva un DLCI secundario, se pierde el tráfico destinado a esa cola solamente.

- Si pierde el DLCI primario, la subinterfaz se desactiva y se pierde todo el tráfico.

Diagrama de la red

Para utilizar esta configuración, necesita tener cuatro DLCI para el lado que utilizará la priorización DLCI. En este ejemplo, hemos configurado Spicey para la colocación en cola de prioridad de la siguiente manera:

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

- Telnet está en la cola de prioridad media.

- El protocolo de transferencia de archivos (FTP) se encuentra en la cola de prioridad normal.

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

Nota: Asegúrese de configurar los DLCI para que correspondan con la lista de prioridades, o bien el sistema no utilizará la cola correcta.

Configuraciones

- Spicey

- Prasit

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 funciona correctamente. Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.

- show frame-relay pvc

- show frame-relay map

- show queueing priority

- debug priority

El resultado que se muestra a continuación surge de ingresar estos comandos en los dispositivos que estamos utilizando en esta configuración de muestra.

Spicey

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          4            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 106           output pkts 15           in bytes 6801

out bytes 1560           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 0         out bcast bytes 0

pvc create time 00:29:22, last time pvc status changed 00:20:37

Priority DLCI Group 1, DLCI 140 (HIGH), DLCI 180 (MEDIUM)

DLCI 190 (NORMAL), DLCI 200 (LOW)

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

input pkts 0             output pkts 51           in bytes 0

out bytes 2434           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 0         out bcast bytes 0

pvc create time 00:29:23, last time pvc status changed 00:14:48

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

input pkts 0             output pkts 13           in bytes 0

out bytes 3653           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 13        out bcast bytes 3653

pvc create time 00:29:23, last time pvc status changed 00:14:28

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

input pkts 0             output pkts 42           in bytes 0

out bytes 2554           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 10        out bcast bytes 500

pvc create time 00:29:24, last time pvc status changed 00:14:09

Spicey#show frame-relay map

Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast

status defined, active

Priority DLCI Group 1, DLCI 140 (HIGH), DLCI 180 (MEDIUM)

DLCI 190 (NORMAL), DLCI 200 (LOW)

Spicey#show queueing priority

Current priority queue configuration:

List   Queue  Args

1      high   protocol ip          list 102

1      medium protocol ip          tcp port telnet

1      normal protocol ip          tcp port ftp

1      low    protocol ip

Para verificar 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:

Otro tráfico IP pasa por la cola baja.

Spicey#

*Mar  1 00:53:57.079: PQ: Serial0 output (Pk size/Q 13/0)

*Mar  1 00:53:58.851: PQ: Serial0: ip -> low

*Mar  1 00:53:58.907: PQ: Serial0: ip -> low

*Mar  1 00:53:58.907: PQ: Serial0 output (Pk size/Q 36/3)

*Mar  1 00:53:59.459: PQ: Serial0: ip -> low

*Mar  1 00:53:59.463: PQ: Serial0: ip -> low

*Mar  1 00:53:59.463: PQ: Serial0 output (Pk size/Q 50/3)

Spicey#

Prasit

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 134           output pkts 119          in bytes 12029

out bytes 7801           dropped pkts 0           in FECN pkts 0

in BECN pkts 0           out FECN pkts 0          out BECN pkts 0

in DE pkts 0             out DE pkts 0

out bcast pkts 18         out bcast bytes 1260

pvc create time 00:21:15, last time pvc status changed 00:21:15

Prasit#show frame-relay map

Serial1 (up): ip 4.0.1.1 dlci 150(0x96,0x2460), dynamic,

broadcast, status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48

Here is the debug output shown on Spicey when you use the command above to ping to Spicey from Prasit.

Spicey#

*Mar  1 00:33:26.755: PQ: Serial0 output (Pk size/Q 13/0)

*Mar  1 00:33:28.535: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.539: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.543: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:33:28.583: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.587: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.587: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:33:28.631: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.635: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.635: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:33:28.679: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.683: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.683: PQ: Serial0 output (Pk size/Q 104/0)

*Mar  1 00:33:28.723: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.727: PQ: Serial0: ip (s=124.124.124.1, d=4.0.1.2) ->high

*Mar  1 00:33:28.731: PQ: Serial0 output (Pk size/Q 104/0)

Prasit#telnet 124.124.124.1

Trying 124.124.124.1 ... Open

User Access Verification

Password:

Spicey>exit

[Connection to 124.124.124.1 closed by foreign host]

Prasit#

Este es el resultado de debug que se muestra en Spicey cuando se utiliza el comando anterior 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 función principal que se utiliza en redes IP o IPX de tamaño mediano o grande, donde las transmisiones de punto de acceso de servicio (SAP) y de routing deben fluir a través de la red Frame Relay. La cola de broadcast se administra independientemente de la cola de interfaz normal, tiene sus propios búferes y tiene un tamaño configurable y una velocidad de servicio. Esta cola de difusión no se utiliza para las actualizaciones de árbol de extensión (BPDU) en puente debido a las sensibilidades de la sincronización. Estos paquetes fluirán a través de las colas normales. El comando interface para habilitar la cola de broadcast es el siguiente:

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

A una cola de difusión se le asigna un límite máximo de velocidad de transmisión (rendimiento) medido en bytes por segundo y paquetes por segundo. La cola se mantiene para asegurarse de que sólo se proporcione este máximo. La cola de difusión tiene prioridad al transmitir a una velocidad inferior al máximo configurado y, por lo tanto, tiene una asignación mínima de ancho de banda garantizada. Los dos límites de velocidad de transmisión están destinados a evitar saturar la interfaz con broadcasts. El límite real en cualquier segundo es el primer límite de tasa que se alcanza. Dada la restricción de la velocidad de transmisión, se requiere almacenamiento en búfer adicional para almacenar los paquetes de broadcast. La cola de difusión se puede configurar para almacenar grandes cantidades de paquetes de difusión. El tamaño de la cola debe configurarse para evitar la pérdida de paquetes de actualización de ruteo de difusión. El tamaño exacto depende del protocolo que se utilice y del número de paquetes necesarios para cada actualización. Para que sea seguro, el tamaño de la cola debe configurarse de modo que se pueda almacenar una actualización de routing completa de cada protocolo y de 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), donde N es la cantidad de identificadores DLCI en los que debe replicarse la difusión

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

La velocidad del paquete no es crítica si la velocidad de bytes se establece de forma conservadora. En general, la velocidad del paquete se debe establecer suponiendo paquetes de 250 bytes. Los valores predeterminados para las interfaces seriales son 64 tamaño de cola, 256 000 bytes por segundo (2 048 000 bps) y 36 pps. Los valores predeterminados para las interfaces seriales de alta velocidad (HSSI) son 256 tamaños de cola, 1 024 000 bytes por segundo (8 192 000 bps) y 144 pps.

Modelado de tráfico

El modelado del tráfico utiliza un mecanismo de control de velocidad denominado filtro de cubeta con ficha. Este filtro de cubeta con ficha se establece 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 búfer en una cola de modelado de tráfico que es igual al tamaño de la cola equilibrada ponderada (WFQ). El filtro Token Bucket no filtra el tráfico, sino que controla la velocidad a la que se envía el tráfico en la interfaz saliente. Para obtener más información sobre los filtros de cubeta con ficha, consulte Descripción general de regulación y modelado.

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

Parámetros de modelado de tráfico

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

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

- EIR = tasa de información excesiva

- TB = token bucket (= Bc + Be)

- Bc = tamaño de ráfaga comprometida (= tamaño de ráfaga sostenida)

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

- DE = criterios de selección de descarte

- Tc = intervalo de medición

- AR = velocidad de acceso correspondiente a la velocidad de la interfaz física (de modo que si utiliza un T1, el AR es aproximadamente de 1,5 Mbps).

Veamos algunos de estos parámetros con más detalle:

Velocidad de acceso (AR)

El número máximo de bits por segundo que una estación final puede transmitir a la red está limitado por la velocidad de acceso de la interfaz de red de usuario. La velocidad de línea de la conexión de red del usuario limita la velocidad de acceso. Puede establecer esto en su suscripción al proveedor de servicios.

Tamaño De Ráfaga Comprometida (Bc)

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

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

El número de bits no comprometidos (fuera de CIR) que el switch de Frame Relay aún acepta pero que están marcados como aptos para ser descartados (DE).

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

Committed Information Rate (CIR)

El CIR es la cantidad permitida de datos que la red se compromete a transferir en condiciones normales. La tasa se promedia a lo largo de un incremento de tiempo Tc. El CIR también se denomina rendimiento mínimo aceptable. 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 el identificador de conexión de link de datos (DLCI). Debido a esto, el filtro de cubeta con ficha controla la velocidad por DLCI. La velocidad de acceso es válida por interfaz de red de usuario. Para Bc, se pueden distinguir los valores entrantes y salientes de Be y CIR. Si la conexión es simétrica, los valores en ambas direcciones son los mismos. Para los circuitos virtuales permanentes, definimos Bc, Be y CIR entrantes y salientes en el momento de la suscripción.

- Pico = velocidad máxima de DLCI. El ancho de banda para ese DLCI particular.

- Tc = Bc / CIR

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

Si el Tc es un segundo, entonces:

- Pico = CIR + Be = Bc + Be

- EIR = Be

En el ejemplo que estamos utilizando aquí, el router envía tráfico entre 48 Kbps y 32 Kbps dependiendo de la congestión en la red. Las redes pueden marcar tramas por encima de Bc con DE pero tienen mucha capacidad de repuesto para transportar la trama. Lo contrario también es posible: pueden tener una capacidad limitada, pero descartan las tramas excesivas inmediatamente. Las redes pueden marcar las tramas por encima de Bc + Be with DE, y posiblemente transportarlas, o simplemente descartar las tramas como sugiere la especificación ITU-T I.370 del Sector de Normalización de Telecomunicaciones de la Unión Internacional de Telecomunicaciones. El modelado del tráfico regula el tráfico basándose en los paquetes etiquetados de notificación de congestión explícita (BECN) de la red del switch. Si recibe un 50% de BECN, el router reduce el tráfico en un octavo del ancho de banda transmitido actual para ese DLCI en particular.

Ejemplo:

La velocidad transmitida es de 42 Kb. El router reduce la velocidad a 42 menos 42 dividido por 8 (42 - 42/8), con lo que alcanza los 36,75 Kb. Si la congestión disminuye después del cambio, el router reduce el tráfico aún más, bajando a un octavo del ancho de banda transmitido actual. El tráfico se reduce hasta que alcanza el valor CIR configurado. Sin embargo, la velocidad puede caer bajo el CIR cuando todavía podemos ver BECN. Puede especificar un límite inferior, como CIR/2. La red ya no está congestionada cuando todas las tramas recibidas de la red ya no tienen un bit BECN durante un intervalo de tiempo determinado. 200 ms es el valor predeterminado para este intervalo.

Modelado del tráfico genérico

La función de modelado de tráfico genérico es una herramienta de modelado de tráfico independiente de los medios y la encapsulación que ayuda a reducir el flujo de tráfico saliente cuando hay congestión dentro de la nube, en el link o en el router del terminal receptor. Podemos configurarlo en interfaces o subinterfaces dentro de un router.

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

- Cuando tiene una topología de red que consta de 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 las sucursales o los sitios de teletrabajo. Debido a la discordancia de velocidad, a menudo existe un cuello de botella para el tráfico en las sucursales o los sitios de teletrabajadores cuando el sitio central envía los datos a una velocidad más rápida que los sitios remotos pueden recibir. Esto produce un cuello de botella en el último switch antes del router de punto remoto.

- Si es un proveedor de servicios que ofrece servicios de velocidad inferior, esta función le permite utilizar el router para dividir sus links T1 o T3, por ejemplo, en canales más pequeños. Puede configurar cada subinterfaz con una cubeta de filtro de token que coincida con el servicio solicitado por un cliente.

En la conexión Frame Relay, es posible que desee que el router regule el tráfico en lugar de enviarlo a la red. La aceleración del tráfico limitaría la pérdida de paquetes en la nube del proveedor de servicios. La capacidad de regulación basada en BECN proporcionada con esta función permite que el router controle dinámicamente el tráfico basándose en la recepción de paquetes etiquetados BECN de la red. Esta regulación contiene paquetes en los búfers del router para reducir el flujo de datos del router a la red Frame Relay. El router regula el tráfico en una base de subinterfaz, y la velocidad también aumenta cuando se reciben menos paquetes etiquetados BECN.

Comandos para modelado de tráfico genérico

Para definir el control de velocidad, utilice este comando:

traffic-shape rate bit-rate [ráfaga-tamaño [exceso-ráfaga-tamaño]] [lista de acceso de grupo]

Para limitar las BECN en una interfaz Frame Relay, utilice este comando:

traffic-shape adaptive [bit-rate]

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

Nota: Debe habilitar el modelado de tráfico en la interfaz con el comando traffic-shape rate antes de poder utilizar el comando traffic-shape adaptive.

La velocidad de bits especificada para el comando traffic-shape rate es el límite superior, y la velocidad de bits especificada para el comando traffic-shape adaptive es el límite inferior (normalmente el valor CIR) al que se modela el tráfico cuando la interfaz recibe BECN. La tasa utilizada es normalmente entre estas dos tasas. Debe configurar el comando traffic-shape adaptive en ambos extremos del link, ya que también configura el dispositivo en el extremo de flujo para reflejar las señales de notificación explícita de congestión de reenvío (FECN) como BECN. Esto permite que el router en el extremo de alta velocidad detecte y se adapte 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 la interfaz 0.1 con un límite superior (normalmente Bc + Be) de 128 kbps y un límite inferior de 64 kbps. Esto permite que el link se ejecute de 64 a 128 kbps, dependiendo del nivel de congestión. Si el lado central tiene un límite superior de 256 kbps, debe utilizar el valor límite superior más bajo.

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

La función de modelado de tráfico sobre Frame Relay proporciona las siguientes capacidades:

- Aplicación de la tasa por VC: Puede configurar una velocidad pico para limitar el tráfico saliente al CIR o a algún otro valor definido, como la velocidad de información excesiva (EIR).

- Compatibilidad generalizada con BECN por VC: El router puede monitorear las BECN y limitar el tráfico basándose en los comentarios de paquetes marcados con BECN de la red Frame Relay.

- Compatibilidad con colas de prioridad (PQ), colas personalizadas (CQ) o WFQ en el nivel de VC. Esto permite una granularidad más fina en la priorización y colocación en cola del tráfico, lo que le proporciona más control sobre el flujo de tráfico en un VC individual. La función de modelado de tráfico sobre Frame Relay se aplica a los circuitos virtuales permanentes (PVC) de Frame Relay y a los circuitos virtuales conmutados (SVC).

Ejemplo:

Interface Serial 0

no ip address

encapsulation frame-relay

frame-relay traffic-shaping

!

interface Serial0.100

ip address 1.1.1.1 255.255.255.252

frame-relay interface-dlci 100

frame-relay class fast

!

interface Serial0.200

ip address 1.1.1.5 255.255.255.252

frame-relay interface-dlci 200

frame-relay class slow

!

map-class frame-relay slow

frame-relay traffic-rate 64000 128000

!

map-class

frame-relay fast

frame-relay traffic-rate 16000 64000

!

En este ejemplo, el router agrega dos cubetas de token.

- Uno se ejecuta entre 64000 (CIR) y 128000(Bc + Be).

- El otro funciona entre 16000 (CIR) y 64000 (Bc + Be).

Si el tráfico entrante de Ethernet es mayor que el filtro de cubeta con ficha, el tráfico se almacena en el búfer en la cola de tráfico de Frame Relay.

Para ver un diagrama de flujo que muestra el flujo de paquetes cuando implementa el modelado de tráfico de Frame Relay, vea el diagrama de flujo de modelado de tráfico de Frame Relay. Para ver un diagrama de flujo específicamente usando un filtro de cubeta con ficha, vea Diagrama de flujo de modelado de tráfico de Frame Relay - Token Bucket.

Comandos de Frame Relay utilizados comúnmente

Esta sección describe dos comandos de Cisco IOS® que son especialmente útiles al configurar Frame Relay.

show frame-relay pvc

Este comando muestra el estado del circuito virtual permanente (PVC), los paquetes entrantes y salientes, los paquetes descartados si hay congestión en la línea mediante la notificación explícita de congestión de reenvío (FECN) y la notificación explícita de congestión de reenvío (BECN), etc. Para obtener 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 de su dispositivo Cisco, puede utilizar Output Interpreter (sólo clientes registrados) para mostrar posibles problemas y soluciones.

Puede utilizar Output Interpreter (sólo clientes registrados) para mostrar posibles problemas y 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:

- CONMUTADO: el router o el servidor de acceso se utiliza como switch.

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

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

El PVC puede tener cuatro estados posibles. El campo PVC STATUS muestra estos datos de la siguiente manera:

- ACTIVE - PVC está activo y funcionando normalmente.

- INACTIVO: el PVC no está activo de extremo a extremo. Esto puede deberse a que no hay asignación (o asignación incorrecta) para el DLCI local en la nube de Frame Relay o el extremo remoto del PVC se elimina.

- DELETED (ELIMINADO): la interfaz de administración local (LMI) no se intercambia entre el router y el switch local, o bien el switch no tiene DLCI configurado en el switch local.

- STATIC: no hay keepalive configurado en la interfaz frame-relay 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 las subinterfaces punto a punto. Es útil sólo 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 de Frame Relay.

Si tiene el resultado de un comando show frame-relay map de su dispositivo Cisco, puede utilizar Output Interpreter (sólo para clientes registrados) para mostrar posibles problemas y soluciones.

Puede utilizar Output Interpreter (sólo clientes registrados) para mostrar posibles problemas y soluciones.

Transmisión de tramas y conexión en puente

Los mensajes de configuración denominados unidades de datos de protocolo de puente (BPDU) se utilizan en los protocolos de árbol de extensión admitidos en los puentes y routers de Cisco. Estos fluyen a intervalos regulares entre puentes y constituyen una cantidad significativa de tráfico debido a su frecuente aparición. Hay dos tipos de protocolos de árbol de expansión en la conexión en puente transparente. Presentado por primera vez por Digital Equipment Corporation (DEC), el algoritmo fue revisado posteriormente por el comité IEEE 802 y publicado en la especificación IEEE 802.1d. El Protocolo de árbol de extensión DEC emite BPDU a intervalos de un segundo, mientras que el IEEE emite BPDU a intervalos de dos segundos. Cada paquete es de 41 bytes, que incluye un mensaje de configuración BPDU de 35 bytes, un encabezado Frame Relay de 2 bytes, un Ethertype de 2 bytes y un FCS de 2 bytes.

Retransmisión de tramas y memoria

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

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

2. Cada sentencia de mapa: 96 bytes (o mapa generado dinámicamente)

3. Cada IDB (interfaz de hardware + Frame Relay de encapsulado): 5040 + 8346 = 13 386 bytes

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

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

- Hardware de 2 interfaces IDB x 13.386 = 26.772

- 8-subinterfaz IDB x 2260 = 18 080 subinterfaces

- 8 DLCI x 216 = 1728 DLCI

- 8 sentencias de mapa x 96 = 768 instrucciones de mapa o dinámica

El total es igual a 47.348 bytes de RAM utilizada.

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

Resolución de problemas de Frame Relay

Esta sección contiene partes del posible resultado del comando show interface que puede encontrarse mientras se resuelve el problema. También se proporcionan explicaciones del resultado.

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

Esta salida significa que tiene un problema con el cable, la unidad de servicio de canal/unidad de servicio de datos (CSU/DSU) o la línea serial. Debe resolver el problema con una prueba de loopback. Para realizar una prueba de loopback, siga estos pasos:

1. Establezca la encapsulación de línea serial en HDLC y keepalive en 10 segundos. Para hacerlo, ejecute los comandos encapsulation hdlc y keepalive 10 en la interfaz serial.

2. Coloque la CSU/DSU o el módem en el modo loop local. Si el protocolo de línea aparece cuando la CSU, la DSU o el módem se encuentra en el modo de loopback local (indicado por un mensaje "Line Protocol is up (looped)"), sugiere que el problema está ocurriendo más allá de la CSU/DSU local. Si la línea de estado no cambia los estados, posiblemente haya un problema en el router, conectando el cable, la CSU/DSU o el módem. En la mayoría de los casos, el problema es con la CSU/DSU o el módem.

3. Haga ping a su propia dirección IP con la CSU/DSU o con el loop del módem. No debería haber ninguna pérdida. Un ping extendido de 0x0000 es útil para resolver problemas de línea, ya que un T1 o E1 deriva el reloj de los datos y requiere una transición cada 8 bits. B8ZS lo asegura. Un patrón de datos pesado cero ayuda a determinar si las transiciones se forzan correctamente en el tronco. Un patrón de unos pesados se utiliza para simular apropiadamente una carga alta cero en caso de que haya un par de inversionistas de datos en el trayecto. El patrón alternativo (0x555) representa un patrón de datos "típico". Si sus pings fallan o si recibe errores de verificación de redundancia cíclica (CRC), se necesita un probador de tasa de error de bits (BERT) con un analizador apropiado de la compañía telefónica.

4. Cuando haya terminado de probar, asegúrese de devolver la encapsulación a Frame Relay.

Serial0 activo, protocolo de línea no funciona

Esta línea en la salida significa que el router está recibiendo una señal de portadora de la CSU/DSU o del módem. Asegúrese de que el proveedor de Frame Relay ha activado su puerto y que los parámetros de la interfaz de administración local (LMI) coinciden. Por lo general, el switch de Frame Relay ignora el equipo de terminal de datos (DTE) a menos que vea el LMI correcto (utilice el valor predeterminado de Cisco para "cisco" LMI). Verifique para asegurarse de que el router Cisco esté transmitiendo datos. Lo más probable es que deba verificar la integridad de la línea mediante pruebas de loop en varias ubicaciones, comenzando por la CSU local y trabajando para salir hasta que llegue al switch de Frame Relay del proveedor. Vea la sección anterior para ver cómo realizar una prueba de loopback.

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

Si no desactivó las señales de mantenimiento, esta línea de salida significa que el router está hablando con el switch del proveedor de Frame Relay. Debería ver un intercambio exitoso de tráfico bidireccional en la interfaz serial sin errores CRC. Las señales de mantenimiento son necesarias en Frame Relay porque son el mecanismo que el router utiliza para "aprender" qué identificadores de conexión de enlace de datos (DLCI) ha aprovisionado el proveedor. Para observar el intercambio, puede utilizar de manera segura debug frame-relay lmi en casi todas las situaciones. El comando debug frame-relay lmi genera muy pocos mensajes y puede proporcionar respuestas a preguntas como:

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

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

3. ¿Los DLCI son correctos?

A continuación se muestra un ejemplo de salida debug frame-relay lmi de 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, status 0x2

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

1. 0x0-Added/idle significa que el switch tiene este DLCI programado pero por alguna razón (como el otro extremo de este PVC está inactivo), no se puede utilizar.

2. 0x2-Added/active significa que el switch de Frame Relay tiene el DLCI y todo está operativo. Puede comenzar 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) configurado (0x1). Esto significa que el switch - o una cola determinada en el switch - para este PVC se realiza una copia de seguridad y usted deja de transmitir en caso de que las tramas se derramen.

4. 0x4-Deleted significa que el switch de Frame Relay no tiene este DLCI programado para el router. Pero fue programado en algún momento del pasado. Esto también podría ser causado por la inversión de los DLCI en el router o por la eliminación del PVC por la compañía telefónica en la nube de Frame Relay. La configuración de un DLCI (que el switch no tiene) aparecerá como 0x4.

5. 0x8-Nuevo/inactivo

6. 0x0a-Nuevo/activo

Características de Frame Relay

Esta sección explica varias características de Frame Relay de las cuales debe tener en cuenta.

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

La verificación del horizonte dividido de IP está inhabilitada de forma predeterminada para la encapsulación de Frame Relay, por lo que las actualizaciones de ruteo entrarán y saldrán de la misma interfaz. Los routers aprenden los identificadores de conexión de enlace de datos (DLCI) que necesitan utilizar desde el switch Frame Relay a través de las actualizaciones de la interfaz de administración local (LMI). A continuación, los routers utilizan ARP inverso para la dirección IP remota y crean un mapping de DLCI locales y sus direcciones IP remotas asociadas. Además, ciertos protocolos como AppleTalk, puente transparente e IPX no se pueden soportar en redes de malla parcial porque requieren "horizonte dividido", en el que un paquete recibido en una interfaz no se puede transmitir desde la misma interfaz, incluso si el paquete se recibe y se transmite en diferentes circuitos virtuales. La configuración de subinterfaces Frame Relay garantiza que una sola interfaz física se trate como interfaces virtuales múltiples. Esta capacidad nos permite superar las reglas de horizonte dividido. Los paquetes recibidos en una interfaz virtual ahora se pueden reenviar 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 con su propia dirección IP en una interfaz de Frame Relay multipunto. Esto se debe a que las interfaces multipunto (sub)Frame Relay no son de difusión (a diferencia de las interfaces Ethernet y punto a punto High-Level Data Link Control [HDLC]) y las subinterfaces punto a punto Frame Relay.

Además, no puede hacer ping de un spoke a otro spoke en una configuración de hub y spoke. Esto se debe a que no hay asignación para su propia dirección IP (y no se aprendió ninguna mediante ARP inverso). Pero si configura un mapa estático (usando el comando frame-relay map) para que su propia dirección IP (o una para el spoke remoto) use el DLCI local, entonces puede hacer ping a sus dispositivos.

aton#ping  3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

aton#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

aton(config)#interface serial 1

aton(config-if)#frame-relay map ip 3.1.3.3 160

aton(config-if)#

aton#show frame-relay map

Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,

broadcast,, status defined, active

Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,

CISCO, status defined, active

Serial1 (up): ip 3.1.3.3 dlci 160(0xA0,0x2800), static,

CISCO, status defined, active

aton#ping 3.1.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 64/68/76 ms

aton#

aton#show running-config

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

no ip directed-broadcast

encapsulation frame-relay

frame-relay map ip 3.1.3.2 160

frame-relay map ip 3.1.3.3 160

frame-relay interface-dlci 160

!

La palabra clave broadcast (difusión)

La palabra clave broadcast proporciona dos funciones: reenvía las difusiones cuando no se habilita la multidifusión y simplifica la configuración de OSPF (Open Shortest Path First) para las redes sin difusión que utilizan Frame Relay.

La palabra clave broadcast también puede ser necesaria para algunos protocolos de ruteo —por ejemplo, AppleTalk— que dependen de las actualizaciones regulares de la tabla de ruteo, especialmente cuando el router en el extremo remoto espera 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 acceso múltiple sin difusión como Frame Relay de la misma manera que trata a una red de broadcast. En las versiones anteriores, esta asignación manual necesaria en la configuración OSPF mediante el comando neighbor interface router. Cuando se incluye el comando frame-relay map en la configuración con la palabra clave broadcast y se configura el comando ip ospf network (con la palabra clave broadcast), no es necesario configurar ningún vecino manualmente. OSPF ahora se ejecuta automáticamente en la red Frame Relay como una red de difusión. (Consulte el comando ip ospf network interface para obtener más detalles.)

Nota: El mecanismo de broadcast OSPF asume que las direcciones IP de clase D nunca se utilizan para el tráfico regular sobre Frame Relay.

Ejemplo:

El siguiente ejemplo mapea 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 utiliza DLCI 100 para difundir las 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 serial0.2 y luego cambiarla a punto a punto. Para cambiarlo, debe recargar el router o crear otra subinterfaz. Así es como funciona el código de Frame Relay en el software Cisco IOS®.

Limitaciones de DLCI

Espacio de dirección DLCI

Se pueden configurar aproximadamente 1000 DLCI en un único link físico, dada una dirección de 10 bits. Debido a que algunos DLCI están reservados (dependen del proveedor), el máximo es de aproximadamente 1000. El rango para una LMI de Cisco es 16-1007. El rango establecido para ANSI/ITU es 16-992. Estos son los DLCI que llevan datos de usuario.

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

Para obtener más información, vea Número máximo de interfaces y subinterfaces para las plataformas de software del IOS de Cisco: Límites IDB.

Actualización de estado de LMI

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

La MTU predeterminada en las interfaces seriales es de 1500 bytes, lo que produce un máximo de 296 DLCI por interfaz. Puede aumentar la MTU para soportar un mensaje de actualización de estado completo más grande desde el switch Frame Relay. Si el mensaje de actualización de estado completo es mayor que la MTU de la interfaz, el paquete se descarta y el contador gigante de la interfaz se incrementa. Al cambiar la MTU, asegúrese de que se configure el mismo valor en el router remoto y en los dispositivos de red intervinientes.

Tenga en cuenta que estos números varían ligeramente, dependiendo del tipo de LMI. A continuación se enumeran las pautas de plataforma de DLCIs máximas por router (no interfaz), basadas en la extrapolación de datos empíricos establecidos en una plataforma de router Cisco 7000:

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

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

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

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

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

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

- Cisco 7500 6 enlaces T1/E1/T3/E3 a 120 DLCI por interfaz = 720 en total

Nota: Estos números son sólo pautas, y supongamos que todo el tráfico se conmuta rápidamente.

Otras consideraciones

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

Dirección IP/IPX/AT

Si utiliza subinterfaces, no coloque una dirección IP, IPX o AT en la interfaz principal. Asigne DLCI a sus subinterfaces antes de habilitar la interfaz principal para asegurarse de que frame-relay inverse-arp funcione correctamente. En caso de que funcione mal, siga estos pasos:

1. Desactive el protocolo de resolución de direcciones inversas (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. Vuelva a activar el comando frame-relay inverse-arp.

RIP y IGRP

Las actualizaciones del protocolo de información de routing (RIP) fluyen cada 30 segundos. Cada paquete RIP puede contener hasta 25 entradas de ruta, por un total de 536 bytes; 36 bytes de este total son información de encabezado y cada entrada de ruta es de 20 bytes. Por lo tanto, si anuncia 1000 rutas sobre un link de Frame Relay configurado para 50 DLCI, el resultado es 1 MB de datos de actualización de ruteo cada 30 segundos, o 285 kbps de ancho de banda consumido. En un link T1, este ancho de banda representa el 18,7% del ancho de banda, con una duración de actualización de 5,6 segundos. Esta cantidad de gastos generales es considerable, y es aceptable en términos límite, pero la tasa de información comprometida (CIR) tendría que estar en la región de la velocidad de acceso. Obviamente, cualquier cosa menos que un T1 incurriría en demasiada sobrecarga. Por ejemplo:

- 1000/25 = 40 paquetes X 36 = 1440 bytes de 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 s X 8 bits = 285 kbps

Las actualizaciones del protocolo de routing de gateway interior (IGRP) fluyen cada 90 segundos (este intervalo es configurable). Cada paquete IGRP puede contener 104 entradas de ruta, para un total de 1492 bytes, 38 de los cuales son información de encabezado, y cada entrada de ruta es de 14 bytes. Si anuncia 1000 rutas sobre un link de Frame Relay configurado con 50 DLCI, la solicitud es aproximadamente 720 KB de datos de actualización de ruteo cada 90 segundos, o 64 kbps de ancho de banda consumido. En un link T1, este ancho de banda representaría el 4,2% del ancho de banda, con cada duración de actualización de 3,7 segundos. Esta sobrecarga es una cantidad aceptable:

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

- 1000 X 14 = 14 000 bytes de entradas de ruta

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

- 717 000 bytes / 90 X 8 bits = 63,7 kbps

Las actualizaciones de routing del protocolo de mantenimiento de tabla de routing (RTMP) se producen cada 10 segundos (este intervalo es configurable). Cada paquete RTMP puede contener hasta 94 entradas de ruta extendidas, para un total de 564 bytes, 23 bytes de información de encabezado y cada entrada de ruta es de 6 bytes. Si anuncia 1000 redes AppleTalk a través de un link Frame Relay configurado para 50 DLCI, el resultado es aproximadamente 313 KB de actualizaciones de RTMP cada 10 segundos, o 250 kbps de ancho de banda consumido. Para permanecer dentro de un nivel aceptable de sobrecarga (15% o menos), se requiere una tasa T1. Por ejemplo:

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

- 1000 X 6 = 6000 bytes de entradas de ruta

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

- 313 000 / 10 s X 8 bits = 250 kbps

Las actualizaciones de paquetes IPX RIP se producen cada 60 segundos (este intervalo es configurable). Cada paquete IPX RIP puede contener hasta 50 entradas de ruta para un total de 536 bytes, 38 bytes de información de encabezado y cada entrada de ruta es de 8 bytes. Si anuncia 1000 rutas IPX sobre un link de Frame Relay configurado para 50 DLCI, el resultado es 536 KB de actualizaciones de IPX cada 60 segundos, o 58,4 kbps de ancho de banda consumido. Para mantener un nivel aceptable de sobrecarga (15% o menos), se requiere una velocidad de 512 kbps. Por ejemplo:

- 1000/50 = 20 paquetes X 38 bytes = 760 bytes de encabezado

- 1000 X 8 = 8000 bytes de entradas de ruta

- Total = 8760 X 50 DLCI = 438 000 bytes de actualizaciones IPX cada 60 segundos

- 438 000 / 60 s X 8 bits = 58,4 kbps

Las actualizaciones de paquetes de punto de acceso al servicio (SAP) IPX se producen cada 60 segundos (este intervalo es configurable). Cada paquete IPX SAP puede contener hasta siete entradas de anuncio para un total de 536 bytes, 38 bytes de información de encabezado y cada entrada de anuncio es de 64 bytes. Si emite 1000 anuncios IPX a través de un link Frame Relay configurado para 50 DLCI, terminaría con 536 KB de actualizaciones IPX cada 60 segundos, o con 58,4 kbps de ancho de banda consumido. Para mantener un nivel aceptable de sobrecarga (15% o menos), se requiere una velocidad superior a 2 Mbps. Obviamente, en este escenario se requiere el filtrado de SAP. En comparación con todos los demás protocolos mencionados en esta sección, las actualizaciones de IPX SAP requieren el mayor ancho de banda:

- 1000/7 = 143 paquetes X 38 bytes = 5434 bytes de encabezado

- 1000 X 64 = 64 000 bytes de entradas de ruta

- Total = 69,434 X 50 DLCI = 3,471,700 bytes de anuncios de servicio IPX cada 60 segundos

- 3 471 700 / 60 s X 8 bits = 462 kbps

Keepalive

En algunos casos, la señal de mantenimiento del dispositivo Cisco debe configurarse ligeramente más corta (unos 8 segundos) que la señal de mantenimiento del switch. Verá la necesidad de esto si la interfaz sigue subiendo y bajando.

Interfaces en serie

Las interfaces seriales, que de forma predeterminada son multipunto, son medios no broadcast, mientras que las subinterfaces punto a punto se transmiten. Si utiliza rutas estáticas, puede señalar el salto siguiente o la subinterfaz serial. Para multipunto, debe apuntar al salto siguiente. Este concepto es muy importante cuando se hace OSPF sobre Frame Relay. El router necesita saber que ésta es una interfaz de broadcast para que OSPF funcione.

OSPF y multipunto

OSPF y multipunto pueden ser muy problemáticos. OSPF necesita un router designado (DR). Si empieza a perder PVC, algunos routers pueden perder conectividad e intentar convertirse en un DR aunque otros routers todavía vean el DR antiguo. Esto hace que el proceso OSPF funcione mal.

La sobrecarga asociada con OSPF no es tan obvia y predecible como lo es con los protocolos de ruteo de vector de distancia tradicionales. La imprevisibilidad proviene de si los links de red OSPF son estables o no. Si todas las adyacencias a un router Frame Relay son estables, sólo fluirán los paquetes hello vecinos (keepalives), lo que es comparativamente mucho menos sobrecarga que la que se produce con un protocolo de vector de distancia (como RIP e IGRP). Sin embargo, si las rutas (adyacencias) son inestables, se producirá una inundación del estado del link y el ancho de banda se puede consumir rápidamente. OSPF también hace un uso muy intensivo del procesador cuando se ejecuta el algoritmo Dijkstra, que se utiliza para las rutas informáticas.

En las versiones anteriores del software Cisco IOS, se tuvo que tener especial cuidado al configurar OSPF sobre medios no broadcast de acceso múltiple como Frame Relay, X.25 y ATM. El protocolo OSPF considera estos medios como cualquier otro medio de difusión como Ethernet. Las nubes de acceso múltiple sin broadcast (NBMA) se suelen crear en una topología radial y hub. Los PVC o los circuitos virtuales conmutados (SVC) se establecen en una malla parcial y la topología física no proporciona el acceso múltiple que OSPF cree que existe. Para el caso de las interfaces seriales punto a punto, OSPF siempre forma una adyacencia entre los vecinos. Las adyacencias OSPF intercambian información de la base de datos. Para minimizar la cantidad de información intercambiada en un segmento determinado, OSPF elige un router para ser un DR y un router para ser un 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 tienen un punto de contacto central para el intercambio de información. La selección del DR se convirtió en un problema porque el DR y el BDR necesitaban tener conectividad física completa con todos los routers que existen en la nube. Además, debido a la falta de capacidades de difusión, DR y BDR necesitaban tener una lista estática de todos los demás routers conectados a la nube. Esta configuración se logra mediante el comando neighbor:

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

En las versiones posteriores del software Cisco IOS, se pueden utilizar diferentes métodos para evitar las complicaciones de configurar vecinos estáticos y tener routers específicos convirtiéndose en DR o BDRs en la nube no broadcast. El método que se debe utilizar depende de si la red es nueva o de un diseño existente que necesita modificaciones.

Una subinterfaz es una manera lógica de definir una interfaz. Es posible dividir una misma interfaz física en varias interfaces lógicas y cada una de las subinterfaces, a su vez, definirla como punto a punto. Este escenario se creó originalmente para manejar mejor los problemas causados por el horizonte dividido sobre NBMA y los protocolos de ruteo basados en vectores.

Una subinterfaz punto a punto tiene las propiedades de cualquier interfaz punto a punto física. En lo que respecta a OSPF, una adyacencia siempre se forma sobre una subinterfaz punto a punto sin elección de DR ni BDR. OSPF considera la nube un conjunto de links punto a punto en lugar de una red de acceso múltiple. El único inconveniente para el punto a punto es que cada segmento pertenece a una subred diferente. Esta situación podría no ser aceptable porque algunos administradores ya han asignado una subred IP para toda la nube. Otra solución alternativa es utilizar las interfaces sin numerar de IP en la nube. Este escenario también podría ser un problema para algunos administradores que administran la WAN basándose en las direcciones IP de las líneas seriales.

Fuentes

1. Comité Consultivo Telegráfico Internacional y Telefónico, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", Recomendación CCITT Q.922, 19 de abril de 1991.

2. Norma Nacional Americana para Telecomunicaciones - Red Digital de Servicios Integrados - Aspectos Básicos del Protocolo de Trama para Uso con Servicio de Portadora de Frame Relay, ANSI T1.618-1991, 18 de junio de 1991.

3. Tecnología de la información - Telecomunicaciones e intercambio de información entre sistemas - Identificación de protocolo en la capa de red, ISO/IEC TR 9577: 1990 (E) 1990-10-15.

4. Estándar Internacional, Sistemas de Procesamiento de Información - Redes de Área Local - Control de Link Lógico, ISO 8802-2: 1989 (E), IEEE 802.2-1989, 1989-12-31.

5. Descripción general de la tecnología de interconexión de redes, octubre de 1994, Cisco Systems

6. Finlayson, R., Mann, R., Mogul, J. y M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, Universidad de Stanford, 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: encapsulación multiprotocolo

9. MIB de Frame Relay RFC 1315

10. RFC 1293-Frame Relay Inverse ARP

11. Compresión de encabezado TCP/IP RFC 1144

12. Interfaz de red de usuario (UNI) de Frame Relay Forum (FRF) 1.1

13. Interfaz de red a red (NNI) de Frame Relay FRF 2.1

14. FRF 3.1-Encapsulación multiprotocolo

15. FRF 4-SVC

16. Administración de redes de clientes (MIB) del servicio de Frame Relay FRF 6

17. Banda de cuatro LMI

18. Q.922 Anexo A

19. ANSI T1.617 Anexo D

20. ANSI T1.618, T1.606

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

22. Guía de diseño de OSPF

23. Notas de Configuración para la Implementación Mejorada de IGRP Mejorado

Información Relacionada

- Más información sobre los comandos de Frame Relay

- Más información sobre la configuración de Frame Relay

- Más información sobre los comandos de respaldo de marcado

- Más información sobre Comandos de Debug ISDN

- Más información sobre los comandos de depuración PPP

- Más información sobre los tipos, códigos y valores de los switches ISDN

- Soporte Técnico y Documentación - Cisco Systems