O Frame Relay é um protocolo de WAN de alta capacidade que opera nas camadas físicas e de link de dados do modelo de referência de Open System Interconnection (OSI). É descrito como uma versão simplificada do X.25 e é comumente utilizado em conexões WAN confiáveis. Este documento discute algumas das perguntas mais freqüentes sobre Frame Relay.
A. Não é possível fazer ping do seu próprio endereço IP em uma interface de Frame Relay multiponto. Para que um ping tenha êxito em uma interface serial, um pacote de requisição de eco do Protocolo ICMP deve ser enviado e um pacote de resposta de eco do ICMP deve ser recebido. Pings para o seu próprio endereço de interface são bem-sucedidos em subinterfaces ponto a ponto ou enlaces de Controle de enlaces de dados de alto nível (HDLC) porque o roteador no outro lado do enlace retorna o eco ICMP e pacotes de resposta de eco.
O mesmo princípio também se aplica às (sub)interfaces multiponto. Para realizar ping nas próprias interfaces, outro roteador precisa enviar de volta pacotes ICMP de pedido e resposta de eco. Como as interfaces multiponto podem ter vários destinos, o roteador deve ter mapeamento de Camada 2 (L2) para Camada 3 (L3) em cada destino. Como o mapeamento não está configurado para nosso próprio endereço de interface, o roteador não tem mapeamento de L2 para L3 no próprio endereço e não sabe como encapsular o pacote. Ou seja, o roteador desconhece qual identificador de conexão de link de dados (DLCI) usar para enviar pacotes de requisição de eco para seu próprio endereço IP, resultando em uma falha de encapsulamento. Para poder fazer o ping de seu próprio endereço de interface, um mapeamento estático deve ser configurado sendo direcionado a outro roteador no enlace do Frame Relay que possa enviar de volta os pacotes ICMP de solicitação e resposta de eco.
A. Você não pode fazer ping de um spoke para outro spoke em uma configuração de hub e spoke usando interfaces multiponto, porque o mapeamento para o endereço IP do outro spoke não é feito automaticamente. Apenas o endereço do hub é automaticamente aprendido por meio do INARP (Protocolo de resolução de endereço inverso). Se você configurar um mapa estático usando o comando frame-relay map no endereço IP de outro spoke para usar o Data-Link Connection Identifier (DLCI) local, será possível fazer ping no endereço do outro spoke.
A. A fila de broadcast de Frame Relay é um recurso importante usado em redes IPX ou IP de porte médio ou grande. Nela, os broadcasts de roteamento e de protocolo SAP devem fluir pela rede Frame Relay. A fila de broadcast é gerenciada independentemente da fila de interface normal, tem seus próprios buffers e um tamanho configurável e taxa de serviço. Devido às sensibilidades de temporização, as BPDUs (Bridge Protocol Data Units) do Spanning Tree Protocol (STP) não são transmitidas usando a fila de broadcast.
A. Essa pergunta é semelhante a aquela de quantos PCs podem ser incluídos em uma Ethernet. Em geral, você pode colocar muito mais do que deveria, considerando as restrições de desempenho e disponibilidade. Ao dimensionar um roteador em uma grande rede, considere os seguintes problemas:
Espaço de endereço DLCI: Com um endereço de 10 bits, cerca de 1000 DLCIs podem ser configurados em um único link físico. Como determinados DLCIs são reservados (dependendo da implementação do fornecedor), o máximo é de cerca de 1000. O intervalo da Cisco Local Management Interface (LMI) é 16-1007. O intervalo para American National Standards Institute e International Telecommunication Union Telecommunication Standardization Sector (ANSI/ITU-T) é 16-992. Esses DLCIs carregam os dados dos usuários.
Atualização de status da LMI: O protocolo LMI requer que todos os relatórios de status do circuito virtual permanente (PVC) caibam em um único pacote e geralmente limita o número de DLCIs para menos de 800, dependendo do tamanho da unidade de transmissão máxima (MTU). Isso produzirá o seguinte para um MTU de interface configurado de 4.000 bytes:
Observação: a MTU padrão nas interfaces seriais é de 1500 bytes, produzindo um máximo de 296 DLCIs por interface.
Replicação de broadcast: Quando o roteador está enviando, ele deve replicar o pacote em cada DLCI, o que causa congestionamento no link de acesso. A fila de transmissão reduz esse problema. Em geral, a rede deve ser projetada para manter a carga de atualização de roteamento abaixo de 20% da velocidade da linha de acesso. Também é importante considerar os requisitos de memória para a fila de broadcast. Uma boa técnica para reduzir essa restrição é usar a rota padrão ou estender os temporizadores de atualização.
Tráfego de dados do usuário: A quantidade de DLCIs depende do tráfego em cada DLCI e dos requisitos de desempenho. Em geral, os acessos a Frame Relay devem ser executados em cargas menores do que os links entre roteadores, pois os recursos de priorização geralmente não são tão fortes. Em geral, o custo marginal de aumentar a velocidade do link de acesso é menor do que para linhas dedicadas.
Para obter estimativas sobre o número prático de DLCIs compatíveis com plataformas de roteadores Cisco, consulte a seção Limitações da DLCI do Guia completo de configuração e solução de problemas de Frame Relay.
A. 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. É necessário utilizar rotas estáticas ou Dynamic Routing para que o tráfego seja roteado. E você deve usar subinterfaces ponto a ponto. Para obter mais informações, consulte a seção Exemplo de IP não numerado em uma subinterface ponto a ponto de Configuração de Frame Relay.
A. Yes. You can configure Cisco routers to function as Frame Relay data communication equipment (DCE) or network-to-network interface (NNI) devices (Frame Relay Switches). Um roteador também pode ser configurado para aceitar switching híbrido de equipamento de terminal de dados/equipamento de comunicação de dados/circuito virtual permanente (DTE/DCE/PVC). . Para obter mais informações, consulte a seção Configuração do Frame Relay do Guia de configuração de rede de longa distância do Cisco IOS, versão 12.1.
A. Yes. Em interfaces multiportas, as instruções de mapas Frame Relay devem ser configuradas usando o comando frame-relay map bridge para identificar circuitos virtuais permanentes (PVCs) para tráfego em ponte. Bridge Protocol Data Units (BPDUs) do Spanning Tree Protocol (STP) são transferidas em intervalos regulares dependendo do protocolo de Bridging configurado.
A. Os roteadores Cisco usam o encapsulamento proprietário do Frame Relay por padrão. O formato de encapsulamento IETP (Internet Engineering Task Force) deve ser especificado para interagir com outros dispositivos do fornecedor. O encapsulamento IETF pode ser especificado em uma interface ou por Data-Link Connection Identifier (DLCI). Para obter mais informações, consulte a seção Exemplos de configuração de Frame Relay de Configuração do Frame Relay, no Guia de configuração de rede de longa distância do Cisco IOS, versão 12.1.
A. O AutoInstall permite configurar um novo roteador de forma automática e dinâmica. O procedimento do AutoInstall envolve conectar um novo roteador a uma rede na qual um roteador atual é pré-configurado, ativar o novo roteador e habilitá-lo com um arquivo de configuração baixado de um servidor TFTP. Para obter mais informações, consulte Utilização das ferramentas de configuração.
Para oferecer suporte a AutoInstall por um link no qual o roteador existente está configurado com uma subinterface ponto a ponto, o comando frame-relay interface-dlci requer adições. As informações adicionais fornecidas com o comando frame-relay interface-dlci são usadas para responder à solicitação do BOOTP (Protocolo de bootstrap) do roteador remoto. A adição do endereço ipip do protocolo ao comando indica o endereço IP da interface principal de um novo roteador ou servidor de acesso no qual um arquivo de configuração do roteador deve ser instalado sobre uma rede de Frame Relay. Use esta opção somente quando o dispositivo atua como o servidor BOOTP para instalação automática por Frame Relay.
Para suportar AutoInstall em um link, no qual o roteador existente está configurado com uma (sub) interface multiponto, o comando frame-relay map deve ser configurado no roteador existente, mapeando o endereço IP do novo roteador para o identificador de conexão do link de dados local (DLCI) usado para conexão ao novo roteador.
Além disso, a (sub)interface de Frame Relay do roteador atual deve ser configurada com o comando ip helper-address apontando para o endereço IP do servidor TFTP.
A. Yes.
A. Não. Ele usa a LMI para determinar quais circuitos virtuais permanentes (PVCs) serão mapeados.
A. Quando o Circuito virtual permanente (PVC) é relacionado como inativo ou excluído.
A. Sim, mas o roteador não o usará até que o DLCI esteja ativo.
A. A mensagem definida e ativa informa que o DLCI pode transportar dados e que o roteador na ponta oposta está ativo.
A. Não, depois que um tipo específico de subinterface é criado, ele não pode ser alterado sem um recarregamento. Por exemplo, você não pode criar uma subinterface multiponto Serial0.2 e alterá-la de ponto a ponto. Para alterá-la, exclua a subinterface atual e recarregue o roteador ou crie outra subinterface. Quando uma subinterface é configurada, um Interface Descriptor Block (IDB) é definido pelo software Cisco IOS®. Os IDBs definidos para subinterfaces não podem ser alterados sem um recarregamento. As subinterfaces excluídas com o comando no interface são mostradas como excluídas pela emissão do comando show ip interface brief.
A. Essa mensagem é exibida se o encapsulamento para a interface for Frame Relay (ou High-Level Data Link Control [HDLC]), e o roteador tentar enviar um pacote contendo um tipo de pacote desconhecido.
A. Esta notificação de congestionamento é realizada alterando um bit no campo de endereço de um quadro à medida que ele atravessar a rede do Frame Relay. Os dispositivos de rede DCE (switches) alteram o valor do bit FECN para um em pacotes que trafegam na mesma direção que o fluxo de dados. Isso notifica um dispositivo de interface (DTE) que procedimentos de prevenção de congestionamentos devem ser iniciados pelo dispositivo receptor. Os bits BECN são definidos em quadros que trafegam na direção oposta ao fluxo de dados, para informar o dispositivo DTE transmissor sobre o congestionamento da rede.
Os dispositivos DTE Frame Relay podem optar por ignorar as informações de FECN e BECN ou podem modificar suas taxas de tráfego com base nos pacotes FECN e BECN recebidos. O comando frame-relay adaptive-shaping é usado quando a modelagem de tráfego de Frame Relay é configurada para permitir que o roteador reaja aos pacotes BECN. Para obter informações sobre como o roteador ajusta as taxas de tráfego em resposta aos BECNs, consulte Modelagem de tráfego.
A. O desempenho ruim em um link de Frame Relay geralmente é causado por congestionamento na rede Frame Relay e por pacotes descartados durante o trânsito. Muitos provedores de serviços oferecem apenas a entrega melhorada no tráfego que excede a taxa garantida. Isso significa que, quando a rede fica congestionada, ela descarta o tráfego na taxa garantida. Essa ação pode provocar baixo desempenho.
A modelagem de tráfego Frame Relay permite que o tráfego seja modelado para a largura de banda disponível. A modelagem de tráfego é usada com freqüência para evitar degradação do desempenho provocada pela perda de pacotes ou congestionamento. Para obter uma descrição dos exemplos de configuração e modelagem de tráfego de Frame Relay, consulte a seção Modelagem de tráfego de Frame Relay ou a seção Modelagem de tráfego de Frame Relay do Guia completo de configuração e solução de problemas do Frame Relay.
Para melhorar o desempenho, consulte as seções Configuração de Compactação de Payload ou Configuração de Compactação de Cabeçalho TCP/IP, do Manual Abrangente para Configuração e Troubleshooting de Frame Relay.
A. O ELMI permite a troca automática de informações de parâmetro de qualidade de serviço (QoS) de Frame Relay entre o roteador Cisco e o switch Cisco. Os roteadores podem basear as decisões de gerenciamento de congestionamento e priorização em valores conhecidos de QoS como a taxa de informações consolidadas (CIR), a intermitência consolidada (Bc) e a intermitência em excesso (Be). O roteador lê os valores de QoS do switch e pode ser configurado para usar esses valores na modelagem de tráfego. Essa melhoria funciona entre Cisco routers e Cisco Switches (plataformas BPX/MGX e IGX). Ative o suporte a ELMI no roteador emitindo o comando frame-relay qos-autosense. Para obter informações e exemplos de configuração, consulte a seção Ativação da interface de gerenciamento local aprimorada em Configuração do Frame Relay e modelagem de tráfego do Frame Relay.
A. Um recurso da Cisco recentemente desenvolvido, chamado Class-Based Weighted Fair Queuing (CBWFQ), permite a largura de banda reservada para diferentes aplicações de fluxos, dependendo da lista de controle de acesso (ACL) ou das interfaces de entrada. Para obter detalhes de configuração, consulte Configuração do enfileiramento justo ponderado.
A. Para que o algoritmo de compactação do cabeçalho TCP funcione, os pacotes devem chegar na ordem. Se os pacotes chegarem fora de ordem, a reconstrução aparecerá para criar pacotes TCP/IP regulares, mas eles não corresponderão ao original. Como o enfileiramento de prioridade altera a ordem na qual os pacotes são transmitidos, não é recomendável ativar o enfileiramento de prioridade na interface.
A. Yes. O recurso Frame Relay IP RTP Priority (Prioridade de RTP de IP de Frame Relay fornece um esquema de enfileiramento de prioridade máxima em um circuito virtual privado (PVC) de Frame Relay para dados sensíveis a retardo, como voz, que são identificados pelos números das portas RTP (Real-Time Transport). Esse recurso garante que o tráfego de voz receba prioridade máxima em relação a outros tráfegos.
A. O recurso PIPQ (PVC Interface Priority Queueing) de Frame Relay oferece priorização no nível de interface dando prioridade a um PVC em relação a outro na mesma interface. Esse recurso também pode ser usado para priorizar o tráfego de voz em relação ao tráfego não de voz quando transportado em PVCs separados na mesma interface.
A. A verificação de IP split horizon está desativada por padrão no encapsulamento de Frame Relay, para permitir que as atualizações de roteamento entrem e saiam da mesma interface. Uma exceção é o Enhanced Interior Gateway Routing Protocol (EIGRP) para o qual o split horizon deve ser explicitamente desativado.
Certos protocolos, como AppleTalk, transparent bridging e Internetwork Packet Exchange (IPX), não podem ser aceitos em redes parcialmente mescladas, porque precisam que o split horizon seja ativado (um pacote recebido em uma interface não pode ser transmitido pela mesma interface, mesmo que o pacote seja recebido e transmitido em diferentes circuitos virtuais).
A configuração de subinterfaces de Frame Relay garante que uma única interface física seja tratada como várias interfaces virtuais. Essa capacidade permite superar as regras de split horizon, de modo que os pacotes de uma interface virtual possam ser encaminhados para outra interface virtual, mesmo que estejam configurados na mesma interface física.
A. O OSPF trata as interfaces de Frame Relay de vários pontos como NON_BROADCAST por padrão. Isso requer que os vizinhos sejam explicitamente configurados. Há diversos métodos de manipulação de OSPF sobre Frame Relay. O método a ser implementado dependerá de a rede estar totalmente engrenada. Para obter mais informações, consulte os seguintes documentos:
A. Estimativas confiáveis só podem ser calculadas para protocolos de vetor de distância que enviam atualizações periódicas. Isso inclui Routing Information Protocol (RIP) e Interior Gateway Routing Protocol (IGRP) para IP, RIP para Internetwork Packet Exchange (IPX) e Routing Table Maintenance Protocol (RTMP) para AppleTalk. Uma discussão sobre a largura de banda consumida por esses protocolos no Frame Relay pode ser encontrada na seção RIP e IGRP de Configuração e solução de problemas de Frame Relay.
A. Isso confirma que o protocolo está configurado e que o mapeamento do protocolo para o DLCI está correto nas duas extremidades.
A. Yes. As variáveis são encontradas no RFC1315 e na base de informações de gerenciamento Data Terminal Ready (DTR) do Frame Relay.
A variável do SNMP para o status de um circuito é fr CircuitState. A forma de identificador de objeto (OID) de Abstract Syntax Notation One (ASN.1) é 1.3.6.1.2.1.10.32.2.1.3. Ele reside em frCircuitTable. Para obter o valor (o status nesse caso), o índice e a DLCI seriam a primeira e a segunda instância, respectivamente. Ao emitir os comandos SNMP Get ou Getnext, você pode descobrir o status do circuito interno do sistema. A tabela a seguir lista os valores válidos:
Valor Estado 1 inválido 2 ativo 3 inativo Para a Cisco, você veria 2 ou 3.