Contents
Introduction
O Frame Relay é um protocolo DDL padrão comutado que manipula vários circuitos virtuais usando um encapsulamento de High-Level Data Link Control (HDLC) entre os dispositivos conectados. Em muitos casos, o Frame Relay é mais eficiente do que o X.25, o protocolo para o qual geralmente se considera uma substituição. A seguinte figura ilustra um quadro do Frame Relay (ANSI T1.618).
Observação na figura acima, os endereços Q.922, como definidos atualmente, são dois octetos e contêm um identificador de conexão de enlace de dados (DLCI) de 10 bits. Em algumas redes, os endereços Q.922 podem, opcionalmente, ser aumentados para três ou quatro octetos.
Os campos "flag" delimitam o início e o fim do quadro. Seguindo o campo "flag" inicial estão dois bytes de informações de endereço. Dez bits desses dois bytes compõem o ID do circuito real (chamado DLCI, para identificador de conexão de enlace de dados).
O valor DLCI de 10 bits é o coração do cabeçalho do Frame Relay. Ele identifica a conexão lógica que é multiplexada no canal físico. No modo básico de endereçamento (ou seja, não estendido pela LMI [Local Management Interface Interface de Gerenciamento Local]), os DLCIs têm significado local; ou seja, os dispositivos finais em duas extremidades diferentes de uma conexão podem usar um DLCI diferente para se referir a essa mesma conexão.
Antes de Começar
Conventions
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Prerequisites
Para obter mais informações e definições para os termos usados neste documento, consulte o Glossário do Frame Relay.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.
Material de Suporte
O Frame Relay foi originalmente concebido como um protocolo para uso em interfaces ISDN. As primeiras propostas para esse efeito foram apresentadas ao ITU-T (International Telecommunication Union Telecommunications Standardization Setor, Setor de Padronização de Telecomunicações da União Internacional de Telecomunicações) (antigo Comitê Consultivo para Telégrafo Internacional e Telefonia [CCITT]) em 1984. O trabalho no Frame Relay também foi realizado no comitê de padrões T1S1 acreditado pela ANSI nos Estados Unidos.
Em 1990, a Cisco Systems, a StrataCom, a Northern Telecom e a Digital Equipment Corporation formaram um consórcio para concentrar o desenvolvimento da tecnologia Frame Relay e acelerar a introdução de produtos Frame Relay interoperáveis. Eles desenvolveram uma especificação de acordo com o protocolo básico do Frame Relay discutido em T1S1 e ITU-T, mas a ampliaram com recursos que fornecem recursos adicionais para ambientes complexos de interconexão de redes. Essas extensões do Frame Relay são chamadas coletivamente de LMI. Esta é a LMI "cisco" no roteador, ao contrário da LMI "ansi" ou "q933a".
O Frame Relay fornece um recurso de comunicação de dados de comutação de pacotes que é usado na interface entre os dispositivos do usuário (como roteadores, bridges, máquinas host) e o equipamento de rede (como nós de comutação). Os dispositivos do usuário são frequentemente chamados de DTE (Data Terminal Equipment, equipamento terminal de dados), enquanto os equipamentos de rede que fazem interface com DTE são frequentemente chamados de DCE (Data Circuit Terminating Equipment, equipamento terminal de circuito de dados). A rede que fornece a interface do Frame Relay pode ser uma rede pública fornecida pela operadora ou uma rede de equipamentos privados que atendem a uma única empresa.
O Frame Relay difere significativamente do X.25 em sua funcionalidade e formato. Em particular, o Frame Relay é um protocolo mais simplificado, facilitando um desempenho mais alto e uma maior eficiência.
Como uma interface entre o usuário e o equipamento de rede, o Frame Relay fornece um meio para multiplexar estatisticamente muitas conversas de dados lógicos (conhecidos como circuitos virtuais) sobre um único link de transmissão física. Isso contrasta com sistemas que usam apenas técnicas de multiplexação por divisão de tempo (TDM) para suportar vários fluxos de dados. A multiplexação estatística do Frame Relay oferece uso mais flexível e eficiente da largura de banda disponível. Ele pode ser usado sem técnicas TDM ou em cima dos canais fornecidos pelos sistemas TDM.
Outra característica importante do Frame Relay é que ele explora os recentes avanços na tecnologia de transmissão de rede de longa distância (WAN). Os protocolos de WAN anteriores, como o X.25, foram desenvolvidos quando os sistemas de transmissão analógica e os meios de cobre eram predominantes. Esses links são muito menos confiáveis do que os links de transmissão digital/mídia de fibra disponíveis atualmente. Em links como esses, os protocolos da camada de enlace podem renunciar a algoritmos demorados de correção de erros, deixando que esses sejam executados em camadas de protocolo mais altas. Assim, é possível obter mais desempenho e eficiência sem sacrificar a integridade dos dados. O Frame Relay foi projetado pensando nessa abordagem. Ele inclui um algoritmo de verificação de redundância cíclica (CRC - Cyclic Redundancy Check) para a detecção de bits corrompidos (de modo que os dados possam ser descartados), mas não inclui nenhum mecanismo de protocolo para a correção de dados incorretos (por exemplo, retransmitindo-os nesse nível de protocolo).
Outra diferença entre Frame Relay e X.25 é a ausência de controle de fluxo explícito por circuito virtual no Frame Relay. Agora que muitos protocolos de camada superior estão efetivamente executando seus próprios algoritmos de controle de fluxo, a necessidade dessa funcionalidade na camada de enlace diminuiu. O Frame Relay, portanto, não inclui procedimentos explícitos de controle de fluxo que duplicam os nas camadas superiores. Em vez disso, são fornecidos mecanismos muito simples de notificação de congestionamento para permitir que uma rede informe a um dispositivo de usuário que os recursos da rede estão próximos de um estado congestionado. Essa notificação pode alertar os protocolos de camada superior de que o controle de fluxo pode ser necessário.
Configurando Frame Relay básico
Quando você tiver conexões confiáveis com o switch local do Frame Relay em ambas as extremidades do circuito virtual permanente (PVC), é hora de começar a planejar a configuração do Frame Relay. Neste primeiro exemplo, o padrão do tipo de LMI (Local Management Interface, interface de gerenciamento local) é "cisco" LMI em Spicey. Uma interface é, por padrão, uma interface "multiponto", portanto, frame-relay inverse-arp está ativado (para point-to-point, não há ARP inverso). A verificação do split horizon IP é desativada por padrão para o encapsulamento do Frame Relay, de modo que as atualizações de roteamento entram e saem da mesma interface. Os roteadores aprendem os DLCIs (Data-Link Connection Identifiers Identificadores de Conexão de Enlace de Dados) que precisam usar a partir do switch Frame Relay através de atualizações de LMI. Os roteadores, então, Inverse ARP para o endereço IP remoto e criam um mapeamento de DLCIs locais e seus endereços IP remotos associados.
Diagrama de Rede
Configurações
| 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 e show
Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.
-
show frame-relay map
-
show frame-relay pvc
-
show frame-relay lmi
-
ping <nome do dispositivo>
-
show ip route
Spicey
Spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 83 output pkts 87 in bytes 8144
out bytes 8408 dropped pkts 0 in FECN pkts0
in BECN pkts 0 out FECN pkts 0 out BECN pkts0
in DE pkts 0 out DE pkts 0
out bcast pkts 41 out bcast bytes 3652
pvc create time 01:31:50, last time pvc status changed 01:28:28
Spicey#show frame-relay lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 550 Num Status msgs Rcvd 552
Num Update Status Rcvd 0 Num Status Timeouts 0
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial0
124.0.0.0/24 is subnetted, 1 subnets
C 124.124.124.0 is directly connected, Ethernet0
R 123.0.0.0/8 [120/1] via 3.1.3.2, 00:00:08, Serial0
Prasit
Prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 87 output pkts 83 in bytes 8408
out bytes 8144 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 38 out bcast bytes 3464
pvc create time 01:34:29, last time pvc status changed 01:28:05
Prasit#show frame-relay lmi
LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 569 Num Status msgs Rcvd 570
Num Update Status Rcvd 0 Num Status Timeouts 0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial1
R 124.0.0.0/8 [120/1] via 3.1.3.1, 00:00:19, Serial1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Configurando Frame Relay do tipo “hub and spoke”
Neste exemplo, o roteador aprende quais DLCIs (data-link connection identifiers, identificadores de conexão de enlace de dados) usa do switch Frame Relay e os atribui à interface principal. Em seguida, o roteador fará o Inverse ARP para o endereço IP remoto.
Observação: você não poderá fazer ping do endereço IP serial de Prasit a partir da Aton, a menos que você adicione explicitamente os mapas de Frame Relay em cada extremidade. Se o roteamento estiver configurado corretamente, o tráfego originado nas LANs não deverá ter um problema. Você poderá fazer ping se usar o endereço IP Ethernet como o endereço origem em um ping estendido.
Quando frame-relay inverse-arp está ativado, o tráfego de IP de broadcast sairá pela conexão por padrão.
Diagrama de Rede
Configurações
| Spicey |
|---|
spicey#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname spicey ! ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 3.1.3.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 130 frame-relay interface-dlci 140 ! ! router rip network 3.0.0.0 network 124.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
prasit#show running-config Building configuration... Current configuration : 1499 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 150 ! ! router rip network 3.0.0.0 network 123.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Aton |
|---|
aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname aton ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.3 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 160 ! router rip network 3.0.0.0 network 122.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
comandos show
-
show frame-relay map
-
show frame-relay pvc
-
ping <nome do dispositivo>
Spicey
spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,
broadcast,, status defined, active
spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 32 output pkts 40 in bytes 3370
out bytes 3928 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 30 out bcast bytes 2888
pvc create time 00:15:46, last time pvc status changed 00:10:42
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 282 output pkts 291 in bytes 25070
out bytes 27876 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 223 out bcast bytes 20884
pvc create time 02:28:36, last time pvc status changed 02:25:14
spicey#
spicey#ping 3.1.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
spicey#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Prasit
prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 311 output pkts 233 in bytes 28562
out bytes 22648 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 162 out bcast bytes 15748
pvc create time 02:31:39, last time pvc status changed 02:25:14
prasit#ping 3.1.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
prasit#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Aton
aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
broadcast,, status defined, active
aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 35 output pkts 32 in bytes 3758
out bytes 3366 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 27 out bcast bytes 2846
pvc create time 00:10:53, last time pvc status changed 00:10:53
aton#ping 3.1.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
aton#ping 3.1.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Conectando-se de raio para raio
Você não pode fazer ping de um spoke para outro em uma configuração de hub e spoke usando interfaces multiponto porque não há mapeamento para os endereços IP dos outros spokes. Somente o endereço do hub é aprendido através do Inverse Address Resolution Protocol (IARP). Se você configurar um mapa estático usando o comando frame-relay map para o endereço IP de um spoke remoto para usar o DLCI (Data Link Connection Identifier Identificador de Conexão de Enlace de Dados) local, poderá fazer ping nos endereços de outros spokes.
Configurações
| 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 <nome do dispositivo>
-
show running-config
Prasit
prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Serial1 (up): ip 3.1.3.3 dlci 150(0x96,0x2460), static,
CISCO, status defined, active
prasit#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/80 ms
prasit#ping 122.122.122.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/76 ms
Aton
aton#show running-config
interface Ethernet0
ip address 122.122.122.1 255.255.255.0
!
interface Serial1
ip address 3.1.3.3 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
frame-relay map ip 3.1.3.2 160
frame-relay interface-dlci 160
aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
broadcast,, status defined, active
Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,
CISCO, status defined, active
aton#ping 3.1.3.2
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
aton#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/80 ms
Configurando subinterfaces de frame relay
As subinterfaces do Frame Relay fornecem um mecanismo para suportar redes de Frame Relay parcialmente em malha. A maioria dos protocolos assume transitividade em uma rede lógica; ou seja, se a estação A pode falar com a estação B, e a estação B pode falar com a estação C, então a estação A deve ser capaz de falar diretamente com a estação C. A transitividade é verdadeira em LANs, mas não em redes Frame Relay, a menos que A esteja diretamente conectado a C.
Além disso, certos protocolos, como AppleTalk e bridging transparente, não podem ser suportados em redes parcialmente em malha porque exigem "split horizon" no qual um pacote recebido em uma interface não pode ser transmitido pela mesma interface, mesmo que o pacote seja recebido e transmitido em circuitos virtuais diferentes.
A configuração de subinterfaces de Frame Relay garante que uma única interface física seja tratada como várias interfaces virtuais. Esse recurso nos permite superar regras de split horizon. Os pacotes recebidos em uma interface virtual agora podem ser encaminhados por outra interface virtual, mesmo que estejam configurados na mesma interface física.
As subinterfaces lidam com as limitações das redes Frame Relay, fornecendo uma maneira de subdividir uma rede Frame Relay parcialmente em malha em um número de sub-redes menores, totalmente em malha (ou ponto a ponto). Cada sub-rede recebe seu próprio número de rede e aparece aos protocolos como se fosse alcançável por meio de uma interface separada. (Observe que as subinterfaces ponto-a-ponto podem não ser numeradas para uso com IP, reduzindo a carga de endereçamento que poderia resultar de outra forma).
Subinterfaces de ponto a ponto
Diagrama de Rede
Configurações
| 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 e Spoke
A seguinte configuração de exemplo de hub e spoke mostra duas subinterfaces ponto a ponto e usa a resolução de endereço dinâmico em um local remoto. Cada subinterface é fornecida com um endereço de protocolo individual e uma máscara de sub-rede, e o comando interface-dlci associa a subinterface a um DLCI (data-link connection identifier, identificador de conexão de link de dados) especificado. Os endereços de destinos remotos para cada subinterface ponto-a-ponto não são resolvidos, pois são ponto-a-ponto e o tráfego deve ser enviado ao peer na outra extremidade. A extremidade remota (Aton) usa o ARP inverso para seu mapeamento e o hub principal responde de acordo com o endereço IP da subinterface. Isso ocorre porque o ARP inverso do Frame Relay está ativado por padrão para interfaces multiponto.
Diagrama de Rede
Configurações
| Spicey |
|---|
Spicey#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 4.0.1.1 255.255.255.0 frame-relay interface-dlci 140 ! interface Serial0.2 point-to-point ip address 3.1.3.1 255.255.255.0 frame-relay interface-dlci 130 ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 124.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point ip address 4.0.1.2 255.255.255.0 frame-relay interface-dlci 150 ! router igrp 2 network 4.0.0.0 network 123.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Aton |
|---|
Aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime ! hostname Aton ! ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.3 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 160 ! router igrp 2 network 3.0.0.0 network 122.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
comandos show
-
show frame-relay map
-
show frame-relay pvc
Spicey
Spicey#show frame-relay map
Serial0.2 (up): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
status defined, active
Serial0.1 (up): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.2
input pkts 11 output pkts 22 in bytes 1080
out bytes 5128 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 17 out bcast bytes 4608
pvc create time 00:06:36, last time pvc status changed 00:06:36
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1
input pkts 33 output pkts 28 in bytes 3967
out bytes 5445 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 17 out bcast bytes 4608
pvc create time 00:06:38, last time pvc status changed 00:06:38
Spicey#ping 122.122.122.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit
Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 45 output pkts 48 in bytes 8632
out bytes 6661 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 31 out bcast bytes 5573
pvc create time 00:12:16, last time pvc status changed 00:06:23
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Aton
Aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
broadcast,, status defined, active
Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 699 output pkts 634 in bytes 81290
out bytes 67008 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 528 out bcast bytes 56074
pvc create time 05:46:14, last time pvc status changed 00:05:57
Aton#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Configurando os mapeamentos dinâmico e estático para subinterfaces multiponto
O mapeamento dinâmico de endereços usa o ARP inverso do Frame Relay para solicitar o endereço do protocolo do próximo salto para uma conexão específica, com um identificador de conexão de enlace de dados (DLCI). As respostas às solicitações do Inverse ARP são inseridas em uma tabela de mapeamento de endereço para DLCI no roteador ou no servidor de acesso; a tabela é então usada para fornecer o endereço do protocolo do próximo salto ou o DLCI para tráfego de saída.
Como a interface física agora está configurada como várias subinterfaces, você deve fornecer informações que distingam uma subinterface da interface física e associam uma subinterface específica a um DLCI específico.
O ARP inverso é ativado por padrão para todos os protocolos suportados, mas pode ser desativado para pares específicos de protocolo DLCI. Como resultado, você pode usar o mapeamento dinâmico para alguns protocolos e o mapeamento estático para outros protocolos no mesmo DLCI. Você pode desativar explicitamente o ARP inverso para um par de protocolo-DLCI se souber que o protocolo não é suportado na outra extremidade da conexão. Como o ARP inverso é ativado por padrão para todos os protocolos suportados, nenhum comando adicional é necessário para configurar o mapeamento dinâmico de endereços em uma subinterface. Um mapa estático vincula um endereço de protocolo de próximo salto especificado a um DLCI especificado. O mapeamento estático elimina a necessidade de solicitações ARP inverso; quando você fornece um mapa estático, o ARP inverso é automaticamente desabilitado para o protocolo especificado no DLCI especificado. Você deve usar o mapeamento estático se o roteador na outra extremidade não suportar ARP inverso ou não suportar ARP inverso para um protocolo específico que você deseja usar no Frame Relay.
Diagrama de Rede
Já vimos como configurar um roteador Cisco para fazer ARP inverso. O exemplo a seguir mostra como configurar mapas estáticos caso você precise deles para interfaces ou subinterfaces multiponto:
Configurações
| Aton |
|---|
Aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Aton ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 multipoint ip address 4.0.1.3 255.255.255.0 frame-relay map ip 4.0.1.1 160 broadcast ! router igrp 2 network 4.0.0.0 network 122.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Spicey |
|---|
Spicey#show running-config Building configuration...Current configuration : 1652 bytes! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 4.0.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 4.0.1.2 140 broadcast frame-relay map ip 4.0.1.3 130 broadcast ! router igrp 2 network 4.0.0.0 network 124.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1162 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 multipoint ip address 4.0.1.2 255.255.255.0 frame-relay map ip 4.0.1.1 150 broadcast ! router igrp 2 network 4.0.0.0 network 123.0.0.0 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
comandos debug e show
-
show frame-relay map
-
show frame-relay pvc
Aton
Aton#show frame-relay map
Serial1.1 (up): ip 4.0.1.1 dlci 160(0xA0,0x2800), static, broadcast,
CISCO, status defined, active
Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial1.1
input pkts 16 output pkts 9 in bytes 3342
out bytes 450 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 9 out bcast bytes 450
pvc create time 00:10:02, last time pvc status changed 00:10:02
Aton#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Spicey
Spicey#show frame-relay map
Serial0 (up): ip 4.0.1.2 dlci 140(0x8C,0x20C0), static, broadcast,
CISCO, status defined, active
Serial0 (up): ip 4.0.1.3 dlci 130(0x82,0x2020), static, broadcast,
CISCO, status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 9 output pkts 48 in bytes 434
out bytes 11045 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 48 out bcast bytes 11045
pvc create time 00:36:25, last time pvc status changed 00:36:15
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 17 output pkts 26 in bytes 1390
out bytes 4195 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 16 out bcast bytes 3155
pvc create time 00:08:39, last time pvc status changed 00:08:39
Spicey#ping 122.122.122.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36
Prasit
Prasit#show frame-relay map
Serial1.1 (up): ip 4.0.1.1 dlci 150(0x96,0x2460), static,
broadcast,
CISCO, status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.1
input pkts 28 output pkts 19 in bytes 4753
out bytes 1490 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 9 out bcast bytes 450
pvc create time 00:11:00, last time pvc status changed 00:11:00
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Para obter mais informações sobre esses comandos, consulte Comandos do Frame Relay.
Configurando Frame Relay com IP não numerado
Se você não tiver o espaço de endereço IP para usar muitas subinterfaces, poderá usar IP não numerado em cada subinterface. Se for esse o caso, você precisará usar rotas estáticas ou roteamento dinâmico para que o tráfego seja roteado como de costume e deve usar subinterfaces ponto-a-ponto.
Diagrama de Rede
O exemplo abaixo ilustra isso:
Configurações
| 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
Configurando o backup do Frame Relay
Backup de frame relay sobre ISDN
Talvez você queira fazer backup dos circuitos do Frame Relay usando ISDN. Há várias maneiras de fazer isso. A primeira, e provavelmente a melhor, é usar rotas estáticas flutuantes que roteiam o tráfego para um endereço IP BRI (Basic Rate Interface, interface de taxa básica) e usar uma métrica de roteamento apropriada. Você também pode usar uma interface de backup na interface principal ou em uma base por DLCI (data-link connection identifier, identificador de conexão de link de dados). Pode ser pouco útil fazer backup da interface principal porque você pode perder PVCs (Permanent Virtual Circuits, circuitos virtuais permanentes) sem que a interface principal seja desativada. Lembre-se, o protocolo está sendo trocado com o switch Frame Relay local, não com o roteador remoto.
Configurações
| Roteador 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 ! |
| Roteador 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 se a ISDN está funcionando, use os seguintes comandos debug. Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.
-
debug isdn q931
-
debug ppp neg
-
debug ppp auth
Tente fazer uma chamada ISDN do lado da chamada para o lado central sem os comandos de backup. Se isso for bem-sucedido, adicione os comandos de backup ao lado da chamada.
Observação: para testar o backup, não use o comando shutdown na interface serial, mas emule um problema de linha serial real puxando o cabo da linha serial.
Configuração por backup de DCLI
Agora vamos supor que Spicey é o lado central e que Prasit é o lado fazendo conexões com o lado central (Spicey). Certifique-se de adicionar apenas os comandos de backup ao lado que está chamando o lado central.
Observação: a carga de backup não é suportada em subinterfaces. Como não rastreamos os níveis de tráfego em subinterfaces, nenhuma carga é calculada.
Diagrama de Rede
Configurações
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1438 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! username Prasit password 0 cisco ! ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 4.0.1.1 255.255.255.0 frame-relay interface-dlci 140 ! interface BRI0 ip address 3.1.6.1 255.255.255.0 encapsulation ppp dialer map ip 3.1.6.2 name Prasit broadcast dialer-group 1 isdn switch-type basic-net3 no peer default ip address no cdp enable ppp authentication chap ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 124.0.0.0 ! ip classless ip route 123.123.123.0 255.255.255.0 3.1.6.2 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1245 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! username Spicey password 0 cisco ! ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point backup delay 5 10 backup interface BRI0 ip address 4.0.1.2 255.255.255.0 frame-relay interface-dlci 150 ! interface BRI0 ip address 3.1.6.2 255.255.255.0 encapsulation ppp dialer map ip 3.1.6.1 name Spicey broadcast 6106 dialer-group 1 isdn switch-type basic-net3 ppp authentication chap ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 123.0.0.0 ! ip route 124.124.124.0 255.255.255.0 3.1.6.1 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
comandos show
-
show frame-relay map
-
show ip route
-
show isdn history
-
show isdn status
-
show interface bri 0
-
show isdn ative
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
A linha serial cai.
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#
A conexão serial está novamente.
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
Concentrador e ponto remoto com perfis de discagem
Aqui está um exemplo de uma configuração de backup de hub e spoke por DLCI. Os roteadores spoke estão chamando o roteador hub. Como você pode ver, permitimos apenas um canal B por lado usando a opção max-link no conjunto de discadores no lado do hub.
Observação: a carga de backup não é suportada em subinterfaces. Como não rastreamos os níveis de tráfego em subinterfaces, nenhuma carga é calculada.
Diagrama de Rede
Configurações
| Aton |
|---|
Aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Aton ! ! username Spicey password 0 cisco ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point ip address 3.1.3.3 255.255.255.0 backup delay 5 10 backup interface BRI0 frame-relay interface-dlci 160 ! interface BRI0 ip address 155.155.155.3 255.255.255.0 encapsulation ppp no ip route-cache no ip mroute-cache dialer map ip 155.155.155.2 name Spicey broadcast 6106 dialer-group 1 isdn switch-type basic-net3 ppp authentication chap ! router igrp 2 network 3.0.0.0 network 122.0.0.0 network 155.155.0.0 ! ip route 124.124.124.0 255.255.255.0 155.155.155.2 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Spicey |
|---|
Spicey#show running-config Building configuration... Current configuration : 1887 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! username Prasit password 0 cisco username Aton password 0 cisco ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 no ip address encapsulation frame-relay ! interface Serial0.1 point-to-point ip address 4.0.1.1 255.255.255.0 frame-relay interface-dlci 140 ! interface Serial0.2 point-to-point ip address 3.1.3.1 255.255.255.0 frame-relay interface-dlci 130 ! interface BRI0 no ip address encapsulation ppp no ip route-cache no ip mroute-cache dialer pool-member 2 max-link 1 dialer pool-member 1 max-link 1 isdn switch-type basic-net3 no peer default ip address no cdp enable ppp authentication chap ! interface Dialer1 ip address 160.160.160.1 255.255.255.0 encapsulation ppp no ip route-cache no ip mroute-cache dialer pool 1 dialer remote-name Prasit dialer-group 1 ppp authentication chap ! interface Dialer2 ip address 155.155.155.2 255.255.255.0 encapsulation ppp no ip route-cache no ip mroute-cache dialer pool 2 dialer remote-name Aton dialer-group 1 ppp authentication chap ! router igrp 2 network 3.0.0.0 network 4.0.0.0 network 124.0.0.0 network 155.155.0.0 network 160.160.0.0 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1267 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! username Spicey password 0 cisco ! isdn switch-type basic-net3 ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 no ip address encapsulation frame-relay ! interface Serial1.1 point-to-point backup delay 5 10 backup interface BRI0 ip address 4.0.1.2 255.255.255.0 frame-relay interface-dlci 150 ! interface BRI0 ip address 160.160.160.2 255.255.255.0 encapsulation ppp dialer map ip 160.160.160.1 name Spicey broadcast 6106 dialer-group 1 isdn switch-type basic-net3 ppp authentication chap ! router igrp 2 network 4.0.0.0 network 123.0.0.0 network 160.160.0.0 ! ip route 124.124.124.0 255.255.255.0 160.160.160.1 250 ! access-list 101 deny igrp any any access-list 101 permit ip any any dialer-list 1 protocol ip list 101 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
comandos show
-
show frame-relay map
-
show ip route
-
show frame map
-
show frame-relay pvc
Aton
Aton#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 160(0xA0,0x2800), broadcast
status defined, active
Aton#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Aton#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route
Gateway of last resort is not set
I 155.155.0.0/16 [100/182571] via 3.1.3.1, Serial1.1
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial1.1
I 4.0.0.0/8 [100/10476] via 3.1.3.1, Serial1.1
I 160.160.0.0/16 [100/182571] via 3.1.3.1, Serial1.1
124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S 124.124.124.0/24 [250/0] via 155.155.155.2
I 124.0.0.0/8 [100/8576] via 3.1.3.1, Serial1.1
I 123.0.0.0/8 [100/10576] via 3.1.3.1, Serial1.1
122.0.0.0/24 is subnetted, 1 subnets
C 122.122.122.0 is directly connected, Ethernet0
Aton#
Serial 1 está caindo.
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 torna-se ativo novamente
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 as linhas seriais dos lados da chamada estão ficando inoperantes.
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#
As duas linhas seriais estão disponíveis novamente.
Spicey#show frame pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial0.2
input pkts 54 output pkts 61 in bytes 7014
out bytes 9975 dropped pkts 3 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 40 out bcast bytes 7803
pvc create time 01:28:14, last time pvc status changed 00:02:38
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE =
Serial0.1
input pkts 56 output pkts 60 in bytes 7604
out bytes 10114 dropped pkts 2 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 39 out bcast bytes 7928
pvc create time 01:28:15, last time pvc status changed 00:02:29
Prasit
Prasit#show frame-relay map
Serial1.1 (up): point-to-point dlci, dlci 150(0x96,0x2460), broadcast
status defined, active
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
I 155.155.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1
I 3.0.0.0/8 [100/10476] via 4.0.1.1, 00:00:41, Serial1.1
4.0.0.0/24 is subnetted, 1 subnets
C 4.0.1.0 is directly connected, Serial1.1
I 160.160.0.0/16 [100/182571] via 4.0.1.1, 00:00:41, Serial1.1
124.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S 124.124.124.0/24 [250/0] via 160.160.160.1
I 124.0.0.0/8 [100/8576] via 4.0.1.1, 00:00:41, Serial1.1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
I 122.0.0.0/8 [100/10576] via 4.0.1.1, 00:00:42, Serial1.1
Prasit#
Serial 1 desliga.
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 torna-se ativo novamente.
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
Configuração de switching do frame relay
A comutação Frame Relay é um meio de comutação de pacotes com base no DLCI (Data-Link Connection Identifier Identificador de Conexão de Enlace de Dados). Podemos considerar isso como o equivalente do Frame Relay de um endereço de Controle de Acesso ao Meio (MAC - Media Access Control). Você executa a comutação configurando seu roteador ou servidor de acesso Cisco em uma rede Frame Relay. Há duas partes em uma rede Frame Relay:
-
Equipamento terminal de dados (DTE - Data Terminal Equipment) do Frame Relay - o roteador ou o servidor de acesso.
-
Switch de equipamento de terminação de circuito de dados (DCE) do Frame Relay.
Observação: no Cisco IOS Software Release 12.1(2)T ou posterior, o comando frame route foi substituído pelo comando connect.
Vamos ver um exemplo de configuração. Na configuração abaixo, estamos usando o roteador América como um switch Frame Relay. Estamos usando o Spicey como um roteador de hub e o Prasit e o Aton como roteadores de spoke. Nós os conectamos da seguinte maneira:
-
O DTE serial 1 (s1) da Prasit está conectado ao DCE serial 1/4 (s1/4) da América.
-
O DTE serial 0 (s0) da amostra está conectado ao DCE serial 1/5 (s1/5) da América.
-
O Aton serial 1 (s1) DTE está conectado ao DCE serial 3/4 (s3/4) da América.
Diagrama de Rede
Este documento é baseado na seguinte configuração:
Configurações
| Spicey |
|---|
Spicey#show running-config Building configuration... ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Spicey ! ! ! interface Ethernet0 ip address 124.124.124.1 255.255.255.0 ! interface Serial0 ip address 3.1.3.1 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 130 frame-relay interface-dlci 140 ! ! router rip network 3.0.0.0 network 124.0.0.0 ! line con 0 ! exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Prasit |
|---|
Prasit#show running-config Building configuration... Current configuration : 1499 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Prasit ! ! ! interface Ethernet0 ip address 123.123.123.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.2 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 150 ! ! router rip network 3.0.0.0 network 123.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| Aton |
|---|
Aton#show running-config Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Aton ! ! ! interface Ethernet0 ip address 122.122.122.1 255.255.255.0 ! interface Serial1 ip address 3.1.3.3 255.255.255.0 encapsulation frame-relay frame-relay interface-dlci 160 ! router rip network 3.0.0.0 network 122.0.0.0 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 login ! end |
| América |
|---|
america#show running-config Building configuration... Current configuration: ! ! service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname america ! frame-relay switching ! ! interface Serial1/4 description *** static DCE connection to s1 Prasit no ip address encapsulation frame-relay clockrate 2000000 frame-relay intf-type dce frame-relay route 150 interface Serial1/5 140 ! interface Serial1/5 description *** static DCE connection to s0 spicy no ip address encapsulation frame-relay bandwidth 1000000 tx-queue-limit 100 frame-relay intf-type dce frame-relay route 130 interface Serial3/4 160 frame-relay route 140 interface Serial1/4 150 transmitter-delay 10 ! interface Serial3/4 description *** static DCE connection to s1 Aton encapsulation frame-relay no ip mroute-cache clockrate 2000000 frame-relay intf-type dce frame-relay route 160 interface Serial1/5 130 ! |
comandos show
Use os seguintes comandos show para testar se sua rede está funcionando corretamente:
-
show frame-relay map
-
show frame-relay pvc
A saída mostrada abaixo é resultado da digitação desses comandos nos dispositivos que estamos usando nesta configuração de exemplo.
Spicey
Spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,
broadcast,, status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 32 output pkts 40 in bytes 3370
out bytes 3928 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 30 out bcast bytes 2888
pvc create time 00:15:46, last time pvc status changed 00:10:42
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 282 output pkts 291 in bytes 25070
out bytes 27876 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 223 out bcast bytes 20884
pvc create time 02:28:36, last time pvc status changed 02:25:14
Prasit
Prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 311 output pkts 233 in bytes 28562
out bytes 22648 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 162 out bcast bytes 15748
pvc create time 02:31:39, last time pvc status changed 02:25:14
Aton
Aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic, broadcast, status defined, active
Aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial
input pkts 35 output pkts 32 in bytes 3758
out bytes 3366 dropped pkts 0 in FECN pkt 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 27 out bcast bytes 2846
pvc create time 00:10:53, last time pvc status changed 00:10:53
Configurando a priorização DLCI do Frame Relay
A priorização de DLCI (Data-Link Connection Identifier) é o processo pelo qual diferentes tipos de tráfego são colocados em DLCIs separados para que uma rede Frame Relay possa fornecer uma taxa de informação comprometida diferente para cada tipo de tráfego. Ele pode ser usado em conjunto com enfileiramento personalizado ou enfileiramento de prioridade para fornecer controle de gerenciamento de largura de banda sobre o link de acesso à rede do Frame Relay. Além disso, alguns provedores de serviços do Frame Relay e switches Frame Relay (como os switches Stratacom Internetwork Packet Exchange [IPX], IGX e BPX ou AXIS) realmente fornecem priorização na nuvem do Frame Relay com base nessa configuração de prioridade.
Considerações de implementação
Ao implementar a priorização de DLCI, observe os seguintes pontos:
-
Se um DLCI secundário cair, você perderá o tráfego destinado apenas para essa fila.
-
Se você perder o DLCI principal, a subinterface será desativada e você perderá todo o tráfego.
Diagrama de Rede
Para usar essa configuração, você precisa ter quatro DLCIs para o lado que usará a priorização de DLCI. Neste exemplo, configuramos o Spicey para o enfileiramento de prioridade da seguinte maneira:
-
O ping está na fila de alta prioridade.
-
O Telnet está na fila de prioridade média.
-
O FTP está na fila de prioridade normal.
-
Todo o tráfego IP restante está na fila de baixa prioridade.
Observação: certifique-se de que você configure os DLCIs para corresponderem à lista de prioridades ou o sistema não usará a fila correta.
Configurações
| 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 e show
Use os seguintes comandos show e debug para testar se sua rede está funcionando corretamente. Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.
-
show frame-relay pvc
-
show frame-relay map
-
show queueing priority
-
debug priority
A saída mostrada abaixo é resultado da digitação desses comandos nos dispositivos que estamos usando nesta configuração de exemplo.
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 a fila de prioridade, use o 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:
Outro tráfego IP passa pela fila baixa.
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#
Aqui está a saída de depuração mostrada no Spicey quando você usa o comando acima para executar telnet para Spicey a partir do 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)
Fila de transmissão do Frame Relay
A fila de broadcast é um recurso principal usado em redes IP ou IPX de médio a grande porte em que os broadcasts de roteamento e ponto de acesso de serviço (SAP) devem fluir pela rede Frame Relay. A fila de broadcast é gerenciada independentemente da fila de interface normal, tem seus próprios buffers e tem um tamanho configurável e uma taxa de serviço. Essa fila de broadcast não é usada para atualizações de spanning tree (BPDUs) de bridging devido a sensibilidades de temporização. Esses pacotes fluirão pelas filas normais. O comando de interface para ativar a fila de broadcast é o seguinte:
frame-relay broadcast-queue size byte-rate packet-rate
Uma fila de broadcast recebe um limite máximo de taxa de transmissão (throughput) medido em bytes por segundo e pacotes por segundo. A fila é servida para garantir que apenas esse máximo seja fornecido. A fila de broadcast tem prioridade ao transmitir a uma taxa abaixo do máximo configurado e, portanto, tem uma alocação de largura de banda mínima garantida. Os dois limites de taxa de transmissão têm como objetivo evitar a inundação da interface com broadcasts. O limite real em qualquer segundo é o primeiro limite de taxa que é atingido. Dada a restrição da taxa de transmissão, é necessário um buffer adicional para armazenar pacotes de broadcast. A fila de broadcast é configurável para armazenar grandes números de pacotes de broadcast. O tamanho da fila deve ser definido para evitar a perda de pacotes de atualização de roteamento de broadcast. O tamanho exato depende do protocolo sendo usado e do número de pacotes necessários para cada atualização. Para ser seguro, o tamanho da fila deve ser definido de modo que uma atualização de roteamento completa de cada protocolo e para cada DLCI (Data-Link Connection Identifier, identificador de conexão de enlace de dados) possa ser armazenada. Como regra geral, comece com 20 pacotes por DLCI. A taxa de bytes deve ser menor do que ambas as seguintes:
-
N/4 vezes a taxa mínima de acesso remoto (medida em bytes por segundo), onde N é o número de DLCIs aos quais a transmissão deve ser replicada
-
1/4 da taxa de acesso local (medida em bytes por segundo)
A taxa de pacotes não é crítica se a taxa de bytes for definida de forma conservadora. Em geral, a taxa de pacotes deve ser definida supondo pacotes de 250 bytes. Os padrões para as interfaces seriais são 64 tamanhos de fila, 256.000 bytes por segundo (2.048.000 bps) e 36 pps. Os padrões para as interfaces seriais de alta velocidade (HSSI) são 256 tamanhos de fila, 1.024.000 bytes por segundo (8.192.000 bps) e 144 pps.
Modelagem de tráfego
A modelagem de tráfego usa um mecanismo de controle de taxa chamado de filtro de token bucket. Esse filtro de token bucket é definido da seguinte maneira:
intermitência em excesso mais intermitência comprometida (Bc + Be) = velocidade máxima do circuito virtual (VC)
O tráfego acima da velocidade máxima é colocado em buffer em uma fila de modelagem de tráfego que é igual ao tamanho da fila de espera ponderada (WFQ). O filtro Token Bucket não filtra o tráfego, mas controla a taxa na qual o tráfego é enviado na interface de saída. Para obter mais informações sobre os filtros de token bucket, consulte a Visão geral de policiamento e modelagem.
Este documento fornece uma visão geral da modelagem de tráfego genérico e da modelagem de tráfego do Frame Relay.
Parâmetros de modelagem de tráfego
Podemos usar os seguintes parâmetros de modelagem de tráfego:
-
CIR = taxa de informações comprometidas (= tempo médio)
-
EIR = excesso de taxa de informação
-
TB = token bucket (= Bc + Be)
-
Bc = tamanho de intermitência comprometida (= tamanho de intermitência sustentada)
-
Be = tamanho de intermitência em excesso
-
DE = elegibilidade de descarte
-
Tc = intervalo de medição
-
AR = taxa de acesso correspondente à taxa da interface física (portanto, se você usa um T1, o AR é aproximadamente 1,5 Mbps).
Vejamos alguns desses parâmetros em mais detalhes:
Taxa de acesso (AR)
O número máximo de bits por segundo que uma estação final pode transmitir para a rede é limitado pela taxa de acesso da interface usuário-rede. A velocidade da linha da conexão de rede do usuário limita a taxa de acesso. Você pode estabelecer isso na sua assinatura do provedor de serviços.
Tamanho De Intermitência Comprometida (Bc)
A quantidade máxima comprometida de dados que você pode oferecer à rede é definida como Bc. Bc é uma medida para o volume de dados para o qual a rede garante a entrega de mensagens em condições normais. Ele é medido durante a taxa comprometida Tc.
Tamanho de burst excedente (Be)
O número de bits não comprometidos (fora do CIR) que ainda são aceitos pelo switch Frame Relay, mas que são marcados como elegíveis para descarte (DE).
O token bucket é um buffer 'virtual'. Ele contém vários tokens, permitindo que você envie uma quantidade limitada de dados por intervalo de tempo. O token bucket é preenchido com bits Bc por Tc. O tamanho máximo do bucket é Bc + Be. Se o Be for muito grande e, se em T0 o bucket for preenchido com tokens Bc + Be, você poderá enviar Bc + Be bits à taxa de acesso. Isso não é limitado pelo Tc, mas pelo tempo necessário para enviar o Be. Esta é uma função da taxa de acesso.
Committed Information Rate (CIR)
A CIR é a quantidade permitida de dados que a rede está comprometida a transferir em condições normais. A taxa é média ao longo de um incremento de tempo Tc. A CIR também é conhecida como throughput mínimo aceitável. Bc e Be são expressos em bits, Tc em segundos e a taxa de acesso e CIR em bits por segundo.
Bc, Be, Tc e CIR são definidos por DLCI (Data-Link Connection Identifier Identificador de Conexão de Enlace de Dados). Devido a isso, o filtro de token bucket controla a taxa por DLCI. A taxa de acesso é válida por interface usuário-rede. Para Bc, os valores de entrada e saída Be e CIR podem ser diferenciados. Se a conexão for simétrica, os valores em ambas as direções serão os mesmos. Para circuitos virtuais permanentes, definimos Bc, Be e CIR de entrada e saída no momento da assinatura.
-
Pico = velocidade máxima do DLCI. A largura de banda desse DLCI específico.
-
Tc = Bc / CIR
-
Pico = CIR + Be/Tc = CIR (1 + Be/Bc)
Se o Tc for um segundo então:
-
Pico = CIR + Be = Bc + Be
-
EIR = Be
No exemplo que estamos usando aqui, o roteador envia tráfego entre 48 Kbps e 32 Kbps, dependendo do congestionamento na rede. As redes podem marcar quadros acima de Bc com DE, mas têm capacidade sobressalente suficiente para transportar o quadro. O contrário também é possível: eles podem ter capacidade limitada, mas descartam quadros excessivos imediatamente. As redes podem marcar quadros acima de Bc + Be com DE, e possivelmente transportá-los, ou simplesmente descartar os quadros conforme sugerido pela especificação ITU-T I.370 do Setor de Padronização de Telecomunicações da União Internacional de Telecomunicações. A modelagem de tráfego restringe o tráfego com base em pacotes marcados com BECN (notificação de congestionamento explícito para trás) da rede do switch. Se você receber 50% de BECN, o roteador diminuirá o tráfego em um oitavo da largura de banda transmitida atual para esse DLCI específico.
Exemplo
A velocidade transmitida é de 42 Kb. O roteador diminui a velocidade para 42 menos 42 dividido por 8 (42 - 42/8), tornando 36,75 Kb. Se o congestionamento diminuir após a alteração, o roteador reduz ainda mais o tráfego, caindo para um oitavo da largura de banda transmitida atual. O tráfego é reduzido até alcançar o valor CIR configurado. No entanto, a velocidade pode cair sob a CIR quando ainda podemos ver BECNs. Você pode especificar um limite inferior, como CIR/2. A rede não está mais congestionada quando todos os quadros recebidos da rede não têm mais um bit BECN para um determinado intervalo de tempo. 200 ms é o valor padrão para esse intervalo.
Formatação de tráfego genérico
O recurso de modelagem de tráfego genérico é uma ferramenta de modelagem de tráfego independente de mídia e encapsulamento que ajuda a reduzir o fluxo de tráfego de saída quando há congestionamento na nuvem, no link ou no roteador de endpoint de recepção. Podemos defini-lo em interfaces ou subinterfaces dentro de um roteador.
A modelagem de tráfego genérica é útil nas seguintes situações:
-
Quando você tem uma topologia de rede que consiste em uma conexão de alta velocidade (velocidade da linha T1) no local central e conexões de baixa velocidade (menos de 56 kbps) nas filiais ou nos locais de trabalho remoto. Devido à incompatibilidade de velocidade, geralmente existe um gargalo para o tráfego nas filiais ou nos locais de trabalho remoto quando o local central envia dados a uma taxa mais rápida que os locais remotos podem receber. Isso resulta em um gargalo no último switch antes do roteador de ponto remoto.
-
Se você for um provedor de serviços que oferece serviços de subtaxa, esse recurso permitirá que você use o roteador para particionar seus links T1 ou T3, por exemplo, em canais menores. Você pode configurar cada subinterface com um bucket de filtro de token que corresponda ao serviço solicitado por um cliente.
Na conexão do Frame Relay, você pode querer que o roteador controle o tráfego em vez de enviá-lo para a rede. Limitar o tráfego limitaria a perda de pacotes na nuvem do provedor de serviços. O recurso de limitação baseado em BECN fornecido com esse recurso permite que você tenha o roteador dinamicamente acelerando o tráfego com base no recebimento de pacotes rotulados de BECN da rede. Essa limitação mantém os pacotes nos buffers do roteador para reduzir o fluxo de dados do roteador para a rede do Frame Relay. O roteador limita o tráfego em uma base de subinterface, e a taxa também é aumentada quando menos pacotes marcados com BECN são recebidos.
Comandos para modelagem de tráfego genérico
Para definir o controle de taxa, use este comando:
traffic-shape rate bit-rate [burst-size [excesso-burst-size]] [group access-list]
Para acelerar BECNs em uma interface do Frame Relay, use este comando:
traffic-shape adaptive [bit-rate]
Para configurar uma subinterface do Frame Relay para estimar a largura de banda disponível quando ele recebe BECNs, use o comando traffic-shape adaptive.
Observação: você deve habilitar a modelagem de tráfego na interface com o comando traffic-shape rate antes de usar o comando traffic-shape adaptive.
A taxa de bits especificada para o comando traffic-shape rate é o limite superior, e a taxa de bits especificada para o comando traffic-shape adaptive é o limite inferior (geralmente o valor CIR) no qual o tráfego é modelado quando a interface recebe BECNs. A taxa efetivamente utilizada situa-se normalmente entre estas duas taxas. Você deve configurar o comando traffic-shape adaptive em ambas as extremidades do link, pois ele também configura o dispositivo na extremidade do fluxo para refletir os sinais FECN (forward Explicit Congestion Notification, notificação explícita de congestionamento de encaminhamento) como BECNs. Isso permite que o roteador na extremidade de alta velocidade detecte e se adapte ao congestionamento mesmo quando o tráfego está fluindo principalmente em uma direção.
Exemplo
O exemplo a seguir configura a modelagem de tráfego na interface 0.1 com um limite superior (geralmente Bc + Be) de 128 kbps e um limite inferior de 64 kbps. Isso permite que o link seja executado de 64 a 128 kbps, dependendo do nível de congestionamento. Se o lado central tiver um limite máximo de 256 kbps, você deve usar o valor de limite máximo mais baixo.
Veja o que configuramos nestes roteadores:
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
Formatação de tráfego frame relay
Com a modelagem de tráfego genérica, você só pode especificar uma taxa de pico (limite superior) por interface física e um valor CIR (limite inferior) por subinterface. Com a modelagem de tráfego do Frame Relay, você inicia um filtro de token bucket por circuito virtual.
O recurso de modelagem de tráfego sobre Frame Relay fornece os seguintes recursos:
-
Aplicação de taxa por VC: Você pode configurar uma taxa de pico para limitar o tráfego de saída à CIR ou a algum outro valor definido, como a EIR (excesso de taxa de informações).
-
Suporte BECN generalizado por VC: O roteador pode monitorar BECNs e limitar o tráfego com base no feedback de pacotes marcados com BECN da rede do Frame Relay.
-
Enfileiramento de prioridade (PQ), enfileiramento personalizado (CQ) ou suporte a WFQ no nível de VC. Isso permite uma melhor granularidade na priorização e enfileiramento do tráfego, dando a você mais controle sobre o fluxo de tráfego em um VC individual. O recurso de modelagem de tráfego sobre Frame Relay se aplica a PVCs (Permanent Virtual Circuits, circuitos virtuais permanentes) e SVCs (Switched Virtual Circuits, circuitos virtuais comutados) do Frame Relay.
Exemplo
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 !
Neste exemplo, o roteador adiciona dois token-buckets.
-
Um executa entre 64000 (CIR) e 128000 (Bc + Be).
-
O outro é executado entre 16000 (CIR) e 64000 (Bc + Be).
Se o tráfego de entrada da Ethernet for maior que o filtro de token bucket, o tráfego será colocado em buffer na fila de tráfego frame-relay.
Para ver um fluxograma mostrando o fluxo de pacotes quando você implementa a modelagem de tráfego do Frame Relay, consulte Fluxograma de modelagem de tráfego do Frame Relay. Para ver um fluxograma especificamente usando um filtro de token bucket, consulte Frame Relay Traffic Shaping - Fluxograma de Token Bucket.
Comandos de Frame Relay mais usados
Esta seção descreve dois comandos do Cisco IOS® que são especialmente úteis na configuração do Frame Relay.
show frame-relay pvc
Esse comando mostra o status do PVC (Permanent Virtual Circuit, circuito virtual permanente), pacotes de entrada e saída, pacotes descartados se houver congestionamento na linha por meio da FECN (Forward Explicit Congestion Notification, notificação de congestionamento explícito de encaminhamento) e BECN (Back Explicit Congestion Notification, notificação de congestionamento explícito de retorno) etc. Para obter uma descrição detalhada dos campos usados com o comando show frame-relay pvc, clique aqui.
Se você tiver a saída de um comando show frame-relay pvc de seu dispositivo Cisco, poderá usar o Output Interpreter (somente clientes registrados) para exibir problemas e correções potenciais.
Uma saída de exemplo é mostrada abaixo:
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
O campo DLCI USAGE contém uma das seguintes entradas:
-
SWITCHED - o roteador ou o servidor de acesso é usado como um switch.
-
LOCAL - o roteador ou o servidor de acesso é usado como DTE (Data Terminal Equipment, equipamento terminal de dados).
-
UNUSED - o identificador de conexão de enlace de dados (DLCI) não é referenciado pelos comandos de configuração inseridos pelo usuário no roteador.
O PVC pode ter quatro estados possíveis. Eles são mostrados pelo campo STATUS do PVC da seguinte maneira:
-
ATIVE (ATIVO) - O PVC está ativo e funcionando normalmente.
-
INATIVO - o PVC não está completo. Isso pode ser porque não há mapeamento (ou mapeamento incorreto) para o DLCI local na nuvem do frame-relay ou a extremidade remota do PVC é Excluída.
-
EXCLUÍDO - A LMI (Local Management Interface, interface de gerenciamento local) não é trocada entre o roteador e o switch local, ou o switch não tem DLCI configurado no switch local.
-
ESTÁTICO - sem keepalive configurado na interface frame-relay do roteador.
show frame-relay map
Use este comando para determinar se frame-relay inverse-arp resolveu um endereço IP remoto para um DLCI local. Esse comando não está ativado para subinterfaces ponto a ponto. É útil somente para interfaces multiponto e subinterfaces. Uma saída de exemplo é mostrada abaixo:
RouterA#show frame-relay map
Serial0 (up): ip 157.147.3.65 dlci 980(0x3D4,0xF440), dynamic,
broadcast,, status defined, active
Para obter uma descrição detalhada dos campos usados com o comando show frame-relay map, consulte Documentation on frame relay Commands.
Se você tiver a saída de um comando show frame-relay map de seu dispositivo Cisco, poderá usar o Output Interpreter (somente clientes registrados) para exibir problemas e correções potenciais.
Frame relay e bridging
As mensagens de configuração chamadas BPDUs (Bridge Protocol Data Units, unidades de dados de protocolo de ponte) são usadas nos protocolos spanning tree suportados em bridges e roteadores da Cisco. Esses fluxos em intervalos regulares entre pontes e constituem uma quantidade significativa de tráfego devido à sua ocorrência frequente. Há dois tipos de protocolos spanning-tree em bridging transparente. Introduzido pela DEC (Digital Equipment Corporation), o algoritmo foi subsequentemente revisado pelo comitê IEEE 802 e publicado na especificação IEEE 802.1d. O DEC Spanning-Tree Protocol emite BPDUs em intervalos de um segundo, enquanto o IEEE emite BPDUs em intervalos de dois segundos. Cada pacote tem 41 bytes, o que inclui uma mensagem BPDU de configuração de 35 bytes, um cabeçalho Frame Relay de 2 bytes, Ethertype de 2 bytes e FCS de 2 bytes.
Frame Relay e memória
O consumo de memória para recursos do Frame Relay ocorre em quatro áreas:
-
Cada identificador de conexão de enlace de dados (DLCI): 216 bytes
-
Cada declaração de mapa: 96 bytes (ou mapa dinamicamente construído)
-
Cada IDB (interface de hardware + encap Frame Relay): 5040 + 8346 = 13.386 bytes
-
Cada IDB (subinterface de software): 2260 bytes
Por exemplo, um Cisco 2501 usando duas interfaces Frame Relay, cada uma com quatro subinterfaces, com um total de oito DLCIs e mapas associados, precisa do seguinte:
-
IDB de hardware de 2 interfaces x 13.386 = 26.772
-
8 subinterfaces IDB x 2260 = 18.080 subinterfaces
-
8 DLCIs x 216 = 1728 DLCIs
-
8 instruções de mapa x 96 = 768 instruções ou dinâmica de mapa
O total é igual a 47.348 bytes de RAM usados.
Observação: os valores usados aqui são válidos para o software Cisco IOS versão 11.1, 12.0 e 12.1.
Troubleshooting de Frame Relay
Esta seção contém partes da possível saída do comando show interface que você pode encontrar durante a solução de problemas. Também são fornecidas explicações sobre a saída.
"Serial0 is down, line protocol is down"
Essa saída significa que você tem um problema com o cabo, a unidade de serviço de canal/unidade de serviço de dados (CSU/DSU) ou a linha serial. Você precisa solucionar o problema com um teste de loopback. Para fazer um teste de loopback, siga as etapas abaixo:
-
Defina o encapsulamento de linha serial como HDLC e keepalive como 10 segundos. Para fazer isso, emita os comandos encapsulation hdlc e keepalive 10 na interface serial.
-
Coloque a CSU/DSU ou o modem no modo de loop local. Se o protocolo de linha for ativado quando a CSU, DSU ou modem estiver no modo de loopback local (indicado por uma mensagem "line protocol is up (looped)"), ele sugerirá que o problema está ocorrendo além da CSU/DSU local. Se a linha de status não alterar os estados, é possível que haja um problema no roteador, conectando cabo, CSU/DSU ou modem. Na maioria dos casos, o problema está na CSU/DSU ou no modem.
-
Faça ping no seu próprio endereço IP com a CSU/DSU ou modem em loop. Não deve haver falhas. Um ping estendido de 0x0000 é útil na resolução de problemas de linha, pois um T1 ou E1 deriva o relógio dos dados e exige uma transição a cada 8 bits. B8ZS garante isso. Um padrão de dados zero pesado ajuda a determinar se as transições são forçadas adequadamente no tronco. Um padrão de uns pesados é usado para simular adequadamente uma carga zero alta, caso haja um par de inversores de dados no caminho. O padrão alternado (0x5555) representa um padrão de dados "típico". Se os pings falharem ou se você receber erros de verificação de redundância cíclica (CRC), é necessário um testador de taxa de erro de bit (BERT) com um analisador apropriado da empresa de telecomunicações.
-
Quando terminar de testar, certifique-se de devolver o encapsulamento ao Frame Relay.
Serial0 está ativo, o protocolo de linha está inativo
Essa linha na saída significa que o roteador está recebendo um sinal de portadora da CSU/DSU ou do modem. Verifique se o provedor do Frame Relay ativou a porta e se as configurações da LMI (Local Management Interface, interface de gerenciamento local) correspondem. Geralmente, o switch do Frame Relay ignora o DTE (Data Terminal Equipment, equipamento terminal de dados), a menos que veja a LMI correta (use o padrão da Cisco para a LMI "Cisco"). Verifique se o roteador Cisco está transmitindo dados. Provavelmente, você precisará verificar a integridade da linha usando testes de loop em vários locais, começando com a CSU local e trabalhando para sair até chegar ao switch Frame Relay do provedor. Consulte a seção anterior para saber como executar um teste de loopback.
"Serial0 está ativo, o protocolo de linha está ativo"
Se você não desligou os keepalives, essa linha de saída significa que o roteador está conversando com o switch do provedor do Frame Relay. Você deve estar vendo uma troca bem-sucedida de tráfego bidirecional na interface serial sem erros de CRC. Os keepalives são necessários no Frame Relay porque são o mecanismo que o roteador usa para "aprender" quais DLCIs (data-link connection identifiers, identificadores de conexão de enlace de dados) o provedor provisionou. Para assistir à troca, você pode usar com segurança debug frame-relay lmi em quase todas as situações. O comando debug frame-relay lmi gera muito poucas mensagens e pode fornecer respostas a perguntas como:
-
O roteador Cisco está se comunicando com o switch local do Frame Relay?
-
O roteador está recebendo mensagens de status de LMI completas para PVCs (Permanent Virtual Circuits, circuitos virtuais permanentes) subscritos do provedor do Frame Relay?
-
Os DLCIs estão corretos?
Aqui estão alguns exemplos de saída debug frame-relay lmi de uma conexão bem-sucedida:
*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 o status de "DLCI 980" na saída acima. Os valores possíveis do campo de status são explicados a seguir:
-
0x0-Added/inative significa que o switch tem esse DLCI programado, mas por algum motivo (como a outra extremidade deste PVC está inativa), ele não é utilizável.
-
0x2-Added/ative significa que o switch Frame Relay tem o DLCI e tudo está operacional. Você pode começar a enviar o tráfego com este DLCI no cabeçalho.
-
0x3-0x3 é uma combinação de um status ativo (0x2) e o RNR (ou r-bit) definido (0x1). Isso significa que o backup do switch - ou de uma fila específica no switch - para esse PVC é feito, e você pára de transmitir em caso de derramamento de quadros.
-
0x4-Deleted significa que o switch Frame Relay não tem esse DLCI programado para o roteador. Mas foi programado em algum momento do passado. Isso também pode ser causado pela reversão dos DLCIs no roteador ou pela exclusão do PVC pela telco na nuvem do Frame Relay. A configuração de um DLCI (que o switch não tem) será exibida como 0x4.
-
0x8-Novo/inativo
-
0x0a-Novo/ativo
Características do Frame Relay
Esta seção explica várias características do Frame Relay das quais você deve estar ciente.
Verificação do horizonte de divisão de IP
A verificação do split horizon IP é desativada por padrão para o encapsulamento do Frame Relay, de modo que as atualizações de roteamento entrarão e sairão da mesma interface. Os roteadores aprendem os DLCIs (Data-Link Connection Identifiers Identificadores de Conexão de Enlace de Dados) que precisam usar a partir do switch Frame Relay através de atualizações da LMI (Local Management Interface, Interface de Gerenciamento Local). Os roteadores então usam o ARP inverso para o endereço IP remoto e criam um mapeamento de DLCIs locais e seus endereços IP remotos associados. Além disso, certos protocolos como AppleTalk, transparent bridging e IPX não podem ser suportados em redes parcialmente em malha porque exigem "split horizon", no qual um pacote recebido em uma interface não pode ser transmitido pela mesma interface, mesmo que o pacote seja recebido e transmitido em circuitos virtuais diferentes. A configuração de subinterfaces de Frame Relay garante que uma única interface física seja tratada como várias interfaces virtuais. Esse recurso nos permite superar regras de split horizon. Os pacotes recebidos em uma interface virtual agora podem ser encaminhados por outra interface virtual, mesmo que estejam configurados na mesma interface física.
Execute ping no seu endereço IP em um Frame Relay multiponto
Você não pode fazer ping em seu próprio endereço IP em uma interface de Frame Relay multiponto. Isso ocorre porque as subinterfaces multiponto (sub)Frame Relay são não broadcast, (diferentemente das interfaces Ethernet e ponto-a-ponto HDLC) e sub-interfaces ponto-a-ponto Frame Relay.
Além disso, você não pode fazer ping de um spoke para outro em uma configuração de hub e spoke. Isso ocorre porque não há mapeamento para seu próprio endereço IP (e nenhum foi aprendido via ARP inverso). Mas se você configurar um mapa estático (usando o comando frame-relay map) para seu próprio endereço IP (ou um para o spoke remoto) para usar o DLCI local, poderá então fazer ping nos seus 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
!
A transmissão de palavra-chave
A palavra-chave broadcast fornece duas funções: encaminha broadcasts quando o multicast não está habilitado e simplifica a configuração do OSPF (Open Shortest Path First) para redes não broadcast que usam o Frame Relay.
A palavra-chave broadcast também pode ser necessária para alguns protocolos de roteamento — por exemplo, AppleTalk — que dependem de atualizações regulares da tabela de roteamento, especialmente quando o roteador na extremidade remota está esperando que um pacote de atualização de roteamento chegue antes de adicionar a rota.
Ao exigir a seleção de um roteador designado, o OSPF trata uma rede multiacesso não broadcast, como o Frame Relay, da mesma forma que trata uma rede de broadcast. Nas versões anteriores, isso exigia a atribuição manual na configuração do OSPF usando o comando neighbor interface router. Quando o comando frame-relay map é incluído na configuração com a palavra-chave broadcast, e o comando ip ospf network (com a palavra-chave broadcast) é configurado, não há necessidade de configurar qualquer vizinho manualmente. O OSPF agora é executado automaticamente na rede do Frame Relay como uma rede de broadcast. (Consulte o comando ip ospf network interface para obter mais detalhes.)
Observação: o mecanismo de broadcast OSPF pressupõe que os endereços IP classe D nunca são usados para tráfego regular sobre Frame Relay.
Exemplo
O exemplo a seguir mapeia o endereço IP de destino 172.16.123.1 para DLCI 100:
interface serial 0 frame-relay map IP 172.16.123.1 100 broadcast
O OSPF usa DLCI 100 para transmitir atualizações.
Reconfigurando uma subinterface
Depois de criar um tipo específico de subinterface, você não poderá alterá-la sem um recarregamento. Por exemplo, você não pode criar uma subinterface serial0.2 multiponto e, em seguida, alterá-la para ponto a ponto. Para alterá-lo, você precisa recarregar o roteador ou criar outra subinterface. É assim que o código do Frame Relay funciona no software Cisco IOS®.
Limitações DLCI
Espaço de endereço DLCI
Aproximadamente 1000 DLCIs podem ser configurados em um único link físico, dado um endereço de 10 bits. Como alguns DLCIs são reservados (dependente de fornecedor-implementação-dependente), o máximo é cerca de 1000. O intervalo para uma LMI da Cisco é 16-1007. O intervalo declarado para ANSI/ITU é 16-992. Esses são os DLCIs que transportam dados de usuário.
No entanto, ao configurar VCs de Frame Relay em subinterfaces, você precisa considerar um limite prático conhecido como limite IDB. O número total de interfaces e subinterfaces por sistema é limitado pelo número de blocos descritores de interface (IDBs) suportados pela sua versão do Cisco IOS. Uma IDB é uma parte da memória que contém informações sobre a interface, como contadores, status da interface e assim por diante. O IOS mantém uma IDB para cada interface presente em uma plataforma e mantém uma IDB para cada subinterface. As interfaces de velocidade mais alta exigem mais memória do que as interfaces de velocidade mais baixa. Cada plataforma contém quantidades diferentes de IDBs máximos e esses limites podem mudar com cada versão do Cisco IOS.
Para obter mais informações, consulte Número máximo de interfaces e subinterfaces para plataformas do software Cisco IOS: Limites de IDB.
Atualização de status LMI
O protocolo LMI requer que todos os relatórios de status do circuito virtual permanente (PVC) caibam em um único pacote e geralmente limita o número de DLCIs para menos de 800, dependendo do tamanho da unidade de transmissão máxima (MTU).
O MTU padrão nas interfaces seriais é de 1500 bytes, resultando em um máximo de 296 DLCIs por interface. Você pode aumentar o MTU para suportar uma mensagem de atualização de status completo maior do switch Frame Relay. Se a mensagem de atualização de status completa for maior que o MTU da interface, o pacote será descartado e o contador gigante da interface será incrementado. Ao alterar o MTU, assegure-se de que o mesmo valor seja configurado no roteador remoto e nos dispositivos de rede que intervêm.
Observe que esses números variam um pouco, dependendo do tipo de LMI. A diretriz máxima de DLCIs por roteador (não interface), baseada na extrapolação de dados empíricos estabelecidos em uma plataforma de roteador Cisco 7000, está listada abaixo:
-
Cisco 2500: 1 link T1/E1 a 60 DLCIs por interface = total de 60
-
Cisco 4000: 1 link T1/E1 a 120 DLCIs por interface = total de 120
-
Cisco 4500: 3 X links T1/E1 a 120 DLCIs por interface = total de 360
-
Cisco 4700: 4 links T1/E1 a 120 DLCIs por interface = total de 480
-
Cisco 7000: 4 links T1/E1/T3/E3 a 120 DLCIs por interface = total de 480
-
Cisco 7200: 5 links T1/E1/T3/E3 a 120 DLCIs por interface = total de 600
-
Cisco 7500: 6 links T1/E1/T3/E3 a 120 DLCIs por interface = total de 720
Observação: esses números são somente diretrizes e supõem que todo o tráfego seja comutado rapidamente.
Outras considerações
Um limite prático de DLCI também depende se os VCs estão executando um protocolo de roteamento dinâmico ou estático. Os protocolos de roteamento dinâmico e outros protocolos como o IPX SAP que trocam tabelas de banco de dados, enviam mensagens hello e de informações de encaminhamento que devem ser vistas e processadas pela CPU. Como regra geral, o uso de rotas estáticas permitirá que você configure um número maior de VCs em uma única interface do Frame Relay.
Endereço IP/IPX/AT
Se você estiver usando subinterfaces, não coloque um endereço IP, IPX ou AT na interface principal. Atribua DLCIs às suas subinterfaces antes de habilitar a interface principal para garantir que o frame-relay inverse-arp funcione corretamente. Se ocorrer um mau funcionamento, siga as etapas abaixo:
-
Desative o Inverse Address Resolution Protocol (ARP) para esse DLCI usando os comandos no frame-relay inverse-arp ip 16 e clear frame-relay-inarp.
-
Corrija sua configuração.
-
Ative o comando frame-relay inverse-arp novamente.
RIP e IGRP
As atualizações do Routing Information Protocol (RIP) fluem a cada 30 segundos. Cada pacote RIP pode conter até 25 entradas de rota, para um total de 536 bytes; 36 bytes desse total são informações de cabeçalho e cada entrada de rota é 20 bytes. Portanto, se você anunciar 1.000 rotas sobre um link Frame Relay configurado para 50 DLCIs, o resultado será 1 MB de dados de atualização de roteamento a cada 30 segundos, ou 285 kbps de largura de banda consumida. Em um link T1, essa largura de banda representa 18,7% da largura de banda, com cada duração de atualização sendo de 5,6 segundos. Essa quantidade de sobrecarga é considerável e é aceitável na linha de fronteira, mas a taxa de informação comprometida (CIR) teria que estar na região da velocidade de acesso. Obviamente, qualquer coisa menor que um T1 teria muita sobrecarga. Por exemplo:
-
1000/25 = 40 pacotes X 36 = 1440 bytes de cabeçalho
-
1000 X 20 bytes = 20.000 bytes de entradas de rota
-
Total de 21.440 bytes X 50 DLCIs = 1072 MB de atualizações do RIP a cada 30 segundos
-
1.072.000 bytes / 30 seg X 8 bits = 285 kbps
As atualizações do Interior Gateway Routing Protocol (IGRP) fluem a cada 90 segundos (esse intervalo é configurável). Cada pacote IGRP pode conter 104 entradas de rota, para um total de 1492 bytes, 38 dos quais são informações de cabeçalho e cada entrada de rota é de 14 bytes. Se você anunciar 1.000 rotas sobre um link Frame Relay configurado com 50 DLCIs, a solicitação é aproximadamente 720 KB de dados de atualização de roteamento a cada 90 segundos, ou 64 kbps de largura de banda consumida. Em um link T1, essa largura de banda representaria 4,2% da largura de banda, com cada duração de atualização sendo 3,7 segundos. Essa sobrecarga é um valor aceitável:
-
1000/104 = 9 pacotes X 38 = 342 bytes de cabeçalho
-
1000 X 14 = 14.000 bytes de entradas de rota
-
Total = 14.342 bytes X 50 DLCIs = 717 KB de atualizações IGRP a cada 90 segundos
-
717.000 bytes / 90 X 8 bits = 63,7 kbps
As atualizações de roteamento do Routing Table Maintenance Protocol (RTMP) ocorrem a cada 10 segundos (esse intervalo é configurável). Cada pacote RTMP pode conter até 94 entradas de rota estendida, para um total de 564 bytes, 23 bytes de informações de cabeçalho e cada entrada de rota é de 6 bytes. Se você anunciar 1000 redes AppleTalk em um link Frame Relay configurado para 50 DLCIs, o resultado será aproximadamente 313 KB de atualizações RTMP a cada 10 segundos, ou 250 kbps de largura de banda consumida. Para permanecer dentro de um nível aceitável de sobrecarga de 15% ou menos), é necessária uma taxa T1. Por exemplo:
-
1000/94 = 11 pacotes X 23 bytes = 253 bytes de cabeçalho
-
1000 X 6 = 6000 bytes de entradas de rota
-
Total = 6253 X 50 DLCIs = 313 KB de atualizações RTMP a cada 10 segundos
-
313.000 / 10 seg X 8 bits = 250 kbps
As atualizações de pacotes RIP IPX ocorrem a cada 60 segundos (esse intervalo é configurável). Cada pacote RIP IPX pode conter até 50 entradas de rota para um total de 536 bytes, 38 bytes de informações de cabeçalho e cada entrada de rota é de 8 bytes. Se você anunciar rotas 1000 IPX sobre um link Frame Relay configurado para 50 DLCIs, o resultado é 536 KB de atualizações IPX a cada 60 segundos, ou 58,4 kbps de largura de banda consumida. Para permanecer dentro de um nível aceitável de sobrecarga (15% ou menos), é necessária uma taxa de 512 kbps. Por exemplo:
-
1000/50 = 20 pacotes X 38 bytes = 760 bytes de cabeçalho
-
1000 X 8 = 8000 bytes de entradas de rota
-
Total = 8760 X 50 DLCIs = 438.000 bytes de atualizações IPX a cada 60 segundos
-
438.000 / 60 seg X 8 bits = 58,4 kbps
As atualizações de pacotes de ponto de acesso de serviço (SAP) IPX ocorrem a cada 60 segundos (esse intervalo é configurável). Cada pacote SAP IPX pode conter até sete entradas de anúncio para um total de 536 bytes, 38 bytes de informações de cabeçalho e cada entrada de anúncio é de 64 bytes. Se você difundir 1000 anúncios IPX em um link Frame Relay configurado para 50 DLCIs, você terminaria com 536 KB de atualizações IPX a cada 60 segundos, ou 58,4 kbps de largura de banda consumida. Para permanecer dentro de um nível aceitável de sobrecarga (15% ou menos), é necessária uma taxa maior que 2 Mbps. Obviamente, a filtragem SAP é necessária neste cenário. Comparadas a todos os outros protocolos mencionados nesta seção, as atualizações IPX SAP exigem a maior largura de banda:
-
1000/7 = 143 pacotes X 38 bytes = 5434 bytes de cabeçalho
-
1000 X 64 = 64.000 bytes de entradas de rota
-
Total = 69.434 X 50 DLCIs = 3.471.700 bytes de anúncios de serviço IPX a cada 60 segundos
-
3.471.700 / 60 s X 8 bits = 462 kbps
Manutenção de atividade
Em alguns casos, a manutenção de atividade no dispositivo Cisco precisa ser definida como um pouco mais curta (cerca de 8 segundos) do que a manutenção de atividade no switch. Você verá a necessidade disso se a interface continuar ativa e inativa.
Interfaces seriais
As interfaces seriais, que são por padrão multiponto, são meios não broadcast, enquanto as subinterfaces ponto-a-ponto são broadcast. Se estiver usando rotas estáticas, você poderá apontar para o próximo salto ou para a subinterface serial. Para multiponto, você precisa apontar para o próximo salto. Esse conceito é muito importante ao se fazer OSPF sobre Frame Relay. O roteador precisa saber que essa é uma interface de broadcast para que o OSPF funcione.
OSPF e multiponto
OSPF e multiponto podem ser muito problemáticos. O OSPF precisa de um roteador designado (DR). Se você começar a perder PVCs, alguns roteadores podem perder a conectividade e tentar se tornar um DR, mesmo que outros roteadores ainda vejam o antigo DR. Isso faz com que o processo OSPF não funcione corretamente.
A sobrecarga associada ao OSPF não é tão óbvia e previsível quanto a protocolos de roteamento de vetor de distância tradicionais. A imprevisibilidade vem da estabilidade ou não dos links de rede OSPF. Se todas as adjacências a um roteador Frame Relay forem estáveis, somente os pacotes de saudação vizinhos (keepalives) fluirão, o que é comparativamente muito menos sobrecarga do que o incorrido com um protocolo de vetor de distância (como RIP e IGRP). No entanto, se as rotas (adjacências) forem instáveis, ocorrerá inundação de link-state e a largura de banda poderá ser consumida rapidamente. O OSPF também usa muito o processador ao executar o algoritmo Dijkstra, que é usado para rotas de computação.
Nas versões anteriores do software Cisco IOS, foi necessário ter cuidado especial ao configurar o OSPF em meios não broadcast multiacesso, como Frame Relay, X.25 e ATM. O protocolo OSPF considera esses meios como qualquer outro meio de transmissão, como a Ethernet. As nuvens de NBMA (Nonbroadcast Multiaccess, multiacesso sem broadcast) normalmente são construídas em uma topologia de hub e spoke. PVCs ou circuitos virtuais comutados (SVCs) são dispostos em uma malha parcial e a topologia física não fornece o multiacesso que o OSPF acredita que existe. Para o caso de interfaces seriais ponto-a-ponto, o OSPF sempre forma uma adjacência entre os vizinhos. As adjacências OSPF trocam informações de banco de dados. Para minimizar a quantidade de informações trocadas em um segmento específico, o OSPF escolhe um roteador como DR e um roteador como BDR (Backup Designated Router, roteador designado de backup) em cada segmento multiacesso. O BDR é escolhido como mecanismo de backup, caso o DR seja desativado.
A ideia por trás dessa configuração é que os roteadores têm um ponto central de contato para troca de informações. A seleção do DR tornou-se um problema porque o DR e o BDR precisavam ter conectividade física completa com todos os roteadores existentes na nuvem. Além disso, devido à falta de recursos de broadcast, o DR e o BDR precisavam ter uma lista estática de todos os outros roteadores conectados à nuvem. Essa configuração é obtida usando o comando neighbor:
neighbor ip-address [priority number] [poll-interval seconds]
Em versões posteriores do software Cisco IOS, diferentes métodos podem ser usados para evitar as complicações de configurar vizinhos estáticos e ter roteadores específicos se tornando DRs ou BDRs na nuvem não broadcast. O método a ser usado é influenciado pelo fato de a rede ser nova ou um projeto existente que precisa ser modificado.
Uma subinterface é uma maneira lógica de definir uma interface. A mesma interface física pode ser dividida em interfaces lógicas múltiplas, com cada sub-interface sendo definida como ponto a ponto. Esse cenário foi originalmente criado para lidar melhor com problemas causados por split horizon sobre NBMA e protocolos de roteamento baseados em vetor.
Uma subinterface ponto a ponto tem as propriedades de qualquer interface física ponto a ponto. Como o OSPF é uma preocupação, uma adjacência é sempre formada em uma sub-interface ponto a ponto sem escolha de DR ou BDR. O OSPF considera a nuvem um conjunto de links ponto-a-ponto em vez de uma rede multiacesso. A única desvantagem do ponto a ponto é que cada segmento pertence a uma sub-rede diferente. Esse cenário pode não ser aceitável porque alguns administradores já atribuíram uma sub-rede IP para toda a nuvem. Outra solução é usar interfaces IP não numeradas na nuvem. Esse cenário também pode ser um problema para alguns administradores que gerenciam a WAN com base nos endereços IP das linhas seriais.
Origens
-
International Telegraph and Telephone Consultative Committee, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", Recomendação Q.922 do CCITT, 19 de abril de 1991.
-
American National Standard for Telecommunications - Integrated Services Digital Network - Aspects of Frame Protocol for Use with Frame Relay Bearer Service, ANSI T1.618-1991, 18 de junho de 1991.
-
Tecnologia da informação - Telecomunicações e intercâmbio de informações entre sistemas - Identificação de protocolo na camada de rede, ISO/IEC TR 9577: 1990 (E) 1990-10-15.
-
Padrão Internacional, Sistemas de Processamento de Informações - Redes Locais - Controle Lógico de Enlace, ISO 8802-2: 1989 (E), IEEE Std 802.2-1989, 1989-12-31.
-
Visão geral da tecnologia de internetworking, outubro de 1994, Cisco Systems
-
Finlayson, R., Mann, R., Mogul, J., e M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, Universidade de Stanford, junho de 1984.
-
Postel, J. e Reynolds, J., "Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information Sciences Institute, fevereiro de 1988.
-
Frame Relay Forum (FRF) 1.1-User-Network Interface (UNI)
-
FRF 2.1-Interface Rede-Rede (NNI - Network-to-Network Interface) de Frame Relay
-
Encapsulamento multiprotocolo FRF 3.1
-
FRF 4-SVCs
-
Gerenciamento de rede de cliente (MIB) de serviço de Frame Relay FRF 6
-
Gangue de quatro LMI
-
Q.922 Anexo A
-
ANSI T1.617 Anexo D
-
ANSI T1.618, T1.606
-
ITU-T Q.933, Q.922
-
Notas de configuração para a implementação aprimorada do IGRP aprimorado
Informações Relacionadas
- Mais informações sobre os comandos do Frame Relay
- Mais informações sobre a configuração do Frame Relay
- Mais informações sobre os comandos de backup de discagem
- Mais informações sobre os comandos de depuração ISDN
- Mais informações sobre os comandos debug do PPP
- Mais informações sobre tipos, códigos e valores de switches ISDN
- Suporte Técnico e Documentação - Cisco Systems