Guía completa de configuración y resolución de problemas de Frame Relay
Contenido
Introducción
Frame Relay es un estándar de la industria, el protocolo de capa de link de datos conmutados que maneja varios circuitos virtuales mediante encapsulación HDLC (High-Level Data Link Control) entre los dispositivos conectados. En muchos casos, Frame Relay es más eficiente que X.25, protocolo del que generalmente se considera un sustituto. La siguiente figura ilustra una trama de Frame Relay (ANSI T1.618).
Observe que en la figura anterior, las direcciones Q.922, tal como están definidas actualmente, son dos octetos y contienen un identificador de conexión de link de datos (DLCI) de 10 bits. En algunas redes, las direcciones Q.922 se pueden aumentar opcionalmente a tres o cuatro octetos.
Los campos "indicador" delimitan el principio y el final del marco. Después del campo "indicador" inicial hay dos bytes de información de dirección. Diez bits de estos dos bytes componen 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 de direccionamiento básico (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 referirse a esa misma conexión.
Antes de comenzar
Convenciones
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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.
Teoría Precedente
Frame Relay se concibió originalmente como un protocolo para su uso en interfaces ISDN. En 1984 se presentaron al Sector de Normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones (UIT-T) (anteriormente el Comité Consultivo Internacional de Telégrafos y Telefonía [CCITT]) propuestas iniciales a tal efecto. El trabajo sobre Frame Relay también se llevó a cabo en el comité de estándares T1S1 acreditado por ANSI en Estados Unidos.
En 1990, Cisco Systems, StrataCom, Northern Telecom y Digital Equipment Corporation formaron un consorcio para centrarse en el desarrollo de tecnología Frame Relay y acelerar la introducción de productos Frame Relay interoperables. Desarrollaron una especificación que se ajustaba al protocolo Frame Relay básico que se discutía en T1S1 e ITU-T, pero lo ampliaron con funciones que proporcionan capacidades adicionales para entornos de interconexión de redes complejos. Estas extensiones de Frame Relay se conocen colectivamente como LMI. Se trata de la LMI de "cisco" en el router en lugar de la 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 los nodos de conmutación). Los dispositivos de usuario se denominan a menudo equipos terminales de datos (DTE), mientras que los equipos de red que interactúan con DTE se denominan a menudo equipos de terminación de circuitos de datos (DCE). La red que proporciona la interfaz Frame Relay puede ser una red pública proporcionada por el operador o una red de equipo privado que atiende a una sola empresa.
Frame Relay difiere significativamente de X.25 en su funcionalidad y formato. En particular, Frame Relay es un protocolo más optimizado, 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 (denominados circuitos virtuales) sobre un solo link de transmisión física. Esto contrasta con los sistemas que solo utilizan técnicas de multiplexación por división de tiempo (TDM) para admitir varios flujos 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 de TDM o en canales superiores proporcionados por los sistemas de TDM.
Otra característica importante de Frame Relay es que aprovecha los recientes avances en la tecnología de transmisión de la red de área extensa (WAN). Los protocolos WAN anteriores, como X.25, se desarrollaban 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 actualmente. A través de links como estos, los protocolos de capa de link pueden renunciar a algoritmos de corrección de errores que consumen mucho tiempo, dejando que estos se realicen 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 se ha 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 los datos se puedan descartar), pero no incluye ningún mecanismo de protocolo para corregir datos incorrectos (por ejemplo, mediante la retransmisión en 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 duplican los de las capas superiores. En su lugar, se proporcionan mecanismos de notificación de congestión muy sencillos para permitir que una red informe a un dispositivo de usuario de que los recursos de red están cerca de un estado de congestión. Esta notificación puede alertar a los protocolos de capa superior de que puede ser necesario controlar el flujo.
Configuración de Basic Frame Relay
Una vez que tenga conexiones confiables con el switch Frame Relay local en ambos extremos del circuito virtual permanente (PVC), es hora de comenzar a planificar la configuración de Frame Relay. En este primer ejemplo, el tipo de interfaz de administración local (LMI) toma de forma predeterminada "cisco" LMI en Spicey. Una interfaz es de forma predeterminada una interfaz "multipunto", por lo que frame-relay inverse-arp está activado (para punto a punto, no hay ARP inverso). La verificación de horizonte dividido 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 de LMI. A continuación, los routers utilizan ARP inverso para la dirección IP remota y crean una asignación de DLCI locales y sus direcciones IP remotas asociadas.
Diagrama de la red
Configuraciones
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1705 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 3.1.3.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 140 ! ! router rip network 3.0.0.0 network 124.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1499 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! ! interface Serial1 ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 150 ! ! router rip network 3.0.0.0 network 123.0.0.0 ! ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Comandos debug y show
Antes de ejecutar un comando debug, consulte Información Importante sobre Comandos Debug.
-
show frame-relay map
-
show frame-relay pvc
-
show frame-relay lmi
-
ping <device name>
-
show ip route
Spicey
Spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 83 output pkts 87 in bytes 8144
out bytes 8408 dropped pkts 0 in FECN pkts0
in BECN pkts 0 out FECN pkts 0 out BECN pkts0
in DE pkts 0 out DE pkts 0
out bcast pkts 41 out bcast bytes 3652
pvc create time 01:31:50, last time pvc status changed 01:28:28
Spicey#show frame-relay lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 550 Num Status msgs Rcvd 552
Num Update Status Rcvd 0 Num Status Timeouts 0
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial0
124.0.0.0/24 is subnetted, 1 subnets
C 124.124.124.0 is directly connected, Ethernet0
R 123.0.0.0/8 [120/1] via 3.1.3.2, 00:00:08, Serial0
Prasit
Prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 87 output pkts 83 in bytes 8408
out bytes 8144 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 38 out bcast bytes 3464
pvc create time 01:34:29, last time pvc status changed 01:28:05
Prasit#show frame-relay lmi
LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 569 Num Status msgs Rcvd 570
Num Update Status Rcvd 0 Num Status Timeouts 0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial1
R 124.0.0.0/8 [120/1] via 3.1.3.1, 00:00:19, Serial1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Configuración de retransmisión de tramas de eje de conexión y radio
En este ejemplo, el router aprende 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 utilizará ARP inverso para la dirección IP remota.
Nota: No podrá hacer ping a la dirección IP serial de Prasit desde Atón a menos que agregue explícitamente mapas de Frame Relay en cada extremo. Si el ruteo está configurado correctamente, el tráfico que se origina en las LAN no debería tener ningún problema. Podrá hacer ping si utiliza la dirección IP de Ethernet como dirección de origen en un ping extendido.
Cuando se habilita frame-relay inverse-arp, el tráfico broadcast IP se apagará por la conexión de forma predeterminada.
Diagrama de la red
Configuraciones
| Spicey |
|---|
spicey#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname spicey ! ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 3.1.3.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 130 frame-relay interface-dlci 140 ! ! router rip network 3.0.0.0 network 124.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
prasit#show running-config Building configuration... Current configuration : 1499 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 150 ! ! router rip network 3.0.0.0 network 123.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Atón |
|---|
aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname aton ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.3 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 160 ! router rip network 3.0.0.0 network 122.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Comandos show
-
show frame-relay map
-
show frame-relay pvc
-
ping <device name>
Spicey
spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,
broadcast,, status defined, active
spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 32 output pkts 40 in bytes 3370
out bytes 3928 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 30 out bcast bytes 2888
pvc create time 00:15:46, last time pvc status changed 00:10:42
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 282 output pkts 291 in bytes 25070
out bytes 27876 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 223 out bcast bytes 20884
pvc create time 02:28:36, last time pvc status changed 02:25:14
spicey#
spicey#ping 3.1.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
spicey#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Prasit
prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 311 output pkts 233 in bytes 28562
out bytes 22648 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 162 out bcast bytes 15748
pvc create time 02:31:39, last time pvc status changed 02:25:14
prasit#ping 3.1.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
prasit#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Atón
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 se detecta la dirección del hub a través del protocolo de resolución de direcciones inversas (IARP). Si configura un mapa estático mediante el comando frame-relay map para que la dirección IP de un spoke remoto utilice el identificador de conexión de link de datos (DLCI) local, puede hacer ping a las direcciones de otros spokes.
Configuraciones
| Prasit |
|---|
prasit#show running-config interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 3.1.3.3 150 frame-relay interface-dlci 150 |
Comandos show
-
show frame-relay map
-
ping <device name>
-
show running-config
Prasit
prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Serial1 (up): ip 3.1.3.3 dlci 150(0x96,0x2460), static,
CISCO, status defined, active
prasit#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/80 ms
prasit#ping 122.122.122.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/76 ms
Atón
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 admitir 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, entonces la estación A debe poder hablar con la estación C directamente. La transitividad es verdadera en las LAN, pero no en las redes Frame Relay a menos que A esté conectado directamente con C.
Además, ciertos protocolos, como AppleTalk y el bridging transparente, no pueden ser soportados en redes con malla parcial porque requieren "split horizon" en el cual un paquete recibido en una interfaz no puede ser transmitido a través de la misma interfaz incluso si el paquete es recibido y transmitido en diferentes circuitos virtuales.
La configuración de subinterfaces de 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 fuera de otra interfaz virtual, incluso si están configurados en la misma interfaz física.
Las subinterfaces resuelven las limitaciones de las redes Frame Relay al proporcionar una manera de subdividir una red Frame Relay parcialmente mallada en una cantidad de subredes más pequeñas, totalmente malladas (o punto a punto). A cada subred se le asigna su propio número de red y se muestra a los protocolos como si fuera accesible 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, de lo contrario, podría resultar).
Subinterfaces punto a punto
Diagrama de la red
Configuraciones
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1338 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! enable password ww ! ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 3.1.3.1 255.255.255.0 frame-relay interface-dlci 140 ! ! router igrp 2 network 3.0.0.0 network 124.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1234 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point ip address 3.1.3.2 255.255.255.0 frame-relay interface-dlci 150 ! router igrp 2 network 3.0.0.0 network 123.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Comandos show
-
show frame-relay map
-
show frame-relay pvc
Spicey
Spicey#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
input pkts 193 output pkts 175 in bytes 20450
out bytes 16340 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 50 out bcast bytes 3786
pvc create time 01:11:27, last time pvc status changed 00:42:32
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit
Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 74 output pkts 89 in bytes 7210
out bytes 10963 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 24 out bcast bytes 4203
pvc create time 00:12:25, last time pvc status changed 00:12:25
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Subinterfaces hub y spoke
La siguiente configuración de ejemplo de hub y spoke muestra dos subinterfaces punto a punto y utiliza resolución de dirección 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 los destinos remotos para cada subinterfaz punto a punto no se resuelven, ya que son punto a punto y el tráfico se debe enviar al par del 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 |
|---|
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 |
| Atón |
|---|
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
Atón
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 ARP inverso de Frame Relay 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 ARP inversas se ingresan en una tabla de mapeo de dirección a DLCI en el router o el servidor de acceso; la tabla se utiliza entonces 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 protocolo-DLCI si sabe que el protocolo no es compatible en el otro extremo de la conexión. Debido a que el ARP inverso está habilitado de forma predeterminada para todos los protocolos que admite, no se requiere ningún comando adicional para configurar la asignación dinámica de direcciones en una subinterfaz. Un mapa estático vincula una dirección de protocolo de siguiente salto especificada a un DLCI especificado. La asignación estática elimina la necesidad de solicitudes ARP inversas; cuando se proporciona un mapa estático, ARP inverso se inhabilita automáticamente para el protocolo especificado en el DLCI especificado. 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 de Cisco para realizar el ARP inverso. El siguiente ejemplo muestra cómo configurar mapas estáticos en caso de que los necesite para interfaces o subinterfaces multipunto:
Configuraciones
| Atón |
|---|
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
Atón
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 de 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 su tráfico se rutee de la manera habitual, y debe utilizar subinterfaces punto a punto.
Diagrama de la red
El siguiente ejemplo ilustra esto:
Configuraciones
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1674 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip unnumbered Ethernet0 frame-relay interface-dlci 140 ! router igrp 2 network 124.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1188 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point ip unnumbered Ethernet0 frame-relay interface-dlci 150 ! router igrp 2 network 123.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Comandos show
-
show frame-relay map
-
show frame-relay pvc
Spicey
Spicey#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial0.1
input pkts 23 output pkts 24 in bytes 3391
out bytes 4952 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 14 out bcast bytes 3912
pvc create time 00:04:47, last time pvc status changed 00:04:47
Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
124.0.0.0/24 is subnetted, 1 subnets
C 124.124.124.0 is directly connected, Ethernet0
123.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
I 123.0.0.0/8 [100/8576] via 123.123.123.1, 00:01:11, Serial0.1
I 123.123.123.0/32 [100/8576] via 123.123.123.1, 00:01:11,
Serial0.1
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit
Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 24 output pkts 52 in bytes 4952
out bytes 10892 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 41 out bcast bytes 9788
pvc create time 00:10:54, last time pvc status changed 00:03:51
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
I 124.0.0.0/8 [100/8576] via 124.124.124.1, 00:00:18, Serial1.1
I 124.124.124.0/32 [100/8576] via 124.124.124.1, 00:00:18,
Serial1.1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/120/436 ms
Configuración de respaldo para Frame Relay
Respaldo de retransmisión de tramas sobre ISDN
Es posible que desee realizar una copia de seguridad de los circuitos Frame Relay mediante ISDN. Hay varias formas de hacerlo. La primera, y probablemente la mejor, es utilizar rutas estáticas flotantes que enrutan el tráfico a una dirección IP de interfaz de velocidad básica (BRI) y utilizan una métrica de routing adecuada. También puede utilizar una interfaz de copia de seguridad en la interfaz principal o en función del identificador de conexión de enlace de datos (DLCI). Es posible que no sea muy útil realizar una copia de seguridad de la interfaz principal, ya que podría perder circuitos virtuales permanentes (PVC) sin que la interfaz principal se desactive. Recuerde que el protocolo se intercambia con el switch Frame Relay local, no con el router remoto.
Configuraciones
| Router 1 |
|---|
ROUTER1# ! hostname ROUTER1 ! username ROUTER2 password same isdn switch-type basic-dms100 ! interface Ethernet 0 ip address 172.16.15.1 255.255.255.248 ! interface serial 0 ip address 172.16.24.129 255.255.255.128 encapsulation FRAME-RELAY ! interface BRI0 description Backup ISDN for frame-relay ip address 172.16.12.1 255.255.255.128 encapsulation PPP dialer idle-timeout 240 dialer wait-for-carrier-time 60 dialer map IP 172.16.12.2 name ROUTER2 broadcast 7086639706 ppp authentication chap dialer-group 1 isdn spid1 0127280320 2728032 isdn spid2 0127295120 2729512 ! router igrp 1 network 172.16.0.0 ! ip route 172.16.15.16 255.255.255.248 172.16.12.2 150 !--- Floating static route. ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 dialer-list 1 LIST 101 ! |
| Router 2 |
|---|
ROUTER2# ! hostname ROUTER2 ! username ROUTER1 password same isdn switch-type basic-dms100 ! interface Ethernet 0 ip address 172.16.15.17 255.255.255.248 ! interface Serial 0 ip address 172.16.24.130 255.255.255.128 encapsulation FRAME-RELAY ! interface BRI0 description ISDN backup interface for frame-relay ip address 172.16.12.2 255.255.255.128 encapsulation PPP dialer idle-timeout 240 dialer map IP 172.16.12.1 name ROUTER1 broadcast ppp authentication chap pulse-time 1 dialer-group 1 isdn spid1 0191933333 4445555 isdn spid2 0191933334 4445556 ! router igrp 1 network 172.16.0.0 ! ip route 172.16.15.0 255.255.255.248 172.16.12.1 150 !--- Floating static route. ! access-list 101 deny igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 access-list 101 permit ip 0.0.0.0 255.255.255.255 162.27.9.0 0.0.0.255 dialer-list 1 LIST 101 ! |
Comandos show
Para verificar si ISDN está funcionando, 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 de llamada 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 al sacar 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 al lado central (Spicey). Tenga cuidado de agregar solamente los comandos de respaldo al lado que está llamando al lado central.
Nota: La carga de copia de seguridad no se soporta en las subinterfaces. Dado que no realizamos un seguimiento de los niveles de tráfico en las subinterfaces, no se calcula ninguna carga.
Diagrama de la red
Configuraciones
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1438 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! username Prasit password 0 cisco ! ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 4.0.1.1 255.255.255.0 frame-relay interface-dlci 140 ! interface BRI0 ip address 3.1.6.1 255.255.255.0 encapsulation ppp dialer map ip 3.1.6.2 name Prasit broadcast dialer-group 1 isdn switch-type basic-net3 no peer default ip address no cdp enable ppp authentication chap ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 124.0.0.0 ! ip classless ip route 123.123.123.0 255.255.255.0 3.1.6.2 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1245 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! username Spicey password 0 cisco ! ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point backup delay 5 10 backup interface BRI0 ip address 4.0.1.2 255.255.255.0 frame-relay interface-dlci 150 ! interface BRI0 ip address 3.1.6.2 255.255.255.0 encapsulation ppp dialer map ip 3.1.6.1 name Spicey broadcast 6106 dialer-group 1 isdn switch-type basic-net3 ppp authentication chap ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 123.0.0.0 ! ip route 124.124.124.0 255.255.255.0 3.1.6.1 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Comandos show
-
show frame-relay map
-
show ip route
-
show isdn history
-
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 en serie está de vuelta.
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 un hub y spoke por configuración de respaldo DLCI. Los routers radiales están llamando al router hub. Como puede ver, solo permitimos un canal B por lado mediante la opción max-link en el conjunto de marcadores en el lado del concentrador.
Nota: La carga de copia de seguridad no se soporta en las subinterfaces. Dado que no realizamos un seguimiento de los niveles de tráfico en las subinterfaces, no se calcula ninguna carga.
Diagrama de la red
Configuraciones
| Atón |
|---|
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
Atón
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#
La serie 1 está cayendo.
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 vuelve a estar activo
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 de la llamada 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#
La serie 1 se cae.
Prasit#
*Mar 1 01:16:08.287: %LINK-3-UPDOWN: Interface Serial1, changed state to down
*Mar 1 01:16:09.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial1, changed state to down
*Mar 1 01:16:11.803: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:16:11.819: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
*Mar 1 01:16:11.855: %LINK-3-UPDOWN: Interface BRI0, changed state to up
*Mar 1 01:16:15.967: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI
64 changed to up
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
160.160.0.0/24 is subnetted, 1 subnets
C 160.160.160.0 is directly connected, BRI0
124.0.0.0/24 is subnetted, 1 subnets
S 124.124.124.0 [250/0] via 160.160.160.1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
*Mar 1 01:21:38.967: %LINK-3-UPDOWN: Interface BRI0:1, changed state to
up.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms
Prasit#
*Mar 1 01:21:40.063: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
*Mar 1 01:21:44.991: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
to 6106 Spicey
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit#
Serial 1 vuelve a estar activo.
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 basado en el identificador de conexión de link de datos (DLCI). Podemos ver esto como el Frame Relay equivalente a una dirección de control de acceso a medios (MAC). La conmutación se realiza configurando el router de Cisco o el servidor de acceso en una red Frame Relay. Una red Frame Relay consta de dos partes:
-
Equipo de terminal de datos (DTE) de Frame Relay: router o servidor de acceso.
-
Interruptor de Frame Relay Data Circuit-Terminating Equipment (DCE).
Nota: En Cisco IOS Software release 12.1(2)T y posteriores, el comando frame route ha sido reemplazado por el comando connect.
Veamos un ejemplo de configuración. En la siguiente configuración, estamos utilizando el router America como un switch Frame Relay. Utilizamos Spicey como router hub y Prasit y Aton como routers spoke. Los hemos conectado de la siguiente manera:
-
Prasit serial 1 (s1) DTE está conectado a America serial 1/4 (s1/4) DCE.
-
Spicey serial 0 (s0) DTE está conectado a America serial 1/5 (s1/5) DCE.
-
El DTE de serie 1 (s1) de Atón está conectado al DCE de serie 3/4 (s3/4) de América.
Diagrama de la red
Este documento se basa en la siguiente configuración:
Configuraciones
| Spicey |
|---|
Spicey#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 3.1.3.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 130 frame-relay interface-dlci 140 ! ! router rip network 3.0.0.0 network 124.0.0.0 ! line con 0 ! exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1499 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 150 ! ! router rip network 3.0.0.0 network 123.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Atón |
|---|
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
Atón
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 link de datos (DLCI) es el proceso por 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 de 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 Internetwork Packet Exchange [IPX], IGX y BPX o AXIS de Stratacom) en realidad 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 un DLCI secundario deja de funcionar, perderá el tráfico destinado a esa cola solamente.
-
Si pierde el DLCI primario, la subinterfaz se desactiva y pierde todo el tráfico.
Diagrama de la red
Para utilizar esta configuración, debe tener cuatro DLCI para el lado que utilizará la priorización DLCI. En este ejemplo, hemos configurado Spicey para la cola de prioridad de la siguiente manera:
-
Ping se encuentra en la cola de prioridad alta.
-
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 se correspondan con la lista de prioridades o el sistema no utilizará la cola correcta.
Configuraciones
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1955 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec ! hostname Spicey ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay priority-group 1 ! interface Serial0.1 point-to-point ip address 4.0.1.1 255.255.255.0 frame-relay priority-dlci-group 1 140 180 190 200 frame-relay interface-dlci 140 ! router igrp 2 network 4.0.0.0 network 124.0.0.0 ! access-list 102 permit icmp any any priority-list 1 protocol ip high list 102 priority-list 1 protocol ip medium tcp telnet priority-list 1 protocol ip normal tcp ftp priority-list 1 protocol ip low ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 ip address 4.0.1.2 255.255.255.0 encapsulation frame-relay ! router igrp 2 network 4.0.0.0 network 123.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
Comandos debug y show
Utilice los 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:
El resto del 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#
Aquí está el resultado de la depuración 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 medianas a grandes en las que las transmisiones de puntos de acceso de servicio (SAP) y routing deben fluir a través de la red Frame Relay. La cola de difusión se administra independientemente de la cola de interfaz normal, tiene sus propios búferes y tiene un tamaño y una velocidad de servicio configurables. Esta cola de difusión no se utiliza para las actualizaciones de árbol de extensión de puente (BPDU) debido a las sensibilidades de temporización. Estos paquetes fluirán a través de las colas normales. El comando interface para habilitar la cola de broadcast sigue:
frame-relay broadcast-queue size byte-rate packet-rate
A una cola de difusión se le da un límite de velocidad máxima de transmisión (rendimiento) medido en bytes por segundo y en paquetes por segundo. Se presta servicio a la cola para garantizar que solo se proporciona este máximo. La cola de broadcast tiene prioridad al transmitir a una velocidad inferior al máximo configurado y, por lo tanto, tiene una asignación de ancho de banda mínima garantizada. Los dos límites de velocidad de transmisión están pensados para evitar inundar la interfaz con difusiones. El límite real en cualquier segundo es el primer límite de velocidad que se alcanza. Dada la restricción de velocidad de transmisión, se requiere almacenamiento en búfer adicional para almacenar los paquetes de difusión. 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 está utilizando y del número de paquetes necesarios para cada actualización. Para garantizar la seguridad, el tamaño de la cola debe configurarse de modo que se pueda almacenar una actualización de ruteo completa de cada protocolo y para cada identificador de conexión de link de datos (DLCI). Como regla general, comience con 20 paquetes por DLCI. La velocidad de bytes debe ser menor que las dos opciones 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 de paquetes no es crítica si la velocidad de bytes se establece de forma conservadora. En general, la velocidad de paquetes debe establecerse asumiendo paquetes de 250 bytes. Los valores predeterminados para las interfaces seriales son 64 tamaños 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 de 256 tamaños de cola, 1.024.000 bytes por segundo (8.192.000 bps) y 144 pps.
Modelado de tráfico
El modelado de tráfico utiliza un mecanismo de control de velocidad llamado 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, pero 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 Información general sobre políticas y formas.
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 exceso de información
-
TB = token bucket (= Bc + Be)
-
Bc = tamaño de ráfaga comprometida (= tamaño de ráfaga sostenido)
-
Be = tamaño de ráfaga excesivo
-
DE = criterios de selección de descartes
-
Tc = intervalo de medición
-
AR = velocidad de acceso correspondiente a la velocidad de la interfaz física (por lo tanto, si utiliza un T1, el AR es de aproximadamente 1,5 Mbps).
Veamos algunos de estos parámetros con más detalle:
Tasa 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 de usuario limita la velocidad de acceso. Puede establecerlo en su suscripción al proveedor de servicios.
Tamaño De Ráfaga Confirmada (Bc)
La cantidad máxima comprometida de datos que puede ofrecer a la red se define como Bc. Bc es una medida del volumen de datos para el que 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)
La cantidad de bits no comprometidos (fuera de CIR) que aún son aceptados por el switch Frame Relay pero que se marcan como elegibles para ser descartados (DE).
El token bucket es un buffer 'virtual'. Contiene varios tokens, lo que 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 está llena de tokens Bc + Be, puede enviar bits Bc + Be a la velocidad de acceso. Esto no está limitado por Tc sino por el tiempo que toma enviar el Be. Esta es una función de la velocidad de acceso.
Committed Information Rate (CIR)
La CIR es la cantidad de datos permitidos que la red está comprometida a transferir en condiciones normales. La tasa se promedia en un incremento de tiempo Tc. El CIR también se conoce como el 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 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 para cada 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 en particular.
-
Tc = Bc / CIR
-
Pico = CIR + Be/Tc = CIR (1 + Be/Bc)
Si el Tc es de un segundo, entonces:
-
Pico = CIR + Be = Bc + Be
-
EIR = Be
En el ejemplo que utilizamos aquí, el router envía tráfico entre 48 y 32 Kbps dependiendo de la congestión de la red. Las redes pueden marcar las tramas por encima de Bc con DE, pero tienen suficiente capacidad de reserva para transportar la trama. Lo contrario también es posible: pueden tener una capacidad limitada, pero descartar tramas excesivas inmediatamente. Las redes pueden marcar las tramas por encima de Bc + Be con DE, y posiblemente transportarlas, o simplemente descartar las tramas según lo sugerido por la especificación ITU-T I.370 del Sector de Normalización de Telecomunicaciones de la Unión Internacional de Telecomunicaciones. El modelado de tráfico acelera el tráfico basándose en paquetes etiquetados de notificación de congestión explícita hacia atrás (BECN) de la red del switch. Si recibe el 50 por ciento de BECN, el router disminuye el tráfico en un octavo del ancho de banda transmitido actualmente 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), lo que hace que 36,75 Kb. Si la congestión disminuye después del cambio, el router reduce aún más el tráfico, disminuyendo a un octavo del ancho de banda transmitido actualmente. El tráfico se reduce hasta que alcanza el valor CIR configurado. Sin embargo, la velocidad puede caer bajo la 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 para 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 encapsulación y medios 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 teletrabajo cuando el sitio central envía datos a una velocidad más rápida que los sitios remotos pueden recibir. Esto da como resultado un cuello de botella en el último switch antes del router de punto remoto.
-
Si es un proveedor de servicios que ofrece servicios de velocidad inferior, esta función le permite utilizar el router para dividir los enlaces 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 acelere 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 aceleración basada en BECN que se proporciona con esta función permite que el router acelere dinámicamente el tráfico en función de la recepción de paquetes etiquetados BECN de la red. Esta aceleración mantiene los paquetes en los búferes del router para reducir el flujo de datos desde el router hacia la red Frame Relay. El router regula el tráfico en función de la subinterfaz y la velocidad también aumenta cuando se reciben menos paquetes etiquetados con BECN.
Comandos para el modelado de tráfico genérico
Para definir el control de velocidad, utilice este comando:
traffic-shape rate bit-rate [burst-size [exceso-burst-size]] [group access-list]
Para regular los BECN en una interfaz Frame Relay, utilice este comando:
traffic-shape adaptive [bit-rate]
Para configurar una subinterfaz de 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 da forma al tráfico cuando la interfaz recibe BECN. La tasa realmente utilizada se encuentra 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 del 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 (generalmente 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 del 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 de 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 velocidad por VC: puede configurar una velocidad pico para limitar el tráfico saliente a la CIR o a algún otro valor definido, como la velocidad de exceso de información (EIR).
-
Compatibilidad con BECN generalizada por VC: el router puede supervisar los BECN y regular el tráfico en función de los comentarios de paquetes marcados con BECN de la red Frame Relay.
-
Cola prioritaria (PQ), cola personalizada (CQ) o compatibilidad con 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 brinda 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 cubos de token.
-
Uno funciona entre 64000 (CIR) y 128000 (Bc + Be).
-
El otro se extiende 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, consulte 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 Frame Relay Traffic Shaping - Token Bucket Flowchart.
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 que entran y salen, los paquetes perdidos si hay congestión en la línea a través de 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 la salida de un comando show frame-relay pvc de su dispositivo Cisco, puede utilizar Output Interpreter (sólo clientes registrados) para mostrar los 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 USO DE DLCI contiene una de las entradas siguientes:
-
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).
-
NO UTILIZADO: 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 (Estado de PVC) muestra estos parámetros de la siguiente manera:
-
ACTIVO - El PVC está activo y funcionando normalmente.
-
INACTIVO: el PVC no está en funcionamiento 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 a que se ha eliminado el extremo remoto del PVC.
-
DELETED (ELIMINADO): la interfaz de administración local (LMI) no se intercambia entre el router y el switch local, o el switch no tiene DLCI configurado en el switch local.
-
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 los comandos de frame relay.
Si tiene la salida de un comando show frame-relay map de su dispositivo Cisco, puede utilizar Output Interpreter (sólo para clientes registrados) para mostrar los 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 los puentes y constituyen una cantidad significativa de tráfico debido a su frecuente ocurrencia. Hay dos tipos de protocolos de árbol de expansión en el bridging transparente. Introducido por primera vez por la 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 expansión DEC emite BPDU en intervalos de un segundo, mientras que el IEEE emite BPDU en intervalos de dos segundos. Cada paquete es de 41 bytes, que incluye un mensaje BPDU de configuración de 35 bytes, un encabezado Frame Relay de 2 bytes, Ethertype de 2 bytes y FCS de 2 bytes.
Retransmisión de tramas y memoria
El consumo de memoria para los recursos de Frame Relay se produce en cuatro áreas:
-
Cada identificador de conexión de vínculo de datos (DLCI): 216 bytes
-
Cada sentencia de mapa: 96 bytes (o mapa construido dinámicamente)
-
Cada IDB (interfaz de hardware + encapsular Frame Relay): 5040 + 8346 = 13 386 bytes
-
Cada IDB (subinterfaz de software): 260 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 subinterfaces IDB x 2260 = 18 080 subinterfaces
-
8 DLCI x 216 = 1728 DLCI
-
8 sentencias de mapa x 96 = 768 sentencias de mapa o dinámica
El total es igual a 47.348 bytes de RAM utilizados.
Nota: Los valores utilizados aquí 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 de la posible salida del comando show interface que puede encontrar al resolver problemas. 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:
-
Establezca la encapsulación de línea serial en HDLC y keepalive en 10 segundos. Para ello, ejecute los comandos encapsulation hdlc y keepalive 10 en la interfaz serial.
-
Coloque la CSU/DSU o el módem en el modo de loop local. Si el protocolo de línea aparece cuando la CSU, DSU o el módem está en modo de loopback local (indicado por un mensaje "line protocol is up (looped)"), sugiere que el problema ocurre más allá de la CSU/DSU local. Si la línea de estado no cambia de estado, es posible que exista un problema en el router, el cable de conexión, 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.
-
Haga ping a su propia dirección IP con la CSU/DSU o el módem en bucle. No debe 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 se asegura de que. Un patrón de datos de cero pesado 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 cero alta en caso de que haya un par de inversores de datos en el trayecto. El patrón alterno (0x5555) representa un patrón de datos "típico". Si sus pings fallan o si obtiene errores de verificación por 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.
-
Cuando haya terminado de probar, asegúrese de que devuelve 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 portadora de la CSU/DSU o del módem. Asegúrese de que el proveedor de Frame Relay haya activado su puerto y de que la configuración de la interfaz de administración local (LMI) coincida. Generalmente, el switch 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). Asegúrese de que el router de Cisco está transmitiendo datos. Lo más probable es que necesite verificar la integridad de la línea mediante pruebas de loop en varias ubicaciones, comenzando con la CSU local y avanzando hasta llegar al switch Frame Relay del proveedor. Consulte la sección anterior para saber cómo realizar una prueba de loopback.
“Serial0 está activo, el protocolo de línea está activo”
Si no desactivó los keepalives, esta línea de salida significa que el router está hablando con el switch del proveedor de Frame Relay. Debería estar viendo 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 link de datos (DLCI) ha suministrado el proveedor. Para observar el intercambio, puede utilizar con seguridad 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:
-
¿El router de Cisco está hablando con el switch Frame Relay local?
-
¿Recibe el router mensajes de estado de LMI completo para los circuitos virtuales permanentes (PVC) suscritos del proveedor de Frame Relay?
-
¿Son correctos los DLCI?
A continuación se muestra un ejemplo de salida de 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:
-
0x0-Added/inactive significa que el switch tiene este DLCI programado pero por alguna razón (como que el otro extremo de este PVC está inactivo), no es utilizable.
-
0x2-Added/active significa que el switch Frame Relay tiene el DLCI y todo está operativo. Puede comenzar a enviar tráfico con este DLCI en el encabezado.
-
0x3-0x3 es una combinación de un estado activo (0x2) y el RNR (o bit r) que se establece (0x1). Esto significa que se realiza una copia de seguridad del switch, o de una cola particular en el switch, para este PVC, y se deja de transmitir en caso de que se derramen tramas.
-
0x4-Deleted significa que el switch Frame Relay no tiene este DLCI programado para el router. Pero fue programado en algún momento en el pasado. Esto también podría deberse a que los DLCI se invierten en el router o a que la compañía telefónica elimina el PVC en la nube de Frame Relay. La configuración de un DLCI (que el switch no tiene) aparecerá como 0x4.
-
0x8-Nuevo/inactivo
-
0x0a-Nuevo/activo
Características de Frame Relay
Esta sección explica varias características de Frame Relay que debe conocer.
Verificación mediante la técnica de división del horizonte de IP
La verificación de horizonte dividido 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 link 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 una asignación de DLCI locales y sus direcciones IP remotas asociadas. Además, ciertos protocolos como AppleTalk, el bridging transparente e IPX no pueden ser soportados en redes con malla parcial porque requieren "split horizon", en el cual un paquete recibido en una interfaz no puede ser transmitido a través de la misma interfaz, incluso si el paquete es recibido y transmitido en diferentes circuitos virtuales. La configuración de subinterfaces de 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 fuera de 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 a su propia dirección IP en una interfaz Frame Relay multipunto. Esto se debe a que las subinterfaces multipunto (sub)de 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 de 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 a través de 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) utilice el DLCI local, 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 difusiones cuando la multidifusión no está habilitada, y simplifica la configuración de OSPF (Open Shortest Path First) para redes sin broadcast que utilizan Frame Relay.
La palabra clave broadcast también puede ser necesaria para algunos protocolos de ruteo, por ejemplo, AppleTalk, que dependen de actualizaciones regulares de la tabla de ruteo, especialmente cuando el router en el extremo remoto está esperando que llegue un paquete de actualización de ruteo antes de agregar la ruta.
Al requerir la selección de un router designado, OSPF trata una red de acceso múltiple sin broadcast, como Frame Relay de la misma manera que trata una red de broadcast. En versiones anteriores, esto requería una asignación manual 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 a través de la red Frame Relay como una red de difusión. (Vea el comando ip ospf network interface para obtener más detalles.)
Nota: El mecanismo de difusión 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 actualizaciones.
Reconfiguración de una subinterfaz
Una vez creado un tipo específico de subinterfaz, no puede cambiarlo 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. Esta es la forma en que 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 solo link físico, con una dirección de 10 bits. Debido a que ciertos DLCI están reservados (depende de la implementación del proveedor), el máximo es de aproximadamente 1000. El intervalo para una LMI de Cisco es de 16-1007. El intervalo establecido para ANSI/ITU es de 16-992. Estos son los DLCI que transportan 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 descriptores de interfaz (IDB) que admite su versión de Cisco IOS. Una 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áximas 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 plataformas de software de Cisco IOS: límites IDB.
Actualización del estado de LMI
El protocolo LMI requiere que todos los informes sobre el estado del circuito virtual permanente (PVC) formen un solo paquete y, en general, restringe el número de DLCI a menos de 800, en función del tamaño de la unidad máxima de transmisión (MTU).
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 admitir 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 se incrementa el contador gigante de la interfaz. Cuando cambie 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 la plataforma de DLCI máximos por router (no interfaz), basadas en la extrapolación de datos empíricos establecidos en una plataforma de router Cisco 7000:
-
Cisco 2500: 1 enlace T1/E1 a 60 DLCI por interfaz = 60 en total
-
Cisco 4000: 1 enlace T1/E1 a 120 DLCI por interfaz = 120 en total
-
Cisco 4500: 3 enlaces T1/E1 a 120 DLCI por interfaz = 360 en total
-
Cisco 4700: 4 enlaces T1/E1 a 120 DLCI por interfaz = 480 en total
-
Cisco 7000: 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 asumen que todo el tráfico es de conmutación rápida.
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. Protocolos de ruteo dinámico y otros protocolos como IPX SAP que intercambian tablas de bases de datos, envían saludos y reenvían 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 sola interfaz Frame Relay.
Dirección IP/IPX/AT
Si está utilizando 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 no funcione correctamente, siga estos pasos:
-
Desactive el protocolo de resolución de dirección inversa (ARP) para ese DLCI mediante los comandos no frame-relay inverse-arp ip 16 y clear frame-relay-inarp.
-
Corrija su configuración.
-
Vuelva a activar el comando frame-relay inverse-arp.
RIP y IGRP
Las actualizaciones del protocolo de información de enrutamiento (RIP) fluyen cada 30 segundos. Cada paquete RIP puede contener hasta 25 entradas de ruta, con un total de 536 bytes; 36 bytes de este total son información de encabezado y cada entrada de ruta tiene 20 bytes. Por lo tanto, si anuncia 1000 rutas a través de 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 por ciento del ancho de banda, con una duración de actualización de 5.6 segundos. Esta cantidad de sobrecarga es considerable y limita con lo aceptable, pero la velocidad de información comprometida (CIR) tendría que estar en la región de la velocidad de acceso. Obviamente, cualquier cosa menos que un T1 incurriría en 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 de 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
El protocolo de routing de gateway interior (IGRP) actualiza el flujo cada 90 segundos (este intervalo se puede configurar). Cada paquete IGRP puede contener 104 entradas de ruta, para un total de 1492 bytes, 38 de los cuales son información de encabezado, y cada entrada de ruta es 14 bytes. Si anuncia 1000 rutas a través de un link de Frame Relay configurado con 50 DLCI, la solicitud es de 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 por ciento del ancho de banda, con una 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 de 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 se puede configurar). 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 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 se puede configurar). Cada paquete IPX RIP puede contener hasta 50 entradas de ruta para un total de 536 bytes, 38 bytes de información de encabezado y cada entrada de ruta es de 8 bytes. Si anuncia 1000 rutas IPX a través de un link Frame Relay configurado para 50 DLCI, el resultado es 536 KB de actualizaciones IPX cada 60 segundos, o 58.4 kbps de ancho de banda consumido. Para permanecer dentro de 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 del punto de acceso al servicio IPX (SAP) se producen cada 60 segundos (este intervalo se puede configurar). 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 tiene 64 bytes. Si difunde 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 58.4 kbps de ancho de banda consumido. Para permanecer dentro de un nivel aceptable de sobrecarga (15% o menos), se requiere una velocidad superior a 2 Mbps. Obviamente, el filtrado de SAP es necesario en esta situación. En comparación con todos los demás protocolos mencionados en esta sección, las actualizaciones 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, el keepalive en el dispositivo de Cisco debe ser configurado un poco más corto (aproximadamente 8 segundos) que el keepalive en el switch. Verá la necesidad de esto si la interfaz sigue subiendo y bajando.
Interfaces en serie
Las interfaces seriales, que son de forma predeterminada multipunto, son medios de no difusión, mientras que las subinterfaces punto a punto son de difusión. Si está utilizando rutas estáticas, puede apuntar al salto siguiente o a 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 esta es una interfaz de difusión para que OSPF funcione.
OSPF y multipunto
OSPF y multipunto pueden ser muy problemáticos. OSPF necesita un router designado (DR). Si comienza a perder PVC, algunos routers pueden perder conectividad e intentar convertirse en un DR aunque otros routers aún vean el DR antiguo. Esto hace que el proceso OSPF funcione mal.
La sobrecarga asociada con OSPF no es tan obvia y predecible como la de los protocolos de ruteo de vectores 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 los paquetes de saludo de vecino (keepalives) fluirán, lo que es comparativamente mucho menos sobrecarga que la incurrida 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 intensivo del procesador cuando ejecuta el algoritmo Dijkstra, que se utiliza para calcular rutas.
En las versiones anteriores del software Cisco IOS, se debía tener especial cuidado al configurar OSPF en medios de no difusión 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 difusión (NBMA) suelen estar integradas en una topología de hub y spoke. Los PVC o los circuitos virtuales conmutados (SVC) están dispuestos en una malla parcial y la topología física no proporciona el multiacceso 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 como DR y un router como router designado de respaldo (BDR) en cada segmento de acceso múltiple. Se elige el BDR como mecanismo de respaldo en caso de que falle el DR.
La idea detrás de esta configuración es que los routers 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 una 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 que se convierten en DR o BDR en la nube de no difusión. El método que se debe utilizar depende de si la red es nueva o de un diseño existente que debe modificarse.
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 split horizon 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 como un conjunto de links punto a punto en lugar de una red multiacceso. El único inconveniente del punto a punto es que cada segmento pertenece a una subred diferente. Este escenario 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 puede ser un problema para algunos administradores que administran la WAN en función de las direcciones IP de las líneas seriales.
Fuentes
-
Comité Consultivo Internacional de Telégrafos y Telefonía, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", Recomendación Q.922 del CCITT, 19 de abril de 1991.
-
Norma Nacional Estadounidense para Telecomunicaciones - Red Digital de Servicios Integrados - Aspectos básicos del protocolo de tramas para su uso con el servicio portador de Frame Relay, ANSI T1.618-1991, 18 de junio de 1991.
-
Tecnología de la información - Telecomunicaciones e intercambio de información entre sistemas - Identificación de protocolos en la capa de red, ISO/IEC TR 9577: 1990 (E) 1990-10-15.
-
Norma Internacional, Sistemas de Procesamiento de Información - Redes de Área Local - Control de Enlace Lógico, ISO 8802-2: 1989 (E), IEEE Std 802.2-1989, 1989-12-31.
-
Descripción general de la tecnología de interconexión, octubre de 1994, Cisco Systems
-
Finlayson, R., Mann, R., Mogul, J., y M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, Stanford University, junio de 1984.
-
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.
-
Frame Relay Forum (FRF) 1.1-User-Network Interface (UNI)
-
FRF 2.1-Frame Relay Network-to-Network Interface (NNI)
-
FRF 3.1-Encapsulación multiprotocolo
-
FRF 4-SVC
-
FRF 6-Frame Relay service customer network management (MIB)
-
Banda de cuatro LMI
-
Q.922 Anexo A
-
ANSI T1.617 Annex D
-
ANSI T1.618, T1.606
-
ITU-T Q.933, Q.922
-
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 Dial-Backup
- Más información sobre los comandos de depuración ISDN
- Más información sobre los comandos de depuración PPP
- Más información sobre tipos, códigos y valores de switches ISDN
- Soporte Técnico y Documentación - Cisco Systems
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)