Contents

Introduction

Antes de Começar

Conventions

Prerequisites

Componentes Utilizados

Material de Suporte

Configurando Frame Relay básico

Diagrama de Rede

Configurações

comandos debug e show

Configurando Frame Relay do tipo “hub and spoke”

Diagrama de Rede

Configurações

comandos show

Conectando-se de raio para raio

Configurações

comandos show

Configurando subinterfaces de frame relay

Subinterfaces de ponto a ponto

comandos show

Subinterfaces Hub e Spoke

comandos show

Configurando os mapeamentos dinâmico e estático para subinterfaces multiponto

Diagrama de Rede

Configurações

comandos debug e show

Configurando Frame Relay com IP não numerado

Diagrama de Rede

Configurações

comandos show

Configurando o backup do Frame Relay

Backup de frame relay sobre ISDN

Configuração por backup de DCLI

Concentrador e ponto remoto com perfis de discagem

Configuração de switching do frame relay

Diagrama de Rede

Configurações

comandos show

Configurando a priorização DLCI do Frame Relay

Considerações de implementação

Diagrama de Rede

Configurações

comandos debug e show

Fila de transmissão do Frame Relay

Modelagem de tráfego

Parâmetros de modelagem de tráfego

Formatação de tráfego genérico

Formatação de tráfego frame relay

Comandos de Frame Relay mais usados

show frame-relay pvc

show frame-relay map

Frame relay e bridging

Frame Relay e memória

Troubleshooting de Frame Relay

"Serial0 is down, line protocol is down"

Serial0 está ativo, o protocolo de linha está inativo

"Serial0 está ativo, o protocolo de linha está ativo"

Características do Frame Relay

Verificação do horizonte de divisão de IP

Execute ping no seu endereço IP em um Frame Relay multiponto

A transmissão de palavra-chave

Reconfigurando uma subinterface

Limitações DLCI

Endereço IP/IPX/AT

RIP e IGRP

Manutenção de atividade

Interfaces seriais

OSPF e multiponto

Origens

Informações Relacionadas

Introduction

O Frame Relay é um protocolo DDL padrão comutado que manipula vários circuitos virtuais usando um encapsulamento de High-Level Data Link Control (HDLC) entre os dispositivos conectados. Em muitos casos, o Frame Relay é mais eficiente do que o X.25, o protocolo para o qual geralmente se considera uma substituição. A seguinte figura ilustra um quadro do Frame Relay (ANSI T1.618).

Observação na figura acima, os endereços Q.922, como definidos atualmente, são dois octetos e contêm um identificador de conexão de enlace de dados (DLCI) de 10 bits. Em algumas redes, os endereços Q.922 podem, opcionalmente, ser aumentados para três ou quatro octetos.

Os campos "flag" delimitam o início e o fim do quadro. Seguindo o campo "flag" inicial estão dois bytes de informações de endereço. Dez bits desses dois bytes compõem o ID do circuito real (chamado DLCI, para identificador de conexão de enlace de dados).

O valor DLCI de 10 bits é o coração do cabeçalho do Frame Relay. Ele identifica a conexão lógica que é multiplexada no canal físico. No modo básico de endereçamento (ou seja, não estendido pela LMI [Local Management Interface Interface de Gerenciamento Local]), os DLCIs têm significado local; ou seja, os dispositivos finais em duas extremidades diferentes de uma conexão podem usar um DLCI diferente para se referir a essa mesma conexão.

Antes de Começar

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Prerequisites

Para obter mais informações e definições para os termos usados neste documento, consulte o Glossário do Frame Relay.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Material de Suporte

O Frame Relay foi originalmente concebido como um protocolo para uso em interfaces ISDN. As primeiras propostas para esse efeito foram apresentadas ao ITU-T (International Telecommunication Union Telecommunications Standardization Setor, Setor de Padronização de Telecomunicações da União Internacional de Telecomunicações) (antigo Comitê Consultivo para Telégrafo Internacional e Telefonia [CCITT]) em 1984. O trabalho no Frame Relay também foi realizado no comitê de padrões T1S1 acreditado pela ANSI nos Estados Unidos.

Em 1990, a Cisco Systems, a StrataCom, a Northern Telecom e a Digital Equipment Corporation formaram um consórcio para concentrar o desenvolvimento da tecnologia Frame Relay e acelerar a introdução de produtos Frame Relay interoperáveis. Eles desenvolveram uma especificação de acordo com o protocolo básico do Frame Relay discutido em T1S1 e ITU-T, mas a ampliaram com recursos que fornecem recursos adicionais para ambientes complexos de interconexão de redes. Essas extensões do Frame Relay são chamadas coletivamente de LMI. Esta é a LMI "cisco" no roteador, ao contrário da LMI "ansi" ou "q933a".

O Frame Relay fornece um recurso de comunicação de dados de comutação de pacotes que é usado na interface entre os dispositivos do usuário (como roteadores, bridges, máquinas host) e o equipamento de rede (como nós de comutação). Os dispositivos do usuário são frequentemente chamados de DTE (Data Terminal Equipment, equipamento terminal de dados), enquanto os equipamentos de rede que fazem interface com DTE são frequentemente chamados de DCE (Data Circuit Terminating Equipment, equipamento terminal de circuito de dados). A rede que fornece a interface do Frame Relay pode ser uma rede pública fornecida pela operadora ou uma rede de equipamentos privados que atendem a uma única empresa.

O Frame Relay difere significativamente do X.25 em sua funcionalidade e formato. Em particular, o Frame Relay é um protocolo mais simplificado, facilitando um desempenho mais alto e uma maior eficiência.

Como uma interface entre o usuário e o equipamento de rede, o Frame Relay fornece um meio para multiplexar estatisticamente muitas conversas de dados lógicos (conhecidos como circuitos virtuais) sobre um único link de transmissão física. Isso contrasta com sistemas que usam apenas técnicas de multiplexação por divisão de tempo (TDM) para suportar vários fluxos de dados. A multiplexação estatística do Frame Relay oferece uso mais flexível e eficiente da largura de banda disponível. Ele pode ser usado sem técnicas TDM ou em cima dos canais fornecidos pelos sistemas TDM.

Outra característica importante do Frame Relay é que ele explora os recentes avanços na tecnologia de transmissão de rede de longa distância (WAN). Os protocolos de WAN anteriores, como o X.25, foram desenvolvidos quando os sistemas de transmissão analógica e os meios de cobre eram predominantes. Esses links são muito menos confiáveis do que os links de transmissão digital/mídia de fibra disponíveis atualmente. Em links como esses, os protocolos da camada de enlace podem renunciar a algoritmos demorados de correção de erros, deixando que esses sejam executados em camadas de protocolo mais altas. Assim, é possível obter mais desempenho e eficiência sem sacrificar a integridade dos dados. O Frame Relay foi projetado pensando nessa abordagem. Ele inclui um algoritmo de verificação de redundância cíclica (CRC - Cyclic Redundancy Check) para a detecção de bits corrompidos (de modo que os dados possam ser descartados), mas não inclui nenhum mecanismo de protocolo para a correção de dados incorretos (por exemplo, retransmitindo-os nesse nível de protocolo).

Outra diferença entre Frame Relay e X.25 é a ausência de controle de fluxo explícito por circuito virtual no Frame Relay. Agora que muitos protocolos de camada superior estão efetivamente executando seus próprios algoritmos de controle de fluxo, a necessidade dessa funcionalidade na camada de enlace diminuiu. O Frame Relay, portanto, não inclui procedimentos explícitos de controle de fluxo que duplicam os nas camadas superiores. Em vez disso, são fornecidos mecanismos muito simples de notificação de congestionamento para permitir que uma rede informe a um dispositivo de usuário que os recursos da rede estão próximos de um estado congestionado. Essa notificação pode alertar os protocolos de camada superior de que o controle de fluxo pode ser necessário.

Configurando Frame Relay básico

Quando você tiver conexões confiáveis com o switch local do Frame Relay em ambas as extremidades do circuito virtual permanente (PVC), é hora de começar a planejar a configuração do Frame Relay. Neste primeiro exemplo, o padrão do tipo de LMI (Local Management Interface, interface de gerenciamento local) é "cisco" LMI em Spicey. Uma interface é, por padrão, uma interface "multiponto", portanto, frame-relay inverse-arp está ativado (para point-to-point, não há ARP inverso). A verificação do split horizon IP é desativada por padrão para o encapsulamento do Frame Relay, de modo que as atualizações de roteamento entram e saem da mesma interface. Os roteadores aprendem os DLCIs (Data-Link Connection Identifiers Identificadores de Conexão de Enlace de Dados) que precisam usar a partir do switch Frame Relay através de atualizações de LMI. Os roteadores, então, Inverse ARP para o endereço IP remoto e criam um mapeamento de DLCIs locais e seus endereços IP remotos associados.

Diagrama de Rede

Configurações

- Spicey

- Prasit

Spicey

Spicey#show running-config

Building configuration...

Current configuration : 1705 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 3.1.3.1 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 140

!

!

router rip

network 3.0.0.0

network 124.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1499 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

!

interface Serial1

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 150

!

!

router rip

network 3.0.0.0

network 123.0.0.0

!

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

comandos debug e show

Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.

- show frame-relay map

- show frame-relay pvc

- show frame-relay lmi

- ping <nome do dispositivo>

- show ip route

Spicey

Spicey#show frame-relay map

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

broadcast,, status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 83            output pkts 87           in bytes 8144

out bytes 8408           dropped pkts 0           in FECN pkts0

in BECN pkts 0           out FECN pkts 0          out BECN pkts0

in DE pkts 0             out DE pkts 0

out bcast pkts 41         out bcast bytes 3652

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

Spicey#show frame-relay lmi

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

Invalid Unnumbered info 0             Invalid Prot Disc 0

Invalid dummy Call Ref 0              Invalid Msg Type 0

Invalid Status Message 0              Invalid Lock Shift 0

Invalid Information ID 0              Invalid Report IE Len 0

Invalid Report Request 0              Invalid Keep IE Len 0

Num Status Enq. Sent 550              Num Status msgs Rcvd 552

Num Update Status Rcvd 0              Num Status Timeouts 0

Spicey#ping 123.123.123.1

Type escape sequence to abort.

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

!!!!!

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

Spicey#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnets

C       3.1.3.0 is directly connected, Serial0

124.0.0.0/24 is subnetted, 1 subnets

C       124.124.124.0 is directly connected, Ethernet0

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

Prasit

Prasit#show frame-relay map

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

broadcast,, status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 87            output pkts 83           in bytes 8408

out bytes 8144           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 38         out bcast bytes 3464

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

Prasit#show frame-relay lmi

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

Invalid Unnumbered info 0             Invalid Prot Disc 0

Invalid dummy Call Ref 0              Invalid Msg Type 0

Invalid Status Message 0              Invalid Lock Shift 0

Invalid Information ID 0              Invalid Report IE Len 0

Invalid Report Request 0              Invalid Keep IE Len 0

Num Status Enq. Sent 569              Num Status msgs Rcvd 570

Num Update Status Rcvd 0              Num Status Timeouts 0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Prasit#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnets

C       3.1.3.0 is directly connected, Serial1

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

123.0.0.0/24 is subnetted, 1 subnets

C       123.123.123.0 is directly connected, Ethernet0

Configurando Frame Relay do tipo “hub and spoke”

Neste exemplo, o roteador aprende quais DLCIs (data-link connection identifiers, identificadores de conexão de enlace de dados) usa do switch Frame Relay e os atribui à interface principal. Em seguida, o roteador fará o Inverse ARP para o endereço IP remoto.

Observação: você não poderá fazer ping do endereço IP serial de Prasit a partir da Aton, a menos que você adicione explicitamente os mapas de Frame Relay em cada extremidade. Se o roteamento estiver configurado corretamente, o tráfego originado nas LANs não deverá ter um problema. Você poderá fazer ping se usar o endereço IP Ethernet como o endereço origem em um ping estendido.

Quando frame-relay inverse-arp está ativado, o tráfego de IP de broadcast sairá pela conexão por padrão.

Diagrama de Rede

Configurações

- Spicey

- Prasit

- Aton

Spicey

spicey#show running-config

Building configuration...

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname spicey

!

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 3.1.3.1 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 130

frame-relay interface-dlci 140

!

!

router rip

network 3.0.0.0

network 124.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

prasit#show running-config

Building configuration...

Current configuration : 1499 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 150

!

!

router rip

network 3.0.0.0

network 123.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Aton

aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname aton

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 160

!

router rip

network 3.0.0.0

network 122.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

comandos show

- show frame-relay map

- show frame-relay pvc

- ping <nome do dispositivo>

Spicey

spicey#show frame-relay map

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

broadcast,, status defined, active

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

broadcast,, status defined, active

spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          2            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 32            output pkts 40           in bytes 3370

out bytes 3928           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 30         out bcast bytes 2888

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

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

input pkts 282           output pkts 291          in bytes 25070

out bytes 27876          dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 223        out bcast bytes 20884

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

spicey#

spicey#ping 3.1.3.2

Type escape sequence to abort.

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

!!!!!

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

spicey#ping 3.1.3.3

Type escape sequence to abort.

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

!!!!!

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

Prasit

prasit#show frame-relay map

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

broadcast,, status defined, active

prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 311           output pkts 233          in bytes 28562

out bytes 22648          dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 162        out bcast bytes 15748

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

prasit#ping 3.1.3.1

Type escape sequence to abort.

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

!!!!!

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

prasit#ping 3.1.3.3

Type escape sequence to abort.

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

.....

Success rate is 0 percent (0/5)

Aton

aton#show frame-relay map

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

broadcast,, status defined, active

aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 35            output pkts 32           in bytes 3758

out bytes 3366           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 27         out bcast bytes 2846

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

aton#ping 3.1.3.1

Type escape sequence to abort.

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

!!!!!

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

aton#ping 3.1.3.2

Type escape sequence to abort.

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

.....

Success rate is 0 percent (0/5)

Conectando-se de raio para raio

Você não pode fazer ping de um spoke para outro em uma configuração de hub e spoke usando interfaces multiponto porque não há mapeamento para os endereços IP dos outros spokes. Somente o endereço do hub é aprendido através do Inverse Address Resolution Protocol (IARP). Se você configurar um mapa estático usando o comando frame-relay map para o endereço IP de um spoke remoto para usar o DLCI (Data Link Connection Identifier Identificador de Conexão de Enlace de Dados) local, poderá fazer ping nos endereços de outros spokes.

Configurações

Prasit

prasit#show running-config

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay map ip 3.1.3.3 150

frame-relay interface-dlci 150

comandos show

- show frame-relay map

- ping <nome do dispositivo>

- show running-config

Prasit

prasit#show frame-relay map

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

broadcast,, status defined, active

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

CISCO, status defined, active

prasit#ping 3.1.3.3

Type escape sequence to abort.

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

!!!!!

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

prasit#ping 122.122.122.1

Type escape sequence to abort.

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

!!!!!

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

Aton

aton#show running-config

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

no ip directed-broadcast

encapsulation frame-relay

frame-relay map ip 3.1.3.2 160

frame-relay interface-dlci 160

aton#show frame-relay map

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

broadcast,, status defined, active

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

CISCO, status defined, active

aton#ping 3.1.3.2

Type escape sequence to abort

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

!!!!!

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

aton#ping 123.123.123.1

Type escape sequence to abort.

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

!!!!!

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

Configurando subinterfaces de frame relay

As subinterfaces do Frame Relay fornecem um mecanismo para suportar redes de Frame Relay parcialmente em malha. A maioria dos protocolos assume transitividade em uma rede lógica; ou seja, se a estação A pode falar com a estação B, e a estação B pode falar com a estação C, então a estação A deve ser capaz de falar diretamente com a estação C. A transitividade é verdadeira em LANs, mas não em redes Frame Relay, a menos que A esteja diretamente conectado a C.

Além disso, certos protocolos, como AppleTalk e bridging transparente, não podem ser suportados em redes parcialmente em malha porque exigem "split horizon" no qual um pacote recebido em uma interface não pode ser transmitido pela mesma interface, mesmo que o pacote seja recebido e transmitido em circuitos virtuais diferentes.

A configuração de subinterfaces de Frame Relay garante que uma única interface física seja tratada como várias interfaces virtuais. Esse recurso nos permite superar regras de split horizon. Os pacotes recebidos em uma interface virtual agora podem ser encaminhados por outra interface virtual, mesmo que estejam configurados na mesma interface física.

As subinterfaces lidam com as limitações das redes Frame Relay, fornecendo uma maneira de subdividir uma rede Frame Relay parcialmente em malha em um número de sub-redes menores, totalmente em malha (ou ponto a ponto). Cada sub-rede recebe seu próprio número de rede e aparece aos protocolos como se fosse alcançável por meio de uma interface separada. (Observe que as subinterfaces ponto-a-ponto podem não ser numeradas para uso com IP, reduzindo a carga de endereçamento que poderia resultar de outra forma).

Subinterfaces de ponto a ponto

Diagrama de Rede

Configurações

- Spicey

- Prasit

Spicey

Spicey#show running-config

Building configuration...

Current configuration : 1338 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

enable password ww

!

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip address 3.1.3.1 255.255.255.0

frame-relay interface-dlci 140

!

!

router igrp 2

network 3.0.0.0

network 124.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1234 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

ip address 3.1.3.2 255.255.255.0

frame-relay interface-dlci 150

!

router igrp 2

network 3.0.0.0

network 123.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

comandos show

- show frame-relay map

- show frame-relay pvc

Spicey

Spicey#show frame-relay map

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

status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          1               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

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

input pkts 193              output pkts 175          in bytes 20450

out bytes 16340             dropped pkts 0           in FECN pkts 0

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

in DE pkts 0                out DE pkts 0

out bcast pkts 50         out    bcast bytes 3786

pvc create time 01:11:27, last time pvc status changed 00:42:32

Spicey#ping 123.123.123.1

Type escape sequence to abort.

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

!!!!!

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

Prasit

Prasit#show frame-relay map

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

status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          1               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

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

Serial1.1

input pkts 74               output pkts 89           in    bytes 7210

out bytes 10963             dropped pkts 0           in    FECN pkts 0

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

in DE pkts 0                out DE pkts 0

out bcast pkts 24           out bcast bytes 4203

pvc create time 00:12:25, last time pvc status changed 00:12:25

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Subinterfaces Hub e Spoke

A seguinte configuração de exemplo de hub e spoke mostra duas subinterfaces ponto a ponto e usa a resolução de endereço dinâmico em um local remoto. Cada subinterface é fornecida com um endereço de protocolo individual e uma máscara de sub-rede, e o comando interface-dlci associa a subinterface a um DLCI (data-link connection identifier, identificador de conexão de link de dados) especificado. Os endereços de destinos remotos para cada subinterface ponto-a-ponto não são resolvidos, pois são ponto-a-ponto e o tráfego deve ser enviado ao peer na outra extremidade. A extremidade remota (Aton) usa o ARP inverso para seu mapeamento e o hub principal responde de acordo com o endereço IP da subinterface. Isso ocorre porque o ARP inverso do Frame Relay está ativado por padrão para interfaces multiponto.

Diagrama de Rede

Configurações

- Spicey

- Prasit

- Aton

Spicey

Spicey#show running-config

Building configuration...

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip address 4.0.1.1 255.255.255.0

frame-relay interface-dlci 140

!

interface Serial0.2 point-to-point

ip address 3.1.3.1 255.255.255.0

frame-relay interface-dlci 130

!

router igrp 2

network 3.0.0.0

network 4.0.0.0

network 124.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

ip address 4.0.1.2 255.255.255.0

frame-relay interface-dlci 150

!

router igrp 2

network 4.0.0.0

network 123.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

!

hostname Aton

!

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 160

!

router igrp 2

network 3.0.0.0

network 122.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

comandos show

- show frame-relay map

- show frame-relay pvc

Spicey

Spicey#show frame-relay map

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

status defined, active

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

status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          2            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 11            output pkts 22           in bytes 1080

out bytes 5128           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 17         out bcast bytes 4608

pvc create time 00:06:36, last time pvc status changed 00:06:36

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

input pkts 33            output pkts 28           in bytes 3967

out bytes 5445           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 17        out bcast bytes 4608

pvc create time 00:06:38, last time pvc status changed 00:06:38

Spicey#ping 122.122.122.1

Type escape sequence to abort.

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

!!!!!

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

Spicey#ping 123.123.123.1

Type escape sequence to abort.

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

!!!!!

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

Prasit

Prasit#show frame-relay map

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

status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

Serial1.1

input pkts 45            output pkts 48           in bytes 8632

out bytes 6661           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 31         out bcast bytes 5573

pvc create time 00:12:16, last time pvc status changed 00:06:23

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Aton

Aton#show frame-relay map

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

broadcast,, status defined, active

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 699           output pkts 634          in bytes 81290

out bytes 67008          dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 528        out bcast bytes 56074

pvc create time 05:46:14, last time pvc status changed 00:05:57

Aton#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Configurando os mapeamentos dinâmico e estático para subinterfaces multiponto

O mapeamento dinâmico de endereços usa o ARP inverso do Frame Relay para solicitar o endereço do protocolo do próximo salto para uma conexão específica, com um identificador de conexão de enlace de dados (DLCI). As respostas às solicitações do Inverse ARP são inseridas em uma tabela de mapeamento de endereço para DLCI no roteador ou no servidor de acesso; a tabela é então usada para fornecer o endereço do protocolo do próximo salto ou o DLCI para tráfego de saída.

Como a interface física agora está configurada como várias subinterfaces, você deve fornecer informações que distingam uma subinterface da interface física e associam uma subinterface específica a um DLCI específico.

O ARP inverso é ativado por padrão para todos os protocolos suportados, mas pode ser desativado para pares específicos de protocolo DLCI. Como resultado, você pode usar o mapeamento dinâmico para alguns protocolos e o mapeamento estático para outros protocolos no mesmo DLCI. Você pode desativar explicitamente o ARP inverso para um par de protocolo-DLCI se souber que o protocolo não é suportado na outra extremidade da conexão. Como o ARP inverso é ativado por padrão para todos os protocolos suportados, nenhum comando adicional é necessário para configurar o mapeamento dinâmico de endereços em uma subinterface. Um mapa estático vincula um endereço de protocolo de próximo salto especificado a um DLCI especificado. O mapeamento estático elimina a necessidade de solicitações ARP inverso; quando você fornece um mapa estático, o ARP inverso é automaticamente desabilitado para o protocolo especificado no DLCI especificado. Você deve usar o mapeamento estático se o roteador na outra extremidade não suportar ARP inverso ou não suportar ARP inverso para um protocolo específico que você deseja usar no Frame Relay.

Diagrama de Rede

Já vimos como configurar um roteador Cisco para fazer ARP inverso. O exemplo a seguir mostra como configurar mapas estáticos caso você precise deles para interfaces ou subinterfaces multiponto:

Configurações

- Aton

- Spicey

- Prasit

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Aton

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 multipoint

ip address 4.0.1.3 255.255.255.0

frame-relay map ip 4.0.1.1 160 broadcast

!

router igrp 2

network 4.0.0.0

network 122.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Spicey

Spicey#show running-config

Building configuration...Current configuration : 1652 bytes!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 4.0.1.1 255.255.255.0

encapsulation frame-relay

frame-relay map ip 4.0.1.2 140 broadcast

frame-relay map ip 4.0.1.3 130 broadcast

!

router igrp 2

network 4.0.0.0

network 124.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1162 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 multipoint

ip address 4.0.1.2 255.255.255.0

frame-relay map ip 4.0.1.1 150 broadcast

!

router igrp 2

network 4.0.0.0

network 123.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

comandos debug e show

- show frame-relay map

- show frame-relay pvc

Aton

Aton#show frame-relay map

Serial1.1 (up): ip 4.0.1.1 dlci 160(0xA0,0x2800), static, broadcast,

CISCO, status defined, active

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

Serial1.1

input pkts 16            output pkts 9            in bytes 3342

out bytes 450            dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 9          out bcast bytes 450

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

Aton#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Spicey

Spicey#show frame-relay map

Serial0 (up): ip 4.0.1.2 dlci 140(0x8C,0x20C0), static, broadcast,

CISCO, status defined, active

Serial0 (up): ip 4.0.1.3 dlci 130(0x82,0x2020), static, broadcast,

CISCO, status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          2            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 9              output pkts 48           in bytes 434

out bytes 11045           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0              out DE pkts 0

out bcast pkts 48         out bcast bytes 11045

pvc create time 00:36:25, last time pvc status changed 00:36:15

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

input pkts 17             output pkts 26           in bytes 1390

out bytes 4195            dropped pkts 0           in FECN pkts 0

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

in DE pkts 0              out DE pkts 0

out bcast pkts 16         out bcast bytes 3155

pvc create time 00:08:39, last time pvc status changed 00:08:39

Spicey#ping 122.122.122.1

Type escape sequence to abort.

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

!!!!!

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

Spicey#ping 123.123.123.1

Type escape sequence to abort.

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

!!!!!

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

Prasit

Prasit#show frame-relay map

Serial1.1 (up): ip 4.0.1.1 dlci 150(0x96,0x2460), static,

broadcast,

CISCO, status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 28            output pkts 19           in bytes 4753

out bytes 1490           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 9         out bcast bytes 450

pvc create time 00:11:00, last time pvc status changed 00:11:00

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Para obter mais informações sobre esses comandos, consulte Comandos do Frame Relay.

Configurando Frame Relay com IP não numerado

Se você não tiver o espaço de endereço IP para usar muitas subinterfaces, poderá usar IP não numerado em cada subinterface. Se for esse o caso, você precisará usar rotas estáticas ou roteamento dinâmico para que o tráfego seja roteado como de costume e deve usar subinterfaces ponto-a-ponto.

Diagrama de Rede

O exemplo abaixo ilustra isso:

Configurações

- Spicey

- Prasit

Spicey

Spicey#show running-config

Building configuration...

Current configuration : 1674 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip unnumbered Ethernet0

frame-relay interface-dlci 140

!

router igrp 2

network 124.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1188 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

ip unnumbered Ethernet0

frame-relay interface-dlci 150

!

router igrp 2

network 123.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

comandos show

- show frame-relay map

- show frame-relay pvc

Spicey

Spicey#show frame-relay map

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

status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

Serial0.1

input pkts 23            output pkts 24           in bytes 3391

out bytes 4952           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 14         out bcast bytes 3912

pvc create time 00:04:47, last time pvc status changed 00:04:47

Spicey#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

124.0.0.0/24 is subnetted, 1 subnets

C       124.124.124.0 is directly connected, Ethernet0

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

I       123.0.0.0/8 [100/8576] via 123.123.123.1, 00:01:11, Serial0.1

I       123.123.123.0/32 [100/8576] via 123.123.123.1, 00:01:11,

Serial0.1

Spicey#ping 123.123.123.1

Type escape sequence to abort.

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

!!!!!

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

Prasit

Prasit#show frame-relay map

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

status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

Serial1.1

input pkts 24            output pkts 52           in bytes 4952

out bytes 10892          dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 41         out bcast bytes 9788

pvc create time 00:10:54, last time pvc status changed 00:03:51

Prasit#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

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

I       124.0.0.0/8 [100/8576] via 124.124.124.1, 00:00:18, Serial1.1

I       124.124.124.0/32 [100/8576] via 124.124.124.1, 00:00:18,

Serial1.1

123.0.0.0/24 is subnetted, 1 subnets

C       123.123.123.0 is directly connected, Ethernet0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Configurando o backup do Frame Relay

Backup de frame relay sobre ISDN

Talvez você queira fazer backup dos circuitos do Frame Relay usando ISDN. Há várias maneiras de fazer isso. A primeira, e provavelmente a melhor, é usar rotas estáticas flutuantes que roteiam o tráfego para um endereço IP BRI (Basic Rate Interface, interface de taxa básica) e usar uma métrica de roteamento apropriada. Você também pode usar uma interface de backup na interface principal ou em uma base por DLCI (data-link connection identifier, identificador de conexão de link de dados). Pode ser pouco útil fazer backup da interface principal porque você pode perder PVCs (Permanent Virtual Circuits, circuitos virtuais permanentes) sem que a interface principal seja desativada. Lembre-se, o protocolo está sendo trocado com o switch Frame Relay local, não com o roteador remoto.

Configurações

- Roteador 1

- Roteador 2

Roteador 1

ROUTER1#

!

hostname ROUTER1

!

username ROUTER2 password same

isdn switch-type basic-dms100

!

interface Ethernet 0

ip address 172.16.15.1 255.255.255.248

!

interface serial 0

ip address 172.16.24.129 255.255.255.128

encapsulation FRAME-RELAY

!

interface BRI0

description Backup ISDN for frame-relay

ip address 172.16.12.1 255.255.255.128

encapsulation PPP

dialer idle-timeout 240

dialer wait-for-carrier-time 60

dialer map IP 172.16.12.2 name ROUTER2 broadcast 7086639706

ppp authentication chap

dialer-group 1

isdn spid1 0127280320 2728032

isdn spid2 0127295120 2729512

!

router igrp 1

network 172.16.0.0

!

ip route 172.16.15.16 255.255.255.248 172.16.12.2 150

!--- Floating static route.

!

access-list 101 deny   igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

dialer-list 1 LIST 101

!

Roteador 2

ROUTER2#

!

hostname ROUTER2

!

username ROUTER1 password same

isdn switch-type basic-dms100

!

interface Ethernet 0

ip address 172.16.15.17 255.255.255.248

!

interface Serial 0

ip address 172.16.24.130 255.255.255.128

encapsulation FRAME-RELAY

!

interface BRI0

description ISDN backup interface for frame-relay

ip address 172.16.12.2 255.255.255.128

encapsulation PPP

dialer idle-timeout 240

dialer map IP 172.16.12.1 name ROUTER1 broadcast

ppp authentication chap

pulse-time 1

dialer-group 1

isdn spid1 0191933333 4445555

isdn spid2 0191933334 4445556

!

router igrp 1

network 172.16.0.0

!

ip route 172.16.15.0 255.255.255.248 172.16.12.1 150

!--- Floating static route.

!

access-list 101 deny   igrp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

access-list 101 permit ip 0.0.0.0 255.255.255.255 162.27.9.0 0.0.0.255

dialer-list 1 LIST 101

!

comandos show

Para verificar se a ISDN está funcionando, use os seguintes comandos debug. Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.

- debug isdn q931

- debug ppp neg

- debug ppp auth

Tente fazer uma chamada ISDN do lado da chamada para o lado central sem os comandos de backup. Se isso for bem-sucedido, adicione os comandos de backup ao lado da chamada.

Observação: para testar o backup, não use o comando shutdown na interface serial, mas emule um problema de linha serial real puxando o cabo da linha serial.

Configuração por backup de DCLI

Agora vamos supor que Spicey é o lado central e que Prasit é o lado fazendo conexões com o lado central (Spicey). Certifique-se de adicionar apenas os comandos de backup ao lado que está chamando o lado central.

Observação: a carga de backup não é suportada em subinterfaces. Como não rastreamos os níveis de tráfego em subinterfaces, nenhuma carga é calculada.

Diagrama de Rede

Configurações

- Spicey

- Prasit

Spicey

Spicey#show running-config

Building configuration...

Current configuration : 1438 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

username Prasit password 0 cisco

!

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip address 4.0.1.1 255.255.255.0

frame-relay interface-dlci 140

!

interface BRI0

ip address 3.1.6.1 255.255.255.0

encapsulation ppp

dialer map ip 3.1.6.2 name Prasit broadcast

dialer-group 1

isdn switch-type basic-net3

no peer default ip address

no cdp enable

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 4.0.0.0

network 124.0.0.0

!

ip classless

ip route 123.123.123.0 255.255.255.0 3.1.6.2 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1245 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

username Spicey password 0 cisco

!

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

backup delay 5 10

backup interface BRI0

ip address 4.0.1.2 255.255.255.0

frame-relay interface-dlci 150

!

interface BRI0

ip address 3.1.6.2 255.255.255.0

encapsulation ppp

dialer map ip 3.1.6.1 name Spicey broadcast 6106

dialer-group 1

isdn switch-type basic-net3

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 4.0.0.0

network 123.0.0.0

!

ip route 124.124.124.0 255.255.255.0 3.1.6.1 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

comandos show

- show frame-relay map

- show ip route

- show isdn history

- show isdn status

- show interface bri 0

- show isdn ative

Spicey

Spicey#show frame-relay map

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

status defined, active

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

status defined, active

Spicey#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 2 subnets C

3.1.3.0 is directly connected, Serial0.2 C

3.1.6.0 is directly connected, BRI0

4.0.0.0/24 is subnetted, 1 subnets C

4.0.1.0 is directly connected, Serial0.1

124.0.0.0/24 is subnetted, 1 subnets C

124.124.124.0 is directly connected, Ethernet0

123.0.0.0/8 is variably subnetted, 2 subnets, 2 masks I

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

123.123.123.0/24 [250/0] via 3.1.6.2 I

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

Spicey#

*Mar  1 00:59:12.527: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

*Mar  1 00:59:13.983: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to up

*Mar  1 00:59:18.547: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6105 Prasit

Spicey#show isdn history

--------------------------------------------------------------------------------

ISDN CALL HISTORY

--------------------------------------------------------------------------------

Call History contains all active calls, and a maximum of 100 inactive calls.

Inactive call data will be retained for a maximum of 15 minutes.

--------------------------------------------------------------------------------

Call    Calling      Called          Remote  Seconds Seconds Seconds

Charges

Type    Number       Number          Name    Used    Left    Idle  Units/Currency

--------------------------------------------------------------------------------

In         6105           6106       Prasit          31      90     29

--------------------------------------------------------------------------------

Spicey#

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

from 6105 Prasit, call lasted 122 seconds

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

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

BRI0:1, changed state to down

Prasit

Prasit#show frame-relay map

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

status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Prasit#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

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

4.0.0.0/24 is subnetted, 1 subnets

C    4.0.1.0 is directly connected, Serial1.1

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

S    124.124.124.0/24 [250/0] via 3.1.6.1

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

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

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

A linha serial cai.

Prasit#

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

*Mar  1 01:23:51.531: %LINEPROTO-5-UPDOWN: Line protocol on Interface

Serial1, changed state to down

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

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

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

*Mar  1 01:23:57.931: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 64 changed to up

Prasit#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

3.0.0.0/24 is subnetted, 1 subnets

C    3.1.6.0 is directly connected, BRI0

124.0.0.0/24 is subnetted, 1 subnets

S    124.124.124.0 [250/0] via 3.1.6.1

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

Prasit#show isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface ISDN Switchtype = basic-net3

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

0 Active Layer 3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask:  0x80000003

Total Allocated ISDN CCBs = 0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!

*Mar  1 01:25:47.383: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up!!!

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

Prasit#

*Mar  1 01:25:48.475: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to up

Prasit#

*Mar  1 01:25:53.407: %ISDN-6-CONNECT: Interface BRI0:1 is now connected

to 6106 Spicey

Prasit#show isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface ISDN Switchtype = basic-net3

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 64, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

1 Active Layer 3 Call(s)

CCB:callid=8003, sapi=0, ces=1, B-chan=1, calltype=DATA

Active dsl 0 CCBs = 1

The Free Channel Mask: 0x80000002

Total Allocated ISDN CCBs = 1

Prasit#show isdn active

--------------------------------------------------------------------------------

ISDN ACTIVE CALLS

--------------------------------------------------------------------------------

Call    Calling      Called          Remote  Seconds Seconds Seconds Charges

Type    Number       Number          Name    Used    Left    Idle    Units/Currency

--------------------------------------------------------------------------------

Out                   6106         Spicey      21     100      19       0

--------------------------------------------------------------------------------

Prasit#

*Mar  1 01:27:49.027: %ISDN-6-DISCONNECT: Interface BRI0:1  disconnected

from 6106 Spicey, call lasted 121 seconds

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

*Mar  1 01:27:50.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface

BRI0:1, changed state to down

*Mar  1 01:28:09.215: %LINK-3-UPDOWN: Interface Serial1, changed state to up

*Mar  1 01:28:10.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface

Serial1, changed state to up

*Mar  1 01:28:30.043: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0,

TEI 64 changed to down

*Mar  1 01:28:30.047: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI

64 changed to down

*Mar  1 01:28:30.371: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode

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

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

Prasit#

A conexão serial está novamente.

Prasit#show isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI0 interface

dsl 0, interface    ISDN Switchtype = basic-net3

Layer 1 Status:

DEACTIVATED

Layer 2 Status:

Layer 2 NOT Activated

Layer 3 Status:

0 Active Layer    3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask:  0x80000003

Total Allocated ISDN CCBs = 0

Prasit#show interface bri 0

BRI0 is standby mode, line protocol is down

Hardware is BRI

Internet address is 3.1.6.2/24

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

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

Encapsulation PPP, loopback not set

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

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

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

Queueing strategy: weighted fair

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

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

Reserved Conversations 0/0 (allocated/max allocated)

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

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

128 packets input, 601 bytes, 0 no buffer

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

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

132 packets output, 687 bytes, 0 underruns

0 output errors, 0 collisions, 10 interface resets

0 output buffer failures, 0 output buffers swapped out

14 carrier transitions

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Concentrador e ponto remoto com perfis de discagem

Aqui está um exemplo de uma configuração de backup de hub e spoke por DLCI. Os roteadores spoke estão chamando o roteador hub. Como você pode ver, permitimos apenas um canal B por lado usando a opção max-link no conjunto de discadores no lado do hub.

Observação: a carga de backup não é suportada em subinterfaces. Como não rastreamos os níveis de tráfego em subinterfaces, nenhuma carga é calculada.

Diagrama de Rede

Configurações

- Aton

- Spicey

- Prasit

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Aton

!

!

username Spicey password 0 cisco

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

ip address 3.1.3.3 255.255.255.0

backup delay 5 10

backup interface BRI0

frame-relay interface-dlci 160

!

interface BRI0

ip address 155.155.155.3 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer map ip 155.155.155.2 name Spicey broadcast 6106

dialer-group 1

isdn switch-type basic-net3

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 122.0.0.0

network 155.155.0.0

!

ip route 124.124.124.0 255.255.255.0 155.155.155.2 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Spicey

Spicey#show running-config

Building configuration...

Current configuration : 1887 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

username Prasit password 0 cisco

username Aton password 0 cisco

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

!

interface Serial0.1 point-to-point

ip address 4.0.1.1 255.255.255.0

frame-relay interface-dlci 140

!

interface Serial0.2 point-to-point

ip address 3.1.3.1 255.255.255.0

frame-relay interface-dlci 130

!

interface BRI0

no ip address

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool-member 2 max-link 1

dialer pool-member 1 max-link 1

isdn switch-type basic-net3

no peer default ip address

no cdp enable

ppp authentication chap

!

interface Dialer1

ip address 160.160.160.1 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool 1

dialer remote-name Prasit

dialer-group 1

ppp authentication chap

!

interface Dialer2

ip address 155.155.155.2 255.255.255.0

encapsulation ppp

no ip route-cache

no ip mroute-cache

dialer pool 2

dialer remote-name Aton

dialer-group 1

ppp authentication chap

!

router igrp 2

network 3.0.0.0

network 4.0.0.0

network 124.0.0.0

network 155.155.0.0

network 160.160.0.0

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1267 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

username Spicey password 0 cisco

!

isdn switch-type basic-net3

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 point-to-point

backup delay 5 10

backup interface BRI0

ip address 4.0.1.2 255.255.255.0

frame-relay interface-dlci 150

!

interface BRI0

ip address 160.160.160.2 255.255.255.0

encapsulation ppp

dialer map ip 160.160.160.1 name Spicey broadcast 6106

dialer-group 1

isdn switch-type basic-net3

ppp authentication chap

!

router igrp 2

network 4.0.0.0

network 123.0.0.0

network 160.160.0.0

!

ip route 124.124.124.0 255.255.255.0 160.160.160.1 250

!

access-list 101 deny   igrp any any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

comandos show

- show frame-relay map

- show ip route

- show frame map

- show frame-relay pvc

Aton

Aton#show frame-relay map

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

status defined, active

Aton#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Aton#show ip route

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

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

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

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

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

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

T - traffic engineered route

Gateway of last resort is not set

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

3.0.0.0/24 is subnetted, 1 subnets

C    3.1.3.0 is directly connected, Serial1.1

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

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

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

S    124.124.124.0/24 [250/0] via 155.155.155.2

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

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

122.0.0.0/24 is subnetted, 1 subnets

C    122.122.122.0 is directly connected, Ethernet0

Aton#

Serial 1 está caindo.

Aton#

01:16:33: %LINK-3-UPDOWN: Interface Serial1, changed state to down

01:16:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,

changed state to down

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

01:16:37: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

01:16:37: %LINK-3-UPDOWN: Interface BRI0, changed state to up

01:16:41: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 64 changed to up

Aton#show ip route

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

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

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

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

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

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

T - traffic engineered route

Gateway of last resort is not set

155.155.0.0/24 is subnetted, 1 subnets

C    155.155.155.0 is directly connected, BRI0

124.0.0.0/24 is subnetted, 1 subnets

S    124.124.124.0 [250/0] via 155.155.155.2

122.0.0.0/24 is subnetted, 1 subnets

C    122.122.122.0 is directly connected, Ethernet0

Aton#ping 124.124.124.1

Type escape sequence to abort.

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

01:21:33: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up.!!!!

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

Aton#

01:21:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,

changed state to up

01:21:39: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 6106

Spicey

Aton#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Aton#

Serial 1 torna-se ativo novamente

Aton#

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

Spicey, call lasted 149 seconds

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

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

changed state to down

Aton#show frame map

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

status deleted

Aton#

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

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

changed state to up

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

to down

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

to down

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

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

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

Aton#show frame map

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

status defined, active

Aton#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Aton#ping 124.124.124.1

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          1               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

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

Serial1.1

input pkts 60               output pkts 69           in    bytes 9694

out bytes 10811             dropped pkts 0           in    FECN pkts 0

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

in DE pkts 0                out DE pkts 0

out bcast pkts 44         out    bcast bytes 7565

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

Spicey

Spicey#show frame-relay map

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

status defined, active

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

status defined, active

Spicey#ping 122.122.122.1

Type escape sequence to abort.

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

!!!!!

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

Spicey#ping 123.123.123.1

Type escape sequence to abort.

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

!!!!!

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

Spicey#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

155.155.0.0/24 is subnetted, 1 subnets

C    155.155.155.0 is directly connected, Dialer2

3.0.0.0/24 is subnetted, 1 subnets

C    3.1.3.0 is directly connected, Serial0.2

4.0.0.0/24 is subnetted, 1 subnets

C    4.0.1.0 is directly connected, Serial0.1

160.160.0.0/24 is subnetted, 1 subnets

C    160.160.160.0 is directly connected, Dialer1

124.0.0.0/24 is subnetted, 1 subnets

C    124.124.124.0 is directly connected, Ethernet0

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

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

Ambas as linhas seriais dos lados da chamada estão ficando inoperantes.

Spicey#

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

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

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

BRI0:1, changed state to up

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

to 6104 Aton

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

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

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

BRI0:2, changed state to up

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

to 6105 Prasit

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

profile Di2

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

from 6104 Aton, call lasted 149 seconds

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

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

BRI0:1, changed state to down

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

profile Di1

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

from 6105 Prasit, call lasted 142 seconds

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

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

BRI0:2, changed state to down

Spicey#show frame map

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

status defined, inactive

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

status defined, inactive

Spicey#

As duas linhas seriais estão disponíveis novamente.

Spicey#show frame pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          2               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

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

Serial0.2

input pkts 54               output pkts 61           in    bytes 7014

out bytes 9975              dropped pkts 3           in    FECN pkts 0

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

in DE pkts 0                out DE pkts 0

out bcast pkts 40         out    bcast bytes 7803

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

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

Serial0.1

input pkts 56               output pkts 60           in    bytes 7604

out bytes 10114             dropped pkts 2           in    FECN pkts 0

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

in DE pkts 0                out DE pkts 0

out bcast pkts 39           out    bcast bytes 7928

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

Prasit

Prasit#show frame-relay map

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

status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Prasit#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

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

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

4.0.0.0/24 is subnetted, 1 subnets

C    4.0.1.0 is directly connected, Serial1.1

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

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

S    124.124.124.0/24 [250/0] via 160.160.160.1

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

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

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

Prasit#

Serial 1 desliga.

Prasit#

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

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

Serial1, changed state to down

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

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

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

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

64 changed to up

Prasit#show ip route

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

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

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

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

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

inter area

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

P - periodic downloaded static route

Gateway of last resort is not set

160.160.0.0/24 is subnetted, 1 subnets

C    160.160.160.0 is directly connected, BRI0

124.0.0.0/24 is subnetted, 1 subnets

S    124.124.124.0 [250/0] via 160.160.160.1

123.0.0.0/24 is subnetted, 1 subnets

C    123.123.123.0 is directly connected, Ethernet0

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

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

up.!!!!

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

Prasit#

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

BRI0:1, changed state to up

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

to 6106 Spicey

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Prasit#

Serial 1 torna-se ativo novamente.

Prasit#

*Mar  1 01:26:40.579: %LINK-3-UPDOWN: Interface Serial1, changed state to up

*Mar  1 01:26:41.579: %LINEPROTO-5-UPDOWN: Line protocol on Interface

Serial1, changed state to up

*Mar  1 01:27:01.051: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BRI0,

TEI 64 changed to down

*Mar  1 01:27:01.055: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI

64 changed to down

*Mar  1 01:27:01.363: %LINK-5-CHANGED: Interface BRI0, changed state to standby mode

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

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

Prasit#show frame map

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

status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted          Static

Local          1               0            0               0

Switched       0               0            0               0

Unused         0               0            0               0

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

Serial1.1

input pkts 58               output pkts 66           in    bytes 9727

out bytes 10022             dropped pkts 0           in    FECN pkts 0

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

in DE pkts 0                out DE pkts 0

out bcast pkts 46         out    bcast bytes 7942

pvc create time 01:27:37, last time pvc status changed 00:01:59

Configuração de switching do frame relay

A comutação Frame Relay é um meio de comutação de pacotes com base no DLCI (Data-Link Connection Identifier Identificador de Conexão de Enlace de Dados). Podemos considerar isso como o equivalente do Frame Relay de um endereço de Controle de Acesso ao Meio (MAC - Media Access Control). Você executa a comutação configurando seu roteador ou servidor de acesso Cisco em uma rede Frame Relay. Há duas partes em uma rede Frame Relay:

- Equipamento terminal de dados (DTE - Data Terminal Equipment) do Frame Relay - o roteador ou o servidor de acesso.

- Switch de equipamento de terminação de circuito de dados (DCE) do Frame Relay.

Observação: no Cisco IOS Software Release 12.1(2)T ou posterior, o comando frame route foi substituído pelo comando connect.

Vamos ver um exemplo de configuração. Na configuração abaixo, estamos usando o roteador América como um switch Frame Relay. Estamos usando o Spicey como um roteador de hub e o Prasit e o Aton como roteadores de spoke. Nós os conectamos da seguinte maneira:

- O DTE serial 1 (s1) da Prasit está conectado ao DCE serial 1/4 (s1/4) da América.

- O DTE serial 0 (s0) da amostra está conectado ao DCE serial 1/5 (s1/5) da América.

- O Aton serial 1 (s1) DTE está conectado ao DCE serial 3/4 (s3/4) da América.

Diagrama de Rede

Este documento é baseado na seguinte configuração:

Configurações

- Spicey

- Prasit

- Aton

- América

Spicey

Spicey#show running-config

Building configuration...

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Spicey

!

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

ip address 3.1.3.1 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 130

frame-relay interface-dlci 140

!

!

router rip

network 3.0.0.0

network 124.0.0.0

!

line con 0

!

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

Current configuration : 1499 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.2 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 150

!

!

router rip

network 3.0.0.0

network 123.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Aton

Aton#show running-config

Building configuration...

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Aton

!

!

!

interface Ethernet0

ip address 122.122.122.1 255.255.255.0

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

encapsulation frame-relay

frame-relay interface-dlci 160

!

router rip

network 3.0.0.0

network 122.0.0.0

!

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

América

america#show running-config

Building configuration...

Current configuration:

!

!

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname america

!

frame-relay switching

!

!

interface Serial1/4

description *** static DCE connection to s1 Prasit

no ip address

encapsulation frame-relay

clockrate 2000000

frame-relay intf-type dce

frame-relay route 150 interface Serial1/5 140

!

interface Serial1/5

description *** static DCE connection to s0 spicy

no ip address

encapsulation frame-relay

bandwidth 1000000

tx-queue-limit 100

frame-relay intf-type dce

frame-relay route 130 interface Serial3/4 160

frame-relay route 140 interface Serial1/4 150

transmitter-delay 10

!

interface Serial3/4

description *** static DCE connection to s1 Aton

encapsulation frame-relay

no ip mroute-cache

clockrate 2000000

frame-relay intf-type dce

frame-relay route 160 interface Serial1/5 130

!

comandos show

Use os seguintes comandos show para testar se sua rede está funcionando corretamente:

- show frame-relay map

- show frame-relay pvc

A saída mostrada abaixo é resultado da digitação desses comandos nos dispositivos que estamos usando nesta configuração de exemplo.

Spicey

Spicey#show frame-relay map

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

broadcast,, status defined, active

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

broadcast,, status defined, active

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted            Static

Local          2                 0            0                 0

Switched       0                 0            0                 0

Unused         0                 0            0                 0

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

input pkts 32                 output pkts 40                in bytes 3370

out bytes 3928                dropped pkts 0                in FECN pkts 0

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

in DE pkts 0                  out DE pkts 0

out bcast pkts 30             out bcast bytes 2888

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

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

input pkts 282                output pkts 291          in bytes 25070

out bytes 27876               dropped pkts 0           in FECN pkts 0

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

in DE pkts 0                  out DE pkts 0

out bcast pkts 223            out bcast bytes 20884

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

Prasit

Prasit#show frame-relay map

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

broadcast,, status defined, active

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted            Static

Local          1                 0            0                 0

Switched       0                 0            0                 0

Unused         0                 0            0

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

input pkts 311                output pkts 233          in bytes 28562

out bytes 22648               dropped pkts 0           in FECN pkts 0

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

in DE pkts 0                  out DE pkts 0

out bcast pkts 162            out bcast bytes 15748

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

Aton

Aton#show frame-relay map

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

Aton#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted            Static

Local          1                 0            0                 0

Switched       0                 0            0                 0

Unused         0                 0            0                 0

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

input pkts 35                 output pkts 32                in bytes 3758

out bytes 3366                dropped pkts 0                in FECN pkt 0

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

in DE pkts 0                  out DE pkts 0

out bcast pkts 27 out bcast bytes 2846

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

Configurando a priorização DLCI do Frame Relay

A priorização de DLCI (Data-Link Connection Identifier) é o processo pelo qual diferentes tipos de tráfego são colocados em DLCIs separados para que uma rede Frame Relay possa fornecer uma taxa de informação comprometida diferente para cada tipo de tráfego. Ele pode ser usado em conjunto com enfileiramento personalizado ou enfileiramento de prioridade para fornecer controle de gerenciamento de largura de banda sobre o link de acesso à rede do Frame Relay. Além disso, alguns provedores de serviços do Frame Relay e switches Frame Relay (como os switches Stratacom Internetwork Packet Exchange [IPX], IGX e BPX ou AXIS) realmente fornecem priorização na nuvem do Frame Relay com base nessa configuração de prioridade.

Considerações de implementação

Ao implementar a priorização de DLCI, observe os seguintes pontos:

- Se um DLCI secundário cair, você perderá o tráfego destinado apenas para essa fila.

- Se você perder o DLCI principal, a subinterface será desativada e você perderá todo o tráfego.

Diagrama de Rede

Para usar essa configuração, você precisa ter quatro DLCIs para o lado que usará a priorização de DLCI. Neste exemplo, configuramos o Spicey para o enfileiramento de prioridade da seguinte maneira:

- O ping está na fila de alta prioridade.

- O Telnet está na fila de prioridade média.

- O FTP está na fila de prioridade normal.

- Todo o tráfego IP restante está na fila de baixa prioridade.

Observação: certifique-se de que você configure os DLCIs para corresponderem à lista de prioridades ou o sistema não usará a fila correta.

Configurações

- Spicey

- Prasit

Spicey

Spicey#show running-config

Building configuration...

Current configuration : 1955 bytes

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

!

hostname Spicey

!

!

interface Ethernet0

ip address 124.124.124.1 255.255.255.0

!

interface Serial0

no ip address

encapsulation frame-relay

priority-group 1

!

interface Serial0.1 point-to-point

ip address 4.0.1.1 255.255.255.0

frame-relay priority-dlci-group 1 140 180 190 200

frame-relay interface-dlci 140

!

router igrp 2

network 4.0.0.0

network 124.0.0.0

!

access-list 102 permit icmp any any

priority-list 1 protocol ip high list 102

priority-list 1 protocol ip medium tcp telnet

priority-list 1 protocol ip normal tcp ftp

priority-list 1 protocol ip low

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

Prasit

Prasit#show running-config

Building configuration...

!

version 12.1

service timestamps debug datetime msec

service timestamps log datetime msec

!

hostname Prasit

!

!

!

interface Ethernet0

ip address 123.123.123.1 255.255.255.0

!

interface Serial1

ip address 4.0.1.2 255.255.255.0

encapsulation frame-relay

!

router igrp 2

network 4.0.0.0

network 123.0.0.0

!

line con 0

exec-timeout 0 0

transport input none

line aux 0

line vty 0 4

login

!

end

comandos debug e show

Use os seguintes comandos show e debug para testar se sua rede está funcionando corretamente. Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.

- show frame-relay pvc

- show frame-relay map

- show queueing priority

- debug priority

A saída mostrada abaixo é resultado da digitação desses comandos nos dispositivos que estamos usando nesta configuração de exemplo.

Spicey

Spicey#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          4            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 106           output pkts 15           in bytes 6801

out bytes 1560           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 0         out bcast bytes 0

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

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

DLCI 190 (NORMAL), DLCI 200 (LOW)

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

input pkts 0             output pkts 51           in bytes 0

out bytes 2434           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 0         out bcast bytes 0

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

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

input pkts 0             output pkts 13           in bytes 0

out bytes 3653           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 13        out bcast bytes 3653

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

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

input pkts 0             output pkts 42           in bytes 0

out bytes 2554           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 10        out bcast bytes 500

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

Spicey#show frame-relay map

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

status defined, active

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

DLCI 190 (NORMAL), DLCI 200 (LOW)

Spicey#show queueing priority

Current priority queue configuration:

List   Queue  Args

1      high   protocol ip          list 102

1      medium protocol ip          tcp port telnet

1      normal protocol ip          tcp port ftp

1      low    protocol ip

Para verificar a fila de prioridade, use o comando debug priority.

Spicey#debug priority

Priority output queueing debugging is on

Spicey#ping 123.123.123.1

Type escape sequence to abort.

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

!!!!!

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

Spicey#

*Mar  1 00:32:30.391: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.395: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

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

*Mar  1 00:32:30.439: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.443: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

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

*Mar  1 00:32:30.487: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.491: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

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

*Mar  1 00:32:30.535: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.539: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

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

*Mar  1 00:32:30.583: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.587: PQ: Serial0: ip (s=4.0.1.1, d=123.123.123.1) ->high

*Mar  1 00:32:30.587: PQ: Serial0 output (Pk size/Q 104/0)Spicey#

Spicey#telnet 123.123.123.1

Trying 123.123.123.1 ... Open

User Access Verification

Password:

*Mar  1 00:32:59.447: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.451: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.451: PQ: Serial0 output (Pk size/Q 48/1)

*Mar  1 00:32:59.475: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.479: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.483: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:32:59.487: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.487: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.491: PQ: Serial0 output (Pk size/Q 53/1)

*Mar  1 00:32:59.495: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.499: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.499: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:32:59.511: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.511: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.515: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:32:59.519: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.519: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.523: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:32:59.527: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.527: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.531: PQ: Serial0 output (Pk size/Q 53/1)

*Mar  1 00:32:59.539: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.543: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.547: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:32:59.751: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.755: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:32:59.755: PQ: Serial0 output (Pk size/Q 44/1)

Password:

Outro tráfego IP passa pela fila baixa.

Spicey#

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

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

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

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

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

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

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

Spicey#

Prasit

Prasit#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

Active     Inactive      Deleted       Static

Local          1            0            0            0

Switched       0            0            0            0

Unused         0            0            0            0

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

input pkts 134           output pkts 119          in bytes 12029

out bytes 7801           dropped pkts 0           in FECN pkts 0

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

in DE pkts 0             out DE pkts 0

out bcast pkts 18         out bcast bytes 1260

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

Prasit#show frame-relay map

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

broadcast, status defined, active

Prasit#ping 124.124.124.1

Type escape sequence to abort.

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

!!!!!

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

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

Spicey#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Prasit#telnet 124.124.124.1

Trying 124.124.124.1 ... Open

User Access Verification

Password:

Spicey>exit

[Connection to 124.124.124.1 closed by foreign host]

Prasit#

Aqui está a saída de depuração mostrada no Spicey quando você usa o comando acima para executar telnet para Spicey a partir do Prasit.

Spicey#

*Mar  1 00:33:54.499: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.499: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.503: PQ: Serial0 output (Pk size/Q 48/1)

*Mar  1 00:33:54.527: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.531: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.531: PQ: Serial0 output (Pk size/Q 56/1)

*Mar  1 00:33:54.547: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.551: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.555: PQ: Serial0 output (Pk size/Q 86/1)

*Mar  1 00:33:54.559: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.563: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.563: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:33:54.571: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.575: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.575: PQ: Serial0 output (Pk size/Q 47/1)

*Mar  1 00:33:54.779: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.783: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:54.783: PQ: Serial0 output (Pk size/Q 44/1)

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

*Mar  1 00:33:57.143: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.143: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.147: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:33:57.447: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.447: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.451: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:33:57.899: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.899: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:57.903: PQ: Serial0 output (Pk size/Q 53/1)

*Mar  1 00:33:59.491: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.495: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.495: PQ: Serial0 output (Pk size/Q 45/1)

*Mar  1 00:33:59.711: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.715: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.715: PQ: Serial0 output (Pk size/Q 45/1)

*Mar  1 00:33:59.951: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.951: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:33:59.955: PQ: Serial0 output (Pk size/Q 45/1)

*Mar  1 00:34:00.123: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.123: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.127: PQ: Serial0 output (Pk size/Q 45/1)

*Mar  1 00:34:00.327: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.327: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.331: PQ: Serial0 output (Pk size/Q 46/1)

*Mar  1 00:34:00.495: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.499: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.499: PQ: Serial0 output (Pk size/Q 44/1)

*Mar  1 00:34:00.543: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.543: PQ: Serial0: ip (tcp 23) -> medium

*Mar  1 00:34:00.547: PQ: Serial0 output (Pk size/Q 44/1)

Fila de transmissão do Frame Relay

A fila de broadcast é um recurso principal usado em redes IP ou IPX de médio a grande porte em que os broadcasts de roteamento e ponto de acesso de serviço (SAP) devem fluir pela rede Frame Relay. A fila de broadcast é gerenciada independentemente da fila de interface normal, tem seus próprios buffers e tem um tamanho configurável e uma taxa de serviço. Essa fila de broadcast não é usada para atualizações de spanning tree (BPDUs) de bridging devido a sensibilidades de temporização. Esses pacotes fluirão pelas filas normais. O comando de interface para ativar a fila de broadcast é o seguinte:

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

Uma fila de broadcast recebe um limite máximo de taxa de transmissão (throughput) medido em bytes por segundo e pacotes por segundo. A fila é servida para garantir que apenas esse máximo seja fornecido. A fila de broadcast tem prioridade ao transmitir a uma taxa abaixo do máximo configurado e, portanto, tem uma alocação de largura de banda mínima garantida. Os dois limites de taxa de transmissão têm como objetivo evitar a inundação da interface com broadcasts. O limite real em qualquer segundo é o primeiro limite de taxa que é atingido. Dada a restrição da taxa de transmissão, é necessário um buffer adicional para armazenar pacotes de broadcast. A fila de broadcast é configurável para armazenar grandes números de pacotes de broadcast. O tamanho da fila deve ser definido para evitar a perda de pacotes de atualização de roteamento de broadcast. O tamanho exato depende do protocolo sendo usado e do número de pacotes necessários para cada atualização. Para ser seguro, o tamanho da fila deve ser definido de modo que uma atualização de roteamento completa de cada protocolo e para cada DLCI (Data-Link Connection Identifier, identificador de conexão de enlace de dados) possa ser armazenada. Como regra geral, comece com 20 pacotes por DLCI. A taxa de bytes deve ser menor do que ambas as seguintes:

- N/4 vezes a taxa mínima de acesso remoto (medida em bytes por segundo), onde N é o número de DLCIs aos quais a transmissão deve ser replicada

- 1/4 da taxa de acesso local (medida em bytes por segundo)

A taxa de pacotes não é crítica se a taxa de bytes for definida de forma conservadora. Em geral, a taxa de pacotes deve ser definida supondo pacotes de 250 bytes. Os padrões para as interfaces seriais são 64 tamanhos de fila, 256.000 bytes por segundo (2.048.000 bps) e 36 pps. Os padrões para as interfaces seriais de alta velocidade (HSSI) são 256 tamanhos de fila, 1.024.000 bytes por segundo (8.192.000 bps) e 144 pps.

Modelagem de tráfego

A modelagem de tráfego usa um mecanismo de controle de taxa chamado de filtro de token bucket. Esse filtro de token bucket é definido da seguinte maneira:

intermitência em excesso mais intermitência comprometida (Bc + Be) = velocidade máxima do circuito virtual (VC)

O tráfego acima da velocidade máxima é colocado em buffer em uma fila de modelagem de tráfego que é igual ao tamanho da fila de espera ponderada (WFQ). O filtro Token Bucket não filtra o tráfego, mas controla a taxa na qual o tráfego é enviado na interface de saída. Para obter mais informações sobre os filtros de token bucket, consulte a Visão geral de policiamento e modelagem.

Este documento fornece uma visão geral da modelagem de tráfego genérico e da modelagem de tráfego do Frame Relay.

Parâmetros de modelagem de tráfego

Podemos usar os seguintes parâmetros de modelagem de tráfego:

- CIR = taxa de informações comprometidas (= tempo médio)

- EIR = excesso de taxa de informação

- TB = token bucket (= Bc + Be)

- Bc = tamanho de intermitência comprometida (= tamanho de intermitência sustentada)

- Be = tamanho de intermitência em excesso

- DE = elegibilidade de descarte

- Tc = intervalo de medição

- AR = taxa de acesso correspondente à taxa da interface física (portanto, se você usa um T1, o AR é aproximadamente 1,5 Mbps).

Vejamos alguns desses parâmetros em mais detalhes:

Taxa de acesso (AR)

O número máximo de bits por segundo que uma estação final pode transmitir para a rede é limitado pela taxa de acesso da interface usuário-rede. A velocidade da linha da conexão de rede do usuário limita a taxa de acesso. Você pode estabelecer isso na sua assinatura do provedor de serviços.

Tamanho De Intermitência Comprometida (Bc)

A quantidade máxima comprometida de dados que você pode oferecer à rede é definida como Bc. Bc é uma medida para o volume de dados para o qual a rede garante a entrega de mensagens em condições normais. Ele é medido durante a taxa comprometida Tc.

Tamanho de burst excedente (Be)

O número de bits não comprometidos (fora do CIR) que ainda são aceitos pelo switch Frame Relay, mas que são marcados como elegíveis para descarte (DE).

O token bucket é um buffer 'virtual'. Ele contém vários tokens, permitindo que você envie uma quantidade limitada de dados por intervalo de tempo. O token bucket é preenchido com bits Bc por Tc. O tamanho máximo do bucket é Bc + Be. Se o Be for muito grande e, se em T0 o bucket for preenchido com tokens Bc + Be, você poderá enviar Bc + Be bits à taxa de acesso. Isso não é limitado pelo Tc, mas pelo tempo necessário para enviar o Be. Esta é uma função da taxa de acesso.

Committed Information Rate (CIR)

A CIR é a quantidade permitida de dados que a rede está comprometida a transferir em condições normais. A taxa é média ao longo de um incremento de tempo Tc. A CIR também é conhecida como throughput mínimo aceitável. Bc e Be são expressos em bits, Tc em segundos e a taxa de acesso e CIR em bits por segundo.

Bc, Be, Tc e CIR são definidos por DLCI (Data-Link Connection Identifier Identificador de Conexão de Enlace de Dados). Devido a isso, o filtro de token bucket controla a taxa por DLCI. A taxa de acesso é válida por interface usuário-rede. Para Bc, os valores de entrada e saída Be e CIR podem ser diferenciados. Se a conexão for simétrica, os valores em ambas as direções serão os mesmos. Para circuitos virtuais permanentes, definimos Bc, Be e CIR de entrada e saída no momento da assinatura.

- Pico = velocidade máxima do DLCI. A largura de banda desse DLCI específico.

- Tc = Bc / CIR

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

Se o Tc for um segundo então:

- Pico = CIR + Be = Bc + Be

- EIR = Be

No exemplo que estamos usando aqui, o roteador envia tráfego entre 48 Kbps e 32 Kbps, dependendo do congestionamento na rede. As redes podem marcar quadros acima de Bc com DE, mas têm capacidade sobressalente suficiente para transportar o quadro. O contrário também é possível: eles podem ter capacidade limitada, mas descartam quadros excessivos imediatamente. As redes podem marcar quadros acima de Bc + Be com DE, e possivelmente transportá-los, ou simplesmente descartar os quadros conforme sugerido pela especificação ITU-T I.370 do Setor de Padronização de Telecomunicações da União Internacional de Telecomunicações. A modelagem de tráfego restringe o tráfego com base em pacotes marcados com BECN (notificação de congestionamento explícito para trás) da rede do switch. Se você receber 50% de BECN, o roteador diminuirá o tráfego em um oitavo da largura de banda transmitida atual para esse DLCI específico.

Exemplo

A velocidade transmitida é de 42 Kb. O roteador diminui a velocidade para 42 menos 42 dividido por 8 (42 - 42/8), tornando 36,75 Kb. Se o congestionamento diminuir após a alteração, o roteador reduz ainda mais o tráfego, caindo para um oitavo da largura de banda transmitida atual. O tráfego é reduzido até alcançar o valor CIR configurado. No entanto, a velocidade pode cair sob a CIR quando ainda podemos ver BECNs. Você pode especificar um limite inferior, como CIR/2. A rede não está mais congestionada quando todos os quadros recebidos da rede não têm mais um bit BECN para um determinado intervalo de tempo. 200 ms é o valor padrão para esse intervalo.

Formatação de tráfego genérico

O recurso de modelagem de tráfego genérico é uma ferramenta de modelagem de tráfego independente de mídia e encapsulamento que ajuda a reduzir o fluxo de tráfego de saída quando há congestionamento na nuvem, no link ou no roteador de endpoint de recepção. Podemos defini-lo em interfaces ou subinterfaces dentro de um roteador.

A modelagem de tráfego genérica é útil nas seguintes situações:

- Quando você tem uma topologia de rede que consiste em uma conexão de alta velocidade (velocidade da linha T1) no local central e conexões de baixa velocidade (menos de 56 kbps) nas filiais ou nos locais de trabalho remoto. Devido à incompatibilidade de velocidade, geralmente existe um gargalo para o tráfego nas filiais ou nos locais de trabalho remoto quando o local central envia dados a uma taxa mais rápida que os locais remotos podem receber. Isso resulta em um gargalo no último switch antes do roteador de ponto remoto.

- Se você for um provedor de serviços que oferece serviços de subtaxa, esse recurso permitirá que você use o roteador para particionar seus links T1 ou T3, por exemplo, em canais menores. Você pode configurar cada subinterface com um bucket de filtro de token que corresponda ao serviço solicitado por um cliente.

Na conexão do Frame Relay, você pode querer que o roteador controle o tráfego em vez de enviá-lo para a rede. Limitar o tráfego limitaria a perda de pacotes na nuvem do provedor de serviços. O recurso de limitação baseado em BECN fornecido com esse recurso permite que você tenha o roteador dinamicamente acelerando o tráfego com base no recebimento de pacotes rotulados de BECN da rede. Essa limitação mantém os pacotes nos buffers do roteador para reduzir o fluxo de dados do roteador para a rede do Frame Relay. O roteador limita o tráfego em uma base de subinterface, e a taxa também é aumentada quando menos pacotes marcados com BECN são recebidos.

Comandos para modelagem de tráfego genérico

Para definir o controle de taxa, use este comando:

traffic-shape rate bit-rate [burst-size [excesso-burst-size]] [group access-list]

Para acelerar BECNs em uma interface do Frame Relay, use este comando:

traffic-shape adaptive [bit-rate]

Para configurar uma subinterface do Frame Relay para estimar a largura de banda disponível quando ele recebe BECNs, use o comando traffic-shape adaptive.

Observação: você deve habilitar a modelagem de tráfego na interface com o comando traffic-shape rate antes de usar o comando traffic-shape adaptive.

A taxa de bits especificada para o comando traffic-shape rate é o limite superior, e a taxa de bits especificada para o comando traffic-shape adaptive é o limite inferior (geralmente o valor CIR) no qual o tráfego é modelado quando a interface recebe BECNs. A taxa efetivamente utilizada situa-se normalmente entre estas duas taxas. Você deve configurar o comando traffic-shape adaptive em ambas as extremidades do link, pois ele também configura o dispositivo na extremidade do fluxo para refletir os sinais FECN (forward Explicit Congestion Notification, notificação explícita de congestionamento de encaminhamento) como BECNs. Isso permite que o roteador na extremidade de alta velocidade detecte e se adapte ao congestionamento mesmo quando o tráfego está fluindo principalmente em uma direção.

Exemplo

O exemplo a seguir configura a modelagem de tráfego na interface 0.1 com um limite superior (geralmente Bc + Be) de 128 kbps e um limite inferior de 64 kbps. Isso permite que o link seja executado de 64 a 128 kbps, dependendo do nível de congestionamento. Se o lado central tiver um limite máximo de 256 kbps, você deve usar o valor de limite máximo mais baixo.

Veja o que configuramos nestes roteadores:

Central#

interface serial 0

encapsulation-frame-relay

interface serial 0.1

traffic-shape rate 128000

traffic-shape adaptive 64000

Client#

interface serial 0

encapsulation-frame-relay

interface serial 0.1

traffic-shape rate 128000

traffic-shape adaptive 64000

Formatação de tráfego frame relay

Com a modelagem de tráfego genérica, você só pode especificar uma taxa de pico (limite superior) por interface física e um valor CIR (limite inferior) por subinterface. Com a modelagem de tráfego do Frame Relay, você inicia um filtro de token bucket por circuito virtual.

O recurso de modelagem de tráfego sobre Frame Relay fornece os seguintes recursos:

- Aplicação de taxa por VC: Você pode configurar uma taxa de pico para limitar o tráfego de saída à CIR ou a algum outro valor definido, como a EIR (excesso de taxa de informações).

- Suporte BECN generalizado por VC: O roteador pode monitorar BECNs e limitar o tráfego com base no feedback de pacotes marcados com BECN da rede do Frame Relay.

- Enfileiramento de prioridade (PQ), enfileiramento personalizado (CQ) ou suporte a WFQ no nível de VC. Isso permite uma melhor granularidade na priorização e enfileiramento do tráfego, dando a você mais controle sobre o fluxo de tráfego em um VC individual. O recurso de modelagem de tráfego sobre Frame Relay se aplica a PVCs (Permanent Virtual Circuits, circuitos virtuais permanentes) e SVCs (Switched Virtual Circuits, circuitos virtuais comutados) do Frame Relay.

Exemplo

Interface Serial 0

no ip address

encapsulation frame-relay

frame-relay traffic-shaping

!

interface Serial0.100

ip address 1.1.1.1 255.255.255.252

frame-relay interface-dlci 100

frame-relay class fast

!

interface Serial0.200

ip address 1.1.1.5 255.255.255.252

frame-relay interface-dlci 200

frame-relay class slow

!

map-class frame-relay slow

frame-relay traffic-rate 64000 128000

!

map-class

frame-relay fast

frame-relay traffic-rate 16000 64000

!

Neste exemplo, o roteador adiciona dois token-buckets.

- Um executa entre 64000 (CIR) e 128000 (Bc + Be).

- O outro é executado entre 16000 (CIR) e 64000 (Bc + Be).

Se o tráfego de entrada da Ethernet for maior que o filtro de token bucket, o tráfego será colocado em buffer na fila de tráfego frame-relay.

Para ver um fluxograma mostrando o fluxo de pacotes quando você implementa a modelagem de tráfego do Frame Relay, consulte Fluxograma de modelagem de tráfego do Frame Relay. Para ver um fluxograma especificamente usando um filtro de token bucket, consulte Frame Relay Traffic Shaping - Fluxograma de Token Bucket.

Comandos de Frame Relay mais usados

Esta seção descreve dois comandos do Cisco IOS® que são especialmente úteis na configuração do Frame Relay.

show frame-relay pvc

Esse comando mostra o status do PVC (Permanent Virtual Circuit, circuito virtual permanente), pacotes de entrada e saída, pacotes descartados se houver congestionamento na linha por meio da FECN (Forward Explicit Congestion Notification, notificação de congestionamento explícito de encaminhamento) e BECN (Back Explicit Congestion Notification, notificação de congestionamento explícito de retorno) etc. Para obter uma descrição detalhada dos campos usados com o comando show frame-relay pvc, clique aqui.

Se você tiver a saída de um comando show frame-relay pvc de seu dispositivo Cisco, poderá usar o Output Interpreter (somente clientes registrados) para exibir problemas e correções potenciais.

Você pode usar o Output Interpreter (somente clientes registrados) para exibir possíveis problemas 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 DLCI USAGE contém uma das seguintes entradas:

- SWITCHED - o roteador ou o servidor de acesso é usado como um switch.

- LOCAL - o roteador ou o servidor de acesso é usado como DTE (Data Terminal Equipment, equipamento terminal de dados).

- UNUSED - o identificador de conexão de enlace de dados (DLCI) não é referenciado pelos comandos de configuração inseridos pelo usuário no roteador.

O PVC pode ter quatro estados possíveis. Eles são mostrados pelo campo STATUS do PVC da seguinte maneira:

- ATIVE (ATIVO) - O PVC está ativo e funcionando normalmente.

- INATIVO - o PVC não está completo. Isso pode ser porque não há mapeamento (ou mapeamento incorreto) para o DLCI local na nuvem do frame-relay ou a extremidade remota do PVC é Excluída.

- EXCLUÍDO - A LMI (Local Management Interface, interface de gerenciamento local) não é trocada entre o roteador e o switch local, ou o switch não tem DLCI configurado no switch local.

- ESTÁTICO - sem keepalive configurado na interface frame-relay do roteador.

show frame-relay map

Use este comando para determinar se frame-relay inverse-arp resolveu um endereço IP remoto para um DLCI local. Esse comando não está ativado para subinterfaces ponto a ponto. É útil somente para interfaces multiponto e subinterfaces. Uma saída de exemplo é mostrada abaixo:

RouterA#show frame-relay map

Serial0 (up): ip 157.147.3.65 dlci 980(0x3D4,0xF440), dynamic,

broadcast,, status defined, active

Para obter uma descrição detalhada dos campos usados com o comando show frame-relay map, consulte Documentation on frame relay Commands.

Se você tiver a saída de um comando show frame-relay map de seu dispositivo Cisco, poderá usar o Output Interpreter (somente clientes registrados) para exibir problemas e correções potenciais.

Você pode usar o Output Interpreter (somente clientes registrados) para exibir possíveis problemas e correções.

Frame relay e bridging

As mensagens de configuração chamadas BPDUs (Bridge Protocol Data Units, unidades de dados de protocolo de ponte) são usadas nos protocolos spanning tree suportados em bridges e roteadores da Cisco. Esses fluxos em intervalos regulares entre pontes e constituem uma quantidade significativa de tráfego devido à sua ocorrência frequente. Há dois tipos de protocolos spanning-tree em bridging transparente. Introduzido pela DEC (Digital Equipment Corporation), o algoritmo foi subsequentemente revisado pelo comitê IEEE 802 e publicado na especificação IEEE 802.1d. O DEC Spanning-Tree Protocol emite BPDUs em intervalos de um segundo, enquanto o IEEE emite BPDUs em intervalos de dois segundos. Cada pacote tem 41 bytes, o que inclui uma mensagem BPDU de configuração de 35 bytes, um cabeçalho Frame Relay de 2 bytes, Ethertype de 2 bytes e FCS de 2 bytes.

Frame Relay e memória

O consumo de memória para recursos do Frame Relay ocorre em quatro áreas:

1. Cada identificador de conexão de enlace de dados (DLCI): 216 bytes

2. Cada declaração de mapa: 96 bytes (ou mapa dinamicamente construído)

3. Cada IDB (interface de hardware + encap Frame Relay): 5040 + 8346 = 13.386 bytes

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

Por exemplo, um Cisco 2501 usando duas interfaces Frame Relay, cada uma com quatro subinterfaces, com um total de oito DLCIs e mapas associados, precisa do seguinte:

- IDB de hardware de 2 interfaces x 13.386 = 26.772

- 8 subinterfaces IDB x 2260 = 18.080 subinterfaces

- 8 DLCIs x 216 = 1728 DLCIs

- 8 instruções de mapa x 96 = 768 instruções ou dinâmica de mapa

O total é igual a 47.348 bytes de RAM usados.

Observação: os valores usados aqui são válidos para o software Cisco IOS versão 11.1, 12.0 e 12.1.

Troubleshooting de Frame Relay

Esta seção contém partes da possível saída do comando show interface que você pode encontrar durante a solução de problemas. Também são fornecidas explicações sobre a saída.

"Serial0 is down, line protocol is down"

Essa saída significa que você tem um problema com o cabo, a unidade de serviço de canal/unidade de serviço de dados (CSU/DSU) ou a linha serial. Você precisa solucionar o problema com um teste de loopback. Para fazer um teste de loopback, siga as etapas abaixo:

1. 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.

2. Coloque a CSU/DSU ou o modem no modo de loop local. Se o protocolo de linha for ativado quando a CSU, DSU ou modem estiver no modo de loopback local (indicado por uma mensagem "line protocol is up (looped)"), ele sugerirá que o problema está ocorrendo além da CSU/DSU local. Se a linha de status não alterar os estados, é possível que haja um problema no roteador, conectando cabo, CSU/DSU ou modem. Na maioria dos casos, o problema está na CSU/DSU ou no modem.

3. Faça ping no seu próprio endereço IP com a CSU/DSU ou modem em loop. Não deve haver falhas. Um ping estendido de 0x0000 é útil na resolução de problemas de linha, pois um T1 ou E1 deriva o relógio dos dados e exige uma transição a cada 8 bits. B8ZS garante isso. Um padrão de dados zero pesado ajuda a determinar se as transições são forçadas adequadamente no tronco. Um padrão de uns pesados é usado para simular adequadamente uma carga zero alta, caso haja um par de inversores de dados no caminho. O padrão alternado (0x5555) representa um padrão de dados "típico". Se os pings falharem ou se você receber erros de verificação de redundância cíclica (CRC), é necessário um testador de taxa de erro de bit (BERT) com um analisador apropriado da empresa de telecomunicações.

4. Quando terminar de testar, certifique-se de devolver o encapsulamento ao Frame Relay.

Serial0 está ativo, o protocolo de linha está inativo

Essa linha na saída significa que o roteador está recebendo um sinal de portadora da CSU/DSU ou do modem. Verifique se o provedor do Frame Relay ativou a porta e se as configurações da LMI (Local Management Interface, interface de gerenciamento local) correspondem. Geralmente, o switch do Frame Relay ignora o DTE (Data Terminal Equipment, equipamento terminal de dados), a menos que veja a LMI correta (use o padrão da Cisco para a LMI "Cisco"). Verifique se o roteador Cisco está transmitindo dados. Provavelmente, você precisará verificar a integridade da linha usando testes de loop em vários locais, começando com a CSU local e trabalhando para sair até chegar ao switch Frame Relay do provedor. Consulte a seção anterior para saber como executar um teste de loopback.

"Serial0 está ativo, o protocolo de linha está ativo"

Se você não desligou os keepalives, essa linha de saída significa que o roteador está conversando com o switch do provedor do Frame Relay. Você deve estar vendo uma troca bem-sucedida de tráfego bidirecional na interface serial sem erros de CRC. Os keepalives são necessários no Frame Relay porque são o mecanismo que o roteador usa para "aprender" quais DLCIs (data-link connection identifiers, identificadores de conexão de enlace de dados) o provedor provisionou. Para assistir à troca, você pode usar com segurança debug frame-relay lmi em quase todas as situações. O comando debug frame-relay lmi gera muito poucas mensagens e pode fornecer respostas a perguntas como:

1. O roteador Cisco está se comunicando com o switch local do Frame Relay?

2. O roteador está recebendo mensagens de status de LMI completas para PVCs (Permanent Virtual Circuits, circuitos virtuais permanentes) subscritos do provedor do Frame Relay?

3. 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:

1. 0x0-Added/inative significa que o switch tem esse DLCI programado, mas por algum motivo (como a outra extremidade deste PVC está inativa), ele não é utilizável.

2. 0x2-Added/ative significa que o switch Frame Relay tem o DLCI e tudo está operacional. Você pode começar a enviar o tráfego com este DLCI no cabeçalho.

3. 0x3-0x3 é uma combinação de um status ativo (0x2) e o RNR (ou r-bit) definido (0x1). Isso significa que o backup do switch - ou de uma fila específica no switch - para esse PVC é feito, e você pára de transmitir em caso de derramamento de quadros.

4. 0x4-Deleted significa que o switch Frame Relay não tem esse DLCI programado para o roteador. Mas foi programado em algum momento do passado. Isso também pode ser causado pela reversão dos DLCIs no roteador ou pela exclusão do PVC pela telco na nuvem do Frame Relay. A configuração de um DLCI (que o switch não tem) será exibida como 0x4.

5. 0x8-Novo/inativo

6. 0x0a-Novo/ativo

Características do Frame Relay

Esta seção explica várias características do Frame Relay das quais você deve estar ciente.

Verificação do horizonte de divisão de IP

A verificação do split horizon IP é desativada por padrão para o encapsulamento do Frame Relay, de modo que as atualizações de roteamento entrarão e sairão da mesma interface. Os roteadores aprendem os DLCIs (Data-Link Connection Identifiers Identificadores de Conexão de Enlace de Dados) que precisam usar a partir do switch Frame Relay através de atualizações da LMI (Local Management Interface, Interface de Gerenciamento Local). Os roteadores então usam o ARP inverso para o endereço IP remoto e criam um mapeamento de DLCIs locais e seus endereços IP remotos associados. Além disso, certos protocolos como AppleTalk, transparent bridging e IPX não podem ser suportados em redes parcialmente em malha porque exigem "split horizon", no qual um pacote recebido em uma interface não pode ser transmitido pela mesma interface, mesmo que o pacote seja recebido e transmitido em circuitos virtuais diferentes. A configuração de subinterfaces de Frame Relay garante que uma única interface física seja tratada como várias interfaces virtuais. Esse recurso nos permite superar regras de split horizon. Os pacotes recebidos em uma interface virtual agora podem ser encaminhados por outra interface virtual, mesmo que estejam configurados na mesma interface física.

Execute ping no seu endereço IP em um Frame Relay multiponto

Você não pode fazer ping em seu próprio endereço IP em uma interface de Frame Relay multiponto. Isso ocorre porque as subinterfaces multiponto (sub)Frame Relay são não broadcast, (diferentemente das interfaces Ethernet e ponto-a-ponto HDLC) e sub-interfaces ponto-a-ponto Frame Relay.

Além disso, você não pode fazer ping de um spoke para outro em uma configuração de hub e spoke. Isso ocorre porque não há mapeamento para seu próprio endereço IP (e nenhum foi aprendido via ARP inverso). Mas se você configurar um mapa estático (usando o comando frame-relay map) para seu próprio endereço IP (ou um para o spoke remoto) para usar o DLCI local, poderá então fazer ping nos seus dispositivos.

aton#ping  3.1.3.3

Type escape sequence to abort.

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

.....

Success rate is 0 percent (0/5)

aton#configure terminal

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

aton(config)#interface serial 1

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

aton(config-if)#

aton#show frame-relay map

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

broadcast,, status defined, active

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

CISCO, status defined, active

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

CISCO, status defined, active

aton#ping 3.1.3.3

Type escape sequence to abort.

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

!!!!!

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

aton#

aton#show running-config

!

interface Serial1

ip address 3.1.3.3 255.255.255.0

no ip directed-broadcast

encapsulation frame-relay

frame-relay map ip 3.1.3.2 160

frame-relay map ip 3.1.3.3 160

frame-relay interface-dlci 160

!

A transmissão de palavra-chave

A palavra-chave broadcast fornece duas funções: encaminha broadcasts quando o multicast não está habilitado e simplifica a configuração do OSPF (Open Shortest Path First) para redes não broadcast que usam o Frame Relay.

A palavra-chave broadcast também pode ser necessária para alguns protocolos de roteamento — por exemplo, AppleTalk — que dependem de atualizações regulares da tabela de roteamento, especialmente quando o roteador na extremidade remota está esperando que um pacote de atualização de roteamento chegue antes de adicionar a rota.

Ao exigir a seleção de um roteador designado, o OSPF trata uma rede multiacesso não broadcast, como o Frame Relay, da mesma forma que trata uma rede de broadcast. Nas versões anteriores, isso exigia a atribuição manual na configuração do OSPF usando o comando neighbor interface router. Quando o comando frame-relay map é incluído na configuração com a palavra-chave broadcast, e o comando ip ospf network (com a palavra-chave broadcast) é configurado, não há necessidade de configurar qualquer vizinho manualmente. O OSPF agora é executado automaticamente na rede do Frame Relay como uma rede de broadcast. (Consulte o comando ip ospf network interface para obter mais detalhes.)

Observação: o mecanismo de broadcast OSPF pressupõe que os endereços IP classe D nunca são usados para tráfego regular sobre Frame Relay.

Exemplo

O exemplo a seguir mapeia o endereço IP de destino 172.16.123.1 para DLCI 100:

interface serial 0

frame-relay map IP 172.16.123.1 100 broadcast

O OSPF usa DLCI 100 para transmitir atualizações.

Reconfigurando uma subinterface

Depois de criar um tipo específico de subinterface, você não poderá alterá-la sem um recarregamento. Por exemplo, você não pode criar uma subinterface serial0.2 multiponto e, em seguida, alterá-la para ponto a ponto. Para alterá-lo, você precisa recarregar o roteador ou criar outra subinterface. É assim que o código do Frame Relay funciona no software Cisco IOS®.

Limitações DLCI

Espaço de endereço DLCI

Aproximadamente 1000 DLCIs podem ser configurados em um único link físico, dado um endereço de 10 bits. Como alguns DLCIs são reservados (dependente de fornecedor-implementação-dependente), o máximo é cerca de 1000. O intervalo para uma LMI da Cisco é 16-1007. O intervalo declarado para ANSI/ITU é 16-992. Esses são os DLCIs que transportam dados de usuário.

No entanto, ao configurar VCs de Frame Relay em subinterfaces, você precisa considerar um limite prático conhecido como limite IDB. O número total de interfaces e subinterfaces por sistema é limitado pelo número de blocos descritores de interface (IDBs) suportados pela sua versão do Cisco IOS. Uma IDB é uma parte da memória que contém informações sobre a interface, como contadores, status da interface e assim por diante. O IOS mantém uma IDB para cada interface presente em uma plataforma e mantém uma IDB para cada subinterface. As interfaces de velocidade mais alta exigem mais memória do que as interfaces de velocidade mais baixa. Cada plataforma contém quantidades diferentes de IDBs máximos e esses limites podem mudar com cada versão do Cisco IOS.

Para obter mais informações, consulte Número máximo de interfaces e subinterfaces para plataformas do software Cisco IOS: Limites de IDB.

Atualização de status LMI

O protocolo LMI requer que todos os relatórios de status do circuito virtual permanente (PVC) caibam em um único pacote e geralmente limita o número de DLCIs para menos de 800, dependendo do tamanho da unidade de transmissão máxima (MTU).

O MTU padrão nas interfaces seriais é de 1500 bytes, resultando em um máximo de 296 DLCIs por interface. Você pode aumentar o MTU para suportar uma mensagem de atualização de status completo maior do switch Frame Relay. Se a mensagem de atualização de status completa for maior que o MTU da interface, o pacote será descartado e o contador gigante da interface será incrementado. Ao alterar o MTU, assegure-se de que o mesmo valor seja configurado no roteador remoto e nos dispositivos de rede que intervêm.

Observe que esses números variam um pouco, dependendo do tipo de LMI. A diretriz máxima de DLCIs por roteador (não interface), baseada na extrapolação de dados empíricos estabelecidos em uma plataforma de roteador Cisco 7000, está listada abaixo:

- Cisco 2500: 1 link T1/E1 a 60 DLCIs por interface = total de 60

- Cisco 4000: 1 link T1/E1 a 120 DLCIs por interface = total de 120

- Cisco 4500: 3 X links T1/E1 a 120 DLCIs por interface = total de 360

- Cisco 4700: 4 links T1/E1 a 120 DLCIs por interface = total de 480

- Cisco 7000: 4 links T1/E1/T3/E3 a 120 DLCIs por interface = total de 480

- Cisco 7200: 5 links T1/E1/T3/E3 a 120 DLCIs por interface = total de 600

- Cisco 7500: 6 links T1/E1/T3/E3 a 120 DLCIs por interface = total de 720

Observação: esses números são somente diretrizes e supõem que todo o tráfego seja comutado rapidamente.

Outras considerações

Um limite prático de DLCI também depende se os VCs estão executando um protocolo de roteamento dinâmico ou estático. Os protocolos de roteamento dinâmico e outros protocolos como o IPX SAP que trocam tabelas de banco de dados, enviam mensagens hello e de informações de encaminhamento que devem ser vistas e processadas pela CPU. Como regra geral, o uso de rotas estáticas permitirá que você configure um número maior de VCs em uma única interface do Frame Relay.

Endereço IP/IPX/AT

Se você estiver usando subinterfaces, não coloque um endereço IP, IPX ou AT na interface principal. Atribua DLCIs às suas subinterfaces antes de habilitar a interface principal para garantir que o frame-relay inverse-arp funcione corretamente. Se ocorrer um mau funcionamento, siga as etapas abaixo:

1. 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.

2. Corrija sua configuração.

3. Ative o comando frame-relay inverse-arp novamente.

RIP e IGRP

As atualizações do Routing Information Protocol (RIP) fluem a cada 30 segundos. Cada pacote RIP pode conter até 25 entradas de rota, para um total de 536 bytes; 36 bytes desse total são informações de cabeçalho e cada entrada de rota é 20 bytes. Portanto, se você anunciar 1.000 rotas sobre um link Frame Relay configurado para 50 DLCIs, o resultado será 1 MB de dados de atualização de roteamento a cada 30 segundos, ou 285 kbps de largura de banda consumida. Em um link T1, essa largura de banda representa 18,7% da largura de banda, com cada duração de atualização sendo de 5,6 segundos. Essa quantidade de sobrecarga é considerável e é aceitável na linha de fronteira, mas a taxa de informação comprometida (CIR) teria que estar na região da velocidade de acesso. Obviamente, qualquer coisa menor que um T1 teria muita sobrecarga. Por exemplo:

- 1000/25 = 40 pacotes X 36 = 1440 bytes de cabeçalho

- 1000 X 20 bytes = 20.000 bytes de entradas de rota

- Total de 21.440 bytes X 50 DLCIs = 1072 MB de atualizações do RIP a cada 30 segundos

- 1.072.000 bytes / 30 seg X 8 bits = 285 kbps

As atualizações do Interior Gateway Routing Protocol (IGRP) fluem a cada 90 segundos (esse intervalo é configurável). Cada pacote IGRP pode conter 104 entradas de rota, para um total de 1492 bytes, 38 dos quais são informações de cabeçalho e cada entrada de rota é de 14 bytes. Se você anunciar 1.000 rotas sobre um link Frame Relay configurado com 50 DLCIs, a solicitação é aproximadamente 720 KB de dados de atualização de roteamento a cada 90 segundos, ou 64 kbps de largura de banda consumida. Em um link T1, essa largura de banda representaria 4,2% da largura de banda, com cada duração de atualização sendo 3,7 segundos. Essa sobrecarga é um valor aceitável:

- 1000/104 = 9 pacotes X 38 = 342 bytes de cabeçalho

- 1000 X 14 = 14.000 bytes de entradas de rota

- Total = 14.342 bytes X 50 DLCIs = 717 KB de atualizações IGRP a cada 90 segundos

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

As atualizações de roteamento do Routing Table Maintenance Protocol (RTMP) ocorrem a cada 10 segundos (esse intervalo é configurável). Cada pacote RTMP pode conter até 94 entradas de rota estendida, para um total de 564 bytes, 23 bytes de informações de cabeçalho e cada entrada de rota é de 6 bytes. Se você anunciar 1000 redes AppleTalk em um link Frame Relay configurado para 50 DLCIs, o resultado será aproximadamente 313 KB de atualizações RTMP a cada 10 segundos, ou 250 kbps de largura de banda consumida. Para permanecer dentro de um nível aceitável de sobrecarga de 15% ou menos), é necessária uma taxa T1. Por exemplo:

- 1000/94 = 11 pacotes X 23 bytes = 253 bytes de cabeçalho

- 1000 X 6 = 6000 bytes de entradas de rota

- Total = 6253 X 50 DLCIs = 313 KB de atualizações RTMP a cada 10 segundos

- 313.000 / 10 seg X 8 bits = 250 kbps

As atualizações de pacotes RIP IPX ocorrem a cada 60 segundos (esse intervalo é configurável). Cada pacote RIP IPX pode conter até 50 entradas de rota para um total de 536 bytes, 38 bytes de informações de cabeçalho e cada entrada de rota é de 8 bytes. Se você anunciar rotas 1000 IPX sobre um link Frame Relay configurado para 50 DLCIs, o resultado é 536 KB de atualizações IPX a cada 60 segundos, ou 58,4 kbps de largura de banda consumida. Para permanecer dentro de um nível aceitável de sobrecarga (15% ou menos), é necessária uma taxa de 512 kbps. Por exemplo:

- 1000/50 = 20 pacotes X 38 bytes = 760 bytes de cabeçalho

- 1000 X 8 = 8000 bytes de entradas de rota

- Total = 8760 X 50 DLCIs = 438.000 bytes de atualizações IPX a cada 60 segundos

- 438.000 / 60 seg X 8 bits = 58,4 kbps

As atualizações de pacotes de ponto de acesso de serviço (SAP) IPX ocorrem a cada 60 segundos (esse intervalo é configurável). Cada pacote SAP IPX pode conter até sete entradas de anúncio para um total de 536 bytes, 38 bytes de informações de cabeçalho e cada entrada de anúncio é de 64 bytes. Se você difundir 1000 anúncios IPX em um link Frame Relay configurado para 50 DLCIs, você terminaria com 536 KB de atualizações IPX a cada 60 segundos, ou 58,4 kbps de largura de banda consumida. Para permanecer dentro de um nível aceitável de sobrecarga (15% ou menos), é necessária uma taxa maior que 2 Mbps. Obviamente, a filtragem SAP é necessária neste cenário. Comparadas a todos os outros protocolos mencionados nesta seção, as atualizações IPX SAP exigem a maior largura de banda:

- 1000/7 = 143 pacotes X 38 bytes = 5434 bytes de cabeçalho

- 1000 X 64 = 64.000 bytes de entradas de rota

- Total = 69.434 X 50 DLCIs = 3.471.700 bytes de anúncios de serviço IPX a cada 60 segundos

- 3.471.700 / 60 s X 8 bits = 462 kbps

Manutenção de atividade

Em alguns casos, a manutenção de atividade no dispositivo Cisco precisa ser definida como um pouco mais curta (cerca de 8 segundos) do que a manutenção de atividade no switch. Você verá a necessidade disso se a interface continuar ativa e inativa.

Interfaces seriais

As interfaces seriais, que são por padrão multiponto, são meios não broadcast, enquanto as subinterfaces ponto-a-ponto são broadcast. Se estiver usando rotas estáticas, você poderá apontar para o próximo salto ou para a subinterface serial. Para multiponto, você precisa apontar para o próximo salto. Esse conceito é muito importante ao se fazer OSPF sobre Frame Relay. O roteador precisa saber que essa é uma interface de broadcast para que o OSPF funcione.

OSPF e multiponto

OSPF e multiponto podem ser muito problemáticos. O OSPF precisa de um roteador designado (DR). Se você começar a perder PVCs, alguns roteadores podem perder a conectividade e tentar se tornar um DR, mesmo que outros roteadores ainda vejam o antigo DR. Isso faz com que o processo OSPF não funcione corretamente.

A sobrecarga associada ao OSPF não é tão óbvia e previsível quanto a protocolos de roteamento de vetor de distância tradicionais. A imprevisibilidade vem da estabilidade ou não dos links de rede OSPF. Se todas as adjacências a um roteador Frame Relay forem estáveis, somente os pacotes de saudação vizinhos (keepalives) fluirão, o que é comparativamente muito menos sobrecarga do que o incorrido com um protocolo de vetor de distância (como RIP e IGRP). No entanto, se as rotas (adjacências) forem instáveis, ocorrerá inundação de link-state e a largura de banda poderá ser consumida rapidamente. O OSPF também usa muito o processador ao executar o algoritmo Dijkstra, que é usado para rotas de computação.

Nas versões anteriores do software Cisco IOS, foi necessário ter cuidado especial ao configurar o OSPF em meios não broadcast multiacesso, como Frame Relay, X.25 e ATM. O protocolo OSPF considera esses meios como qualquer outro meio de transmissão, como a Ethernet. As nuvens de NBMA (Nonbroadcast Multiaccess, multiacesso sem broadcast) normalmente são construídas em uma topologia de hub e spoke. PVCs ou circuitos virtuais comutados (SVCs) são dispostos em uma malha parcial e a topologia física não fornece o multiacesso que o OSPF acredita que existe. Para o caso de interfaces seriais ponto-a-ponto, o OSPF sempre forma uma adjacência entre os vizinhos. As adjacências OSPF trocam informações de banco de dados. Para minimizar a quantidade de informações trocadas em um segmento específico, o OSPF escolhe um roteador como DR e um roteador como BDR (Backup Designated Router, roteador designado de backup) em cada segmento multiacesso. O BDR é escolhido como mecanismo de backup, caso o DR seja desativado.

A ideia por trás dessa configuração é que os roteadores têm um ponto central de contato para troca de informações. A seleção do DR tornou-se um problema porque o DR e o BDR precisavam ter conectividade física completa com todos os roteadores existentes na nuvem. Além disso, devido à falta de recursos de broadcast, o DR e o BDR precisavam ter uma lista estática de todos os outros roteadores conectados à nuvem. Essa configuração é obtida usando o comando neighbor:

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

Em versões posteriores do software Cisco IOS, diferentes métodos podem ser usados para evitar as complicações de configurar vizinhos estáticos e ter roteadores específicos se tornando DRs ou BDRs na nuvem não broadcast. O método a ser usado é influenciado pelo fato de a rede ser nova ou um projeto existente que precisa ser modificado.

Uma subinterface é uma maneira lógica de definir uma interface. A mesma interface física pode ser dividida em interfaces lógicas múltiplas, com cada sub-interface sendo definida como ponto a ponto. Esse cenário foi originalmente criado para lidar melhor com problemas causados por split horizon sobre NBMA e protocolos de roteamento baseados em vetor.

Uma subinterface ponto a ponto tem as propriedades de qualquer interface física ponto a ponto. Como o OSPF é uma preocupação, uma adjacência é sempre formada em uma sub-interface ponto a ponto sem escolha de DR ou BDR. O OSPF considera a nuvem um conjunto de links ponto-a-ponto em vez de uma rede multiacesso. A única desvantagem do ponto a ponto é que cada segmento pertence a uma sub-rede diferente. Esse cenário pode não ser aceitável porque alguns administradores já atribuíram uma sub-rede IP para toda a nuvem. Outra solução é usar interfaces IP não numeradas na nuvem. Esse cenário também pode ser um problema para alguns administradores que gerenciam a WAN com base nos endereços IP das linhas seriais.

Origens

1. International Telegraph and Telephone Consultative Committee, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", Recomendação Q.922 do CCITT, 19 de abril de 1991.

2. American National Standard for Telecommunications - Integrated Services Digital Network - Aspects of Frame Protocol for Use with Frame Relay Bearer Service, ANSI T1.618-1991, 18 de junho de 1991.

3. 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.

4. 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.

5. Visão geral da tecnologia de internetworking, outubro de 1994, Cisco Systems

6. Finlayson, R., Mann, R., Mogul, J., e M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, Universidade de Stanford, junho de 1984.

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

8. RFC 1490 - Encapsulamento multiprotocolo

9. RFC 1315 - MIB de Frame Relay

10. RFC 1293-Frame Relay Inverse ARP

11. RFC 1144-Compressão de cabeçalho TCP/IP

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

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

14. Encapsulamento multiprotocolo FRF 3.1

15. FRF 4-SVCs

16. Gerenciamento de rede de cliente (MIB) de serviço de Frame Relay FRF 6

17. Gangue de quatro LMI

18. Q.922 Anexo A

19. ANSI T1.617 Anexo D

20. ANSI T1.618, T1.606

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

22. Guia de projeto de OSPF

23. Notas de configuração para a implementação aprimorada do IGRP aprimorado

Informações Relacionadas

- Mais informações sobre os comandos do Frame Relay

- Mais informações sobre a configuração do Frame Relay

- Mais informações sobre os comandos de backup de discagem

- Mais informações sobre os comandos de depuração ISDN

- Mais informações sobre os comandos debug do PPP

- Mais informações sobre tipos, códigos e valores de switches ISDN

- Suporte Técnico e Documentação - Cisco Systems