Guia abrangente para configuração e solução de problemas do Frame Relay
Contents
Introdução
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).
Observe na figura acima que os endereços Q.922, conforme definido atualmente, são dois octetos e contêm um identificador de conexão de link 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 de "flag" delimitam o início e o fim do quadro. Seguindo o primeiro campo "flag" estão dois bytes de informações de endereço. Dez bits desses dois bytes formam o ID do circuito real (chamado de DLCI, para o identificador de conexão de link de dados).
O valor de 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 (ou seja, não estendido pela LMI [Local Management Interface Interface Interface de Gerenciamento Local]) de endereçamento, os DLCIs têm significado local; isto é, 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.
Pré-requisitos
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. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. 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 Setor de Padronização de Telecomunicações da União Internacional de Telecomunicações (ITU-T) (anteriormente o Comitê Consultivo para Telégrafo e Telefone Internacional [CCITT]) em 1984. O trabalho no Frame Relay também foi realizado no comitê de padrões T1S1 credenciado 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 interoperáveis de Frame Relay. Eles desenvolveram uma especificação de acordo com o protocolo básico do Frame Relay que estava sendo discutido no T1S1 e no ITU-T, mas a estenderam com recursos que fornecem capacidades adicionais para ambientes complexos de internetworking. Essas extensões do Frame Relay são conhecidas coletivamente como LMI. Essa é 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 de usuário são frequentemente chamados de equipamento terminal de dados (DTE), enquanto o equipamento de rede que faz interface com o DTE é frequentemente chamado de equipamento de terminação de circuito de dados (DCE). 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, que facilita maior desempenho e maior eficiência.
Como uma interface entre o usuário e o equipamento de rede, o Frame Relay fornece um meio de multiplexar estatisticamente muitas conversações lógicas de dados (chamadas de circuitos virtuais) sobre um único link físico de transmissão. Isso contrasta com os 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 de TDM ou sobre canais fornecidos pelos sistemas de TDM.
Outra característica importante do Frame Relay é que ele explora os avanços recentes na tecnologia de transmissão de rede de longa distância (WAN). Os protocolos WAN anteriores, como o X.25, foram desenvolvidos quando os sistemas de transmissão analógica e a mídia 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-os para serem executados em camadas de protocolo mais altas. Portanto, é possível aumentar o desempenho e a eficiência sem sacrificar a integridade dos dados. O Frame Relay foi projetado tendo essa abordagem em mente. Ele inclui um algoritmo de verificação de redundância cíclica (CRC) para detectar bits corrompidos (para que os dados possam ser descartados), mas não inclui nenhum mecanismo de protocolo para corrigir dados incorretos (por exemplo, retransmitindo-os nesse nível de protocolo).
Outra diferença entre o Frame Relay e o 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 dupliquem os das camadas superiores. Em vez disso, mecanismos de notificação de congestionamento muito simples são fornecidos para permitir que uma rede informe a um dispositivo do usuário que os recursos da rede estão próximos de um estado congestionado. Essa notificação pode alertar os protocolos das camadas superiores de que o controle de fluxo pode ser necessário.
Configurando Frame Relay básico
Depois que você tiver conexões confiáveis com o switch local do Frame Relay nas duas extremidades do PVC (Permanent Virtual Circuit Circuito Virtual Permanente), é hora de começar a planejar a configuração do Frame Relay. Neste primeiro exemplo, o padrão do tipo LMI (Local Management Interface Interface de Gerenciamento Local) é "cisco" LMI no Spicey. Uma interface é, por padrão, uma interface "multiponto", portanto, frame-relay inverse-arp está ativado (para ponto a ponto, 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 link de dados) que precisam usar no switch do Frame Relay por meio de atualizações da LMI. 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.
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 <device name>
-
show ip route
Spicey
Spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 83 output pkts 87 in bytes 8144
out bytes 8408 dropped pkts 0 in FECN pkts0
in BECN pkts 0 out FECN pkts 0 out BECN pkts0
in DE pkts 0 out DE pkts 0
out bcast pkts 41 out bcast bytes 3652
pvc create time 01:31:50, last time pvc status changed 01:28:28
Spicey#show frame-relay lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 550 Num Status msgs Rcvd 552
Num Update Status Rcvd 0 Num Status Timeouts 0
Spicey#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms
Spicey#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial0
124.0.0.0/24 is subnetted, 1 subnets
C 124.124.124.0 is directly connected, Ethernet0
R 123.0.0.0/8 [120/1] via 3.1.3.2, 00:00:08, Serial0
Prasit
Prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 87 output pkts 83 in bytes 8408
out bytes 8144 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 38 out bcast bytes 3464
pvc create time 01:34:29, last time pvc status changed 01:28:05
Prasit#show frame-relay lmi
LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 569 Num Status msgs Rcvd 570
Num Update Status Rcvd 0 Num Status Timeouts 0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
3.0.0.0/24 is subnetted, 1 subnets
C 3.1.3.0 is directly connected, Serial1
R 124.0.0.0/8 [120/1] via 3.1.3.1, 00:00:19, Serial1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Configurando Frame Relay do tipo “hub and spoke”
Neste exemplo, o roteador aprende quais identificadores de conexão de enlace de dados (DLCIs) usa do switch do Frame Relay e os atribui à interface principal. Em seguida, o roteador fará o ARP inverso para o endereço IP remoto.
Observação: você não poderá fazer ping no endereço IP serial de Prasit a partir do Aton, a menos que adicione explicitamente mapas Frame Relay em cada extremidade. Se o roteamento estiver configurado corretamente, o tráfego originado nas LANs não deverá ter problemas. 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á habilitado, o tráfego 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 <device name>
Spicey
spicey#show frame-relay map
Serial0 (up): ip 3.1.3.2 dlci 140(0x8C,0x20C0), dynamic,
broadcast,, status defined, active
Serial0 (up): ip 3.1.3.3 dlci 130(0x82,0x2020), dynamic,
broadcast,, status defined, active
spicey#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 32 output pkts 40 in bytes 3370
out bytes 3928 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 30 out bcast bytes 2888
pvc create time 00:15:46, last time pvc status changed 00:10:42
DLCI = 140, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 282 output pkts 291 in bytes 25070
out bytes 27876 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 223 out bcast bytes 20884
pvc create time 02:28:36, last time pvc status changed 02:25:14
spicey#
spicey#ping 3.1.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
spicey#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Prasit
prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
prasit#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 150, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 311 output pkts 233 in bytes 28562
out bytes 22648 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 162 out bcast bytes 15748
pvc create time 02:31:39, last time pvc status changed 02:25:14
prasit#ping 3.1.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
prasit#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Aton
aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
broadcast,, status defined, active
aton#show frame-relay pvc
PVC Statistics for interface Serial1 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1
input pkts 35 output pkts 32 in bytes 3758
out bytes 3366 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 27 out bcast bytes 2846
pvc create time 00:10:53, last time pvc status changed 00:10:53
aton#ping 3.1.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
aton#ping 3.1.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Conectando-se de raio para raio
Você não pode fazer ping de um spoke para outro em uma configuração hub-and-spoke usando interfaces multiponto porque não há mapeamento para os endereços IP dos outros spokes. Somente o endereço do hub é aprendido por meio 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 identificador de conexão de enlace de dados (DLCI) local, você 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 <device name>
-
show running-config
Prasit
prasit#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 150(0x96,0x2460), dynamic,
broadcast,, status defined, active
Serial1 (up): ip 3.1.3.3 dlci 150(0x96,0x2460), static,
CISCO, status defined, active
prasit#ping 3.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/80 ms
prasit#ping 122.122.122.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 122.122.122.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/76 ms
Aton
aton#show running-config
interface Ethernet0
ip address 122.122.122.1 255.255.255.0
!
interface Serial1
ip address 3.1.3.3 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay
frame-relay map ip 3.1.3.2 160
frame-relay interface-dlci 160
aton#show frame-relay map
Serial1 (up): ip 3.1.3.1 dlci 160(0xA0,0x2800), dynamic,
broadcast,, status defined, active
Serial1 (up): ip 3.1.3.2 dlci 160(0xA0,0x2800), static,
CISCO, status defined, active
aton#ping 3.1.3.2
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 3.1.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms
aton#ping 123.123.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/80 ms
Configurando subinterfaces de frame relay
As subinterfaces de Frame Relay fornecem um mecanismo para suportar redes de Frame Relay parcialmente em malha. A maioria dos protocolos assume a transitividade em uma rede lógica; isto é, se a estação A pode se comunicar com a estação B, e a estação B pode se comunicar com a estação C, então a estação A deve ser capaz de se comunicar diretamente com a estação C. A transitividade é verdadeira em redes locais, mas não em redes Frame Relay, a menos que A esteja diretamente conectado a C.
Além disso, certos protocolos, como AppleTalk e Transparent Bridging, não podem ser suportados em redes parcialmente em malha porque exigem "split horizon", em que um pacote recebido em uma interface não pode ser transmitido pela mesma interface, mesmo que o pacote seja recebido e transmitido em diferentes circuitos virtuais.
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 as regras de split horizon. Os pacotes recebidos em uma interface virtual podem agora ser encaminhados para outra interface virtual, mesmo que estejam configurados na mesma interface física.
As subinterfaces tratam das limitações das redes do Frame Relay, fornecendo uma maneira de subdividir uma rede do Frame Relay parcialmente em mesh em um número de sub-redes menores, totalmente em mesh (ou ponto-a-ponto). Cada sub-rede recebe seu próprio número de rede e aparece para os protocolos como se fosse alcançável através 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).
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 configuração de exemplo de hub e spoke a seguir 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 e uma máscara de sub-rede individuais, e o comando interface-dlci associa a subinterface a um identificador de conexão de link de dados (DLCI) 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 de protocolo do próximo salto para uma conexão específica, dado um identificador de conexão de link de dados (DLCI). As respostas às solicitações do ARP inverso são inseridas em uma tabela de mapeamento de endereço para DLCI no roteador ou servidor de acesso; a tabela é usada para fornecer o endereço de protocolo do próximo salto ou o DLCI para o tráfego de saída.
Como a interface física agora está configurada como várias subinterfaces, você deve fornecer informações que diferenciem uma subinterface da interface física e associem uma subinterface específica a um DLCI específico.
O Inverse ARP é ativado por padrão para todos os protocolos aos quais oferece suporte, 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 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 de endereço dinâmico em uma subinterface. Um mapa estático vincula um endereço de protocolo do próximo salto especificado a um DLCI especificado. O mapeamento estático remove a necessidade de solicitações do ARP inverso; quando você fornece um mapa estático, o ARP inverso é desativado automaticamente para o protocolo especificado no DLCI especificado. Você deve usar o mapeamento estático se o roteador na outra extremidade não suportar o ARP inverso ou não suportar o 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 o 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 esse for o caso, você precisará usar rotas estáticas ou roteamento dinâmico para que seu tráfego seja roteado como de costume, e você 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
Pode ser conveniente fazer backup de circuitos 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 usam uma métrica de roteamento apropriada. Você também pode usar uma interface de backup na interface principal ou por identificador de conexão de link de dados (DLCI). Pode não ajudar muito fazer o backup da interface principal porque você poderia perder PVCs (permanent virtual circuits, circuitos virtuais permanentes) sem que a interface principal ficasse inativa. Lembre-se de que o protocolo está sendo trocado com o switch local do Frame Relay, 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 o 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 obtiver êxito, 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 real de linha serial 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 que faz conexões com o lado central (Spicey). Tome cuidado para adicionar somente 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 nas 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 fica inativa.
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á de volta 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
Este é um exemplo de um hub e spoke por configuração de backup de DLCI. Os roteadores spoke estão chamando o roteador de 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 nas 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#
A serial 1 está sendo desativada.
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
As duas linhas seriais dos lados da chamada estão sendo desativadas.
Spicey#
*Mar 1 01:21:30.171: %LINK-3-UPDOWN: Interface BRI0:1, changed state toup
*Mar 1 01:21:30.627: %DIALER-6-BIND: Interface BR0:1 bound to profile Di2
*Mar 1 01:21:31.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
*Mar 1 01:21:36.191: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
to 6104 Aton
*Mar 1 01:21:40.923: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar 1 01:21:41.359: %DIALER-6-BIND: Interface BR0:2 bound to profile Di1
*Mar 1 01:21:42.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:2, changed state to up
*Mar 1 01:21:46.943: %ISDN-6-CONNECT: Interface BRI0:2 is now connected
to 6105 Prasit
*Mar 1 01:23:59.819: %DIALER-6-UNBIND: Interface BR0:1 unbound from
profile Di2
*Mar 1 01:23:59.831: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected
from 6104 Aton, call lasted 149 seconds
*Mar 1 01:23:59.927: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:24:00.923: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to down
*Mar 1 01:24:03.015: %DIALER-6-UNBIND: Interface BR0:2 unbound from
profile Di1
*Mar 1 01:24:03.023: %ISDN-6-DISCONNECT: Interface BRI0:2 disconnected
from 6105 Prasit, call lasted 142 seconds
*Mar 1 01:24:03.107: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
*Mar 1 01:24:04.107: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:2, changed state to down
Spicey#show frame map
Serial0.1 (down): point-to-point dlci, dlci 140(0x8C,0x20C0), broadcast
status defined, inactive
Serial0.2 (down): point-to-point dlci, dlci 130(0x82,0x2020), broadcast
status defined, inactive
Spicey#
Ambas as 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#
A serial 1 fica inativa.
Prasit#
*Mar 1 01:16:08.287: %LINK-3-UPDOWN: Interface Serial1, changed state to down
*Mar 1 01:16:09.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Serial1, changed state to down
*Mar 1 01:16:11.803: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 1 01:16:11.819: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
*Mar 1 01:16:11.855: %LINK-3-UPDOWN: Interface BRI0, changed state to up
*Mar 1 01:16:15.967: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI
64 changed to up
Prasit#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
160.160.0.0/24 is subnetted, 1 subnets
C 160.160.160.0 is directly connected, BRI0
124.0.0.0/24 is subnetted, 1 subnets
S 124.124.124.0 [250/0] via 160.160.160.1
123.0.0.0/24 is subnetted, 1 subnets
C 123.123.123.0 is directly connected, Ethernet0
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
*Mar 1 01:21:38.967: %LINK-3-UPDOWN: Interface BRI0:1, changed state to
up.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 36/36/36 ms
Prasit#
*Mar 1 01:21:40.063: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0:1, changed state to up
*Mar 1 01:21:44.991: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
to 6106 Spicey
Prasit#ping 124.124.124.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 124.124.124.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
Prasit#
Serial 1 se torna 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 identificador de conexão de enlace de dados (DLCI). 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 o roteador Cisco ou o servidor de acesso em uma rede Frame Relay. Há duas partes em uma rede Frame Relay:
-
Equipamento de terminal de dados (DTE - Data Terminal Equipment) do Frame Relay - o roteador ou servidor de acesso.
-
Switch de equipamento de terminação de circuito de dados (DCE - Data Circuit Terminating Equipment) Frame Relay.
Observação: no Cisco IOS Software Release 12.1(2)T e Mais Recente, o comando frame route foi substituído pelo comando connect.
Vejamos um exemplo de configuração. Na configuração abaixo, estamos usando o roteador América como um switch Frame Relay. Estamos usando Spicey como um roteador de hub e Prasit e Aton como roteadores spoke. Nós os conectamos da seguinte maneira:
-
Prasit serial 1 (s1) O DTE está conectado ao DCE serial 1/4 (s1/4) americano.
-
O DTE serial 0 (s0) Spicey é conectado ao DCE serial 1/5 (s1/5) da América.
-
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á operando 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 do identificador de conexão de enlace de dados (DLCI) é o processo pelo qual diferentes tipos de tráfego são colocados em DLCIs separados, de modo que uma rede Frame Relay possa fornecer uma taxa de informações comprometidas diferente para cada tipo de tráfego. Ele pode ser usado em conjunto com o enfileiramento personalizado ou com o 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 de Frame Relay e switches de Frame Relay (como os switches Internetwork Packet Exchange [IPX], IGX e BPX ou AXIS da Stratacom) realmente fornecem priorização dentro da nuvem de 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 ficar inativo, você perderá o tráfego destinado somente a 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 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 configurar os DLCIs para que correspondam à 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á operando 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 em Spicey quando você usa o comando acima para telnet para Spicey de 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 importante usado em redes IP ou IPX de médio a grande porte nas quais broadcasts de roteamento e de 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 e uma taxa de serviço configuráveis. Essa fila de broadcast não é usada para atualizações de spanning-tree (BPDUs) 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 de taxa máxima 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 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 garantir a segurança, o tamanho da fila deve ser definido de modo que uma atualização de roteamento completa de cada protocolo e de cada identificador de conexão de link de dados (DLCI) possa ser armazenada. Como regra geral, comece com 20 pacotes por DLCI. A taxa de bytes deve ser menor que:
-
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 será 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 tamanho de fila de 256, 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 forma:
intermitência em excesso mais intermitência comprometida (Bc + Be) = velocidade máxima para o 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 WFQ (Weighted Fair Queue, fila justa ponderada). 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 filtros de token bucket, consulte a Visão geral de vigilância e modelagem.
Este documento fornece uma visão geral da modelagem de tráfego genérica 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ção comprometida (= tempo médio)
-
EIR = taxa de excesso de informação
-
TB = token bucket (= Bc + Be)
-
Bc = tamanho de intermitência confirmado (= tamanho de intermitência sustentado)
-
Be = tamanho de intermitência em excesso
-
DE = elegibilidade para descarte
-
Tc = intervalo de medição
-
AR = taxa de acesso correspondente à taxa da interface física (portanto, se você usar um T1, o AR será de aproximadamente 1,5 Mbps).
Vejamos alguns desses parâmetros com 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 em sua assinatura do provedor de serviços.
Tamanho de Intermitência Confirmado (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. É medida durante a taxa comprometida Tc.
Tamanho de burst excedente (Be)
O número de bits não comprometidos (fora da CIR) que ainda são aceitos pelo switch do Frame Relay, mas são marcados como qualificados para serem descartados (DE).
O token bucket é um buffer 'virtual'. Ele contém vários tokens, permitindo enviar 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 bits Bc + Be na taxa de acesso. Isso não é limitado pelo Tc, mas pelo tempo que leva para enviar o Be. Essa é uma função da taxa de acesso.
Committed Information Rate (CIR)
A CIR é a quantidade de dados permitida que a rede se compromete a transferir em condições normais. A média da taxa é calculada ao longo de um incremento de tempo Tc. A CIR também é chamada de 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 identificador de conexão de link de dados (DLCI). 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, Be e CIR, os valores de entrada e saída 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.
-
Peak = velocidade máxima do DLCI. A largura de banda para esse 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 os quadros acima de Bc com DE, mas têm muita capacidade sobressalente para transportar o quadro. O inverso também é possível: eles podem ter capacidade limitada, mas descartar quadros excessivos imediatamente. As redes podem marcar quadros acima de Bc + Be com DE e possivelmente transportá-los, ou simplesmente descartar os quadros como 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 acelera o tráfego com base em pacotes marcados BECN (Backward-Explicit Congestion Notification) da rede do switch. Se você receber 50 por cento de BECN, o roteador diminui o tráfego em um oitavo da largura de banda atualmente transmitida para aquele 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), fazendo 36,75 Kb. Se o congestionamento diminuir após a alteração, o roteador reduzirá ainda mais o tráfego, caindo para um oitavo da largura de banda atualmente transmitida. O tráfego é reduzido até atingir 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érica é uma ferramenta de modelagem de tráfego independente de encapsulamento e mídia que ajuda a reduzir o fluxo de tráfego de saída quando há congestionamento na nuvem, no link ou no roteador do ponto final receptor. 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) nos locais da filial ou do telecomutador. Devido à incompatibilidade de velocidade, um gargalo geralmente existe para o tráfego na filial ou nos locais de telecomutador quando o local central envia dados em 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 token filter bucket que corresponda ao serviço solicitado por um cliente.
Em sua conexão Frame Relay, você pode desejar que o roteador acelere 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 controle baseado em BECN fornecido com esse recurso permite que você faça com que o roteador controle dinamicamente o tráfego com base no recebimento de pacotes marcados BECN da rede. Esse controle mantém os pacotes nos buffers do roteador para reduzir o fluxo de dados do roteador para a rede do Frame Relay. O roteador acelera 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 [overburst-size]] [group access-list]
Para acelerar os 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 ao receber 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 realmente usada está normalmente entre essas 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 sinais de encaminhamento de notificação explícita de congestionamento (FECN) como BECNs. Isso permite que o roteador na extremidade de alta velocidade detecte e se adapte ao congestionamento mesmo quando o tráfego estiver 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 superior de 256 kbps, você deverá usar o valor de limite superior mais baixo.
Veja o que configuramos nesses 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ê pode especificar apenas uma taxa de pico (limite superior) por interface física e um valor de CIR (limite inferior) por subinterface. Com a modelagem de tráfego do Frame Relay, você inicia um filtro de token bucket por Circuito virtual.
A modelagem de tráfego no recurso 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 para a CIR ou algum outro valor definido, como EIR (Excesso de Taxa de Informação).
-
Suporte BECN generalizado por VC: o roteador pode monitorar BECNs e acelerar o tráfego com base no feedback de pacotes marcados por BECN da rede Frame Relay.
-
Enfileiramento de prioridade (PQ - Priority Queuing), enfileiramento personalizado (CQ - Custom Queuing) ou suporte WFQ no nível VC. Isso permite maior granularidade na priorização e no enfileiramento do tráfego, dando a você mais controle sobre o fluxo de tráfego em um VC individual. A modelagem de tráfego sobre o recurso Frame Relay aplica-se aos Circuitos Virtuais Permanentes (PVCs - Permanent Virtual Circuits) e aos Circuitos Virtuais Comutados (SVCs - Switched Virtual Circuits) 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 passa 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 do frame-relay.
Para exibir um fluxograma que mostre 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 exibir um fluxograma especificamente usando um filtro de token bucket, consulte Modelagem de Tráfego Frame Relay - 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 circuito virtual permanente (PVC), pacotes de entrada e saída, pacotes descartados se houver congestionamento na linha por meio de notificação de congestionamento explícito de encaminhamento (FECN) e notificação de congestionamento explícito de retorno (BECN) e assim por diante. 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 Output Interpreter (somente clientes registrados) para exibir problemas potenciais e correções.
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 USO DE DLCI contém uma das seguintes entradas:
-
SWITCHED - o roteador ou servidor de acesso é usado como um switch.
-
LOCAL - o roteador ou servidor de acesso é usado como equipamento terminal de dados (DTE).
-
NÃO USADO - o identificador de conexão de link 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 PVC STATUS da seguinte maneira:
-
ATIVO - O PVC está ativo e funcionando normalmente.
-
INATIVO - O PVC não é completo. Isso pode ocorrer 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.
-
STATIC - nenhum 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á habilitado para subinterfaces ponto a ponto. É útil somente para interfaces e subinterfaces multiponto. 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 Documentação sobre os comandos do frame relay.
Se você tiver a saída de um comando show frame-relay map de seu dispositivo Cisco, poderá usar Output Interpreter (somente clientes registrados) para exibir problemas potenciais e correções.
Frame relay e bridging
As mensagens de configuração chamadas de unidades de dados de protocolo de ponte (BPDUs - Bridge Protocol Data Units) são usadas nos protocolos spanning-tree suportados em bridges e roteadores Cisco. Esses fluxos ocorrem 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 Digital Equipment Corporation (DEC), o algoritmo foi posteriormente 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 de BPDU de configuração de 35 bytes, um cabeçalho de Frame Relay de 2 bytes, Ethertype de 2 bytes e um FCS de 2 bytes.
Frame Relay e memória
O consumo de memória dos recursos do Frame Relay ocorre em quatro áreas:
-
Cada identificador de conexão de link de dados (DLCI): 216 bytes
-
Cada instrução de mapa: 96 bytes (ou mapa construído dinamicamente)
-
Cada IDB (interface de hardware + encapsulamento de 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:
-
hardware de 2 interfaces IDB x 13.386 = 26.772
-
8 subinterfaces IDB x 2260 = 18.080 subinterfaces
-
8 DLCIs x 216 = 1.728 DLCIs
-
8 instruções de mapa x 96 = 768 instruções de mapa ou dinâmica
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ões 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 ao solucionar 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 ficar ativo quando a CSU, DSU ou modem estiver no modo de loopback local (indicado por uma mensagem "line protocol is up (looped)"), isso sugere que o problema está ocorrendo além da CSU/DSU local. Se a linha de status não mudar de estado, possivelmente há um problema no roteador, cabo de conexão, CSU/DSU ou modem. Na maioria dos casos, o problema está na CSU/DSU ou no modem.
-
Faça ping em seu próprio endereço IP com a CSU/DSU ou modem em loop. Não deve haver erros. Um ping estendido de 0x0000 é útil na resolução de problemas de linha já que 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 pesado de dados zero ajuda a determinar se as transições são forçadas apropriadamente no tronco. Um padrão de uns pesados é usado para simular apropriadamente uma carga de zero alto no caso de haver um par de inversores de dados no caminho. O padrão alternado (0x555) 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), será necessário um testador de taxa de erros de bit (BERT) com um analisador apropriado da telco.
-
Ao concluir o teste, 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 portador do CSU/DSU ou 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 equipamento terminal de dados (DTE), a menos que veja a LMI correta (use o padrão da Cisco para "cisco" LMI). 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 desativou os keepalives, essa linha de saída significa que o roteador está falando 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 identificadores de conexão de link de dados (DLCIs) o provedor provisionou. Para observar a troca, você pode usar com segurança debug frame-relay lmi em quase todas as situações. O comando debug frame-relay lmi gera pouquíssimas 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) assinados 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 (por exemplo, a outra extremidade desse 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 tráfego com esse DLCI no cabeçalho.
-
0x3-0x3 é uma combinação de um status ativo (0x2) e o RNR (ou bit r) que está definido (0x1). Isso significa que foi feito o backup do switch - ou de uma fila específica no switch - para esse PVC, e você interrompe a transmissão caso os quadros sejam despejados.
-
0x4-Deleted significa que o switch do Frame Relay não tem esse DLCI programado para o roteador. Mas foi programado em algum ponto no passado. Isso também pode ser causado pela reversão dos DLCIs no roteador ou pela exclusão do PVC pela empresa de telecomunicações na nuvem do Frame Relay. Configurar um DLCI (que o switch não tem) será exibido 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 pela mesma interface. Os roteadores aprendem os DLCIs (data-link connection identifiers, identificadores de conexão de link de dados) que precisam usar a partir do switch Frame Relay por meio de atualizações da LMI (Local Management Interface, interface de gerenciamento local). Os roteadores 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, ponte transparente e IPX, não podem ser suportados em redes parcialmente em malha porque exigem "split horizon", em que 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 as regras de split horizon. Os pacotes recebidos em uma interface virtual podem agora ser encaminhados para 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 (sub)interfaces multiponto do Frame Relay são não broadcast, (ao contrário das interfaces Ethernet e ponto a ponto High-Level Data Link Control [HDLC]) e subinterfaces ponto a ponto do Frame Relay.
Além disso, você não pode fazer ping de um spoke para outro em uma configuração de hub and spoke. Isso ocorre porque não há mapeamento para seu próprio endereço IP (e nenhum foi aprendido por meio do 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, você poderá fazer ping em 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 sem broadcast que usam 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 um pacote de atualização de roteamento chegar antes de adicionar a rota.
Ao exigir a seleção de um roteador designado, o OSPF trata uma rede multiacesso sem broadcast, como Frame Relay, da mesma maneira que trata uma rede de broadcast. Em versões anteriores, isso exigia 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 nenhum vizinho manualmente. O OSPF agora é executado automaticamente na rede 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 supõe que os endereços IP classe D nunca sejam usados para tráfego regular sobre Frame Relay.
Exemplo
O exemplo a seguir mapeia o endereço IP 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 pode alterá-la sem recarregar. 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 determinados DLCIs são reservados (dependentes da implementação do fornecedor), o máximo é de aproximadamente 1000. O intervalo para uma LMI Cisco é 16-1007. A faixa declarada para ANSI/ITU é 16-992. Esses são os DLCIs que transportam dados de usuário.
No entanto, ao configurar VCs do Frame Relay em subinterfaces, você precisa considerar um limite prático conhecido como limite de IDB. O número total de interfaces e subinterfaces por sistema é limitado pelo número de blocos descritores de interface (IDBs) que sua versão do Cisco IOS suporta. Um 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 um IDB para cada interface presente em uma plataforma e mantém um IDB para cada subinterface. Interfaces de maior velocidade exigem mais memória do que interfaces de menor velocidade. 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 de Software Cisco IOS: Limites de IDB.
Atualização de status da 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, produzindo um máximo de 296 DLCIs por interface. Você pode aumentar a MTU para suportar uma mensagem de atualização de status completo maior do switch do Frame Relay. Se a mensagem de atualização de status completo for maior que a interface MTU, o pacote será descartado e o contador gigante da interface será incrementado. Ao alterar a MTU, certifique-se de que o mesmo valor esteja configurado no roteador remoto e nos dispositivos de rede de intervenção.
Observe que esses números variam um pouco, dependendo do tipo de LMI. Os DLCIs máximos por diretriz de plataforma de roteador (não interface), com base na extrapolação de dados empíricos estabelecidos em uma plataforma de roteador Cisco 7000, estão listados abaixo:
-
Cisco 2500: 1 X link T1/E1 @ 60 DLCIs por interface = total de 60
-
Cisco 4000: 1 X link T1/E1 @ 120 DLCIs por interface = total de 120
-
Cisco 4500: 3 X links T1/E1 @ 120 DLCIs por interface = total de 360
-
Cisco 4700: 4 X links T1/E1 @ 120 DLCIs por interface = total de 480
-
Cisco 7000: 4 X links T1/E1/T3/E3 @ 120 DLCIs por interface = total de 480
-
Cisco 7200: 5 X links T1/E1/T3/E3 @ 120 DLCIs por interface = total de 600
-
Cisco 7500: 6 X links T1/E1/T3/E3 @ 120 DLCIs por interface = total de 720
Observação: esses números são apenas diretrizes e presumem que todo o tráfego é comutado rapidamente.
Outras considerações
Um limite prático de DLCI também depende de os VCs estarem executando um protocolo de roteamento dinâmico ou estático. Protocolos de roteamento dinâmico e outros protocolos como IPX SAP que trocam tabelas de banco de dados, enviam mensagens de saudação e de informações de encaminhamento que devem ser vistas e processadas pela CPU. Como regra geral, o uso de rotas estáticas permitirá configurar um número maior de VCs em uma única interface do Frame Relay.
Endereço IP/IPX/AT
Se estiver usando subinterfaces, não coloque um endereço IP, IPX ou AT na interface principal. Atribua DLCIs às suas subinterfaces antes de ativar a interface principal para garantir que o frame-relay inverse-arp funcione corretamente. Em caso de 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 novamente o comando frame-relay inverse-arp.
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 é de 20 bytes. Portanto, se você anunciar 1.000 rotas em um link do 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 consumidos. Em um link T1, essa largura de banda representa 18,7 por cento da largura de banda, com cada duração de atualização sendo 5,6 segundos. Essa quantidade de sobrecarga é considerável e é aceitável na fronteira, mas a CIR (committed information rate, taxa de informações comprometidas) teria que estar na região da velocidade de acesso. Obviamente, qualquer coisa menor que um T1 causaria 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 de RIP a cada 30 segundos
-
1.072.000 bytes/30 seg X 8 bits = 285 kbps
As atualizações do IGRP (Interior Gateway Routing Protocol) 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 das quais são informações de cabeçalho, e cada entrada de rota é de 14 bytes. Se você anunciar 1.000 rotas em um link do Frame Relay configurado com 50 DLCIs, a solicitação será de aproximadamente 720 KB de dados de atualização de roteamento a cada 90 segundos, ou 64 kbps de largura de banda consumidos. Em um link T1, essa largura de banda representaria 4,2 por cento da largura de banda, com cada duração de atualização sendo 3,7 segundos. Essa sobrecarga é uma quantidade 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 1.000 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 consumidos. Para permanecer dentro de um nível aceitável de sobrecarga de 15 por cento ou menos), é necessária uma taxa de 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 1.000 rotas IPX em um link Frame Relay configurado para 50 DLCIs, o resultado será 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 por cento 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 pacote do 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ê transmitir 1.000 anúncios IPX por um link de Frame Relay configurado para 50 DLCIs, você terminará com 536 KB de atualizações IPX a cada 60 segundos, ou 58,4 kbps de largura de banda consumidos. Para permanecer dentro de um nível aceitável de sobrecarga (15 por cento ou menos), é necessária uma taxa maior que 2 Mbps. Obviamente, a filtragem SAP é necessária nesse cenário. Em comparação com 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 seg X 8 bits = 462 kbps
Manutenção de atividade
Em alguns casos, o keepalive no dispositivo Cisco precisa ser definido um pouco mais curto (cerca de 8 segundos) do que o keepalive no switch. Você verá a necessidade disso se a interface continuar sendo ativada e desativada.
Interfaces seriais
As interfaces seriais, que são, por padrão, multiponto, são meios sem 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 fazer OSPF sobre Frame Relay. O roteador precisa saber que essa é uma interface de broadcast para que o OSPF funcione.
OSPF e multiponto
O OSPF e o 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 conectividade e tentar se tornar um DR, mesmo que outros roteadores ainda vejam o DR antigo. Isso faz com que o processo OSPF funcione incorretamente.
A sobrecarga associada ao OSPF não é tão óbvia e previsível quanto a dos protocolos de roteamento de vetor de distância tradicionais. A imprevisibilidade vem do fato de os links da rede OSPF serem ou não estáveis. Se todas as adjacências de um roteador Frame Relay forem estáveis, apenas os pacotes hello vizinhos (keepalives) fluirão, o que é comparativamente muito menos sobrecarga do que a incorrida com um protocolo de vetor de distância (como RIP e IGRP). Se, no entanto, as rotas (adjacências) forem instáveis, ocorrerá uma inundação de link-state e a largura de banda poderá ser rapidamente consumida. O OSPF também faz uso intensivo do processador ao executar o algoritmo Dijkstra, que é usado para rotas de computação.
Em versões anteriores do software Cisco IOS, era necessário tomar cuidado especial ao configurar o OSPF em mídias não broadcast multiacesso, como Frame Relay, X.25 e ATM. O protocolo OSPF considera esses meios como qualquer outro meio de broadcast, como a Ethernet. Nuvens de multiacesso sem broadcast (NBMA) são normalmente construídas em uma topologia de hub e spoke. Os PVCs ou os Circuitos Virtuais Comutados (SVCs - Switched Virtual Circuits) são dispostos em uma malha parcial e a topologia física não fornece o multiacesso que o OSPF acredita existir. 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 do banco de dados. Para minimizar a quantidade de informações trocadas em um segmento específico, o OSPF elege um roteador para ser um DR e um roteador para ser um roteador designado de backup (BDR) 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 a 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 com o comando neighbor:
neighbor ip-address [priority number] [poll-interval seconds]
Em versões posteriores do software Cisco IOS, métodos diferentes 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 sem broadcast. O método a ser usado é influenciado pelo fato de a rede ser um projeto novo ou 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, pois 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 CCITT Q.922, 19 de abril de 1991.
-
American National Standard For Telecommunications - Integrated Services Digital Network - Core 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. and 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 - Interface usuário-rede (UNI)
-
Interface rede a rede (NNI - Network-to-Network Interface) de Frame Relay FRF 2.1
-
Encapsulamento multiprotocolo FRF 3.1
-
FRF 4-SVCs
-
Gerenciamento de rede de cliente (MIB - Customer Network Management) de serviço de Frame Relay FRF 6
-
Grupo 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 avançada do Enhanced IGRP
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 comandos de backup de discagem
- Mais informações sobre comandos debug ISDN
- Mais informações sobre os comandos de depuração do PPP
- Mais informações sobre tipos, códigos e valores de switch ISDN
- Suporte Técnico e Documentação - Cisco Systems
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)