O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
O X.25 é um protocolo padrão ITU-T (International Telecommunication Union-Telecommunication Standardization Setor Setor de padronização de telecomunicações da União Internacional de Telecomunicações) para comunicação WAN que define como os dispositivos do usuário e os dispositivos de rede estabelecem e mantêm conexões. O X.25 é mais comumente visto em redes propensas a erros. Este documento discute algumas das perguntas mais freqüentes sobre X.25
R. O Anexo G suporta apenas as chamadas de roteamento X.25 e de montador/desmontador de pacote (PAD). O mesmo acontece com o Serviço de rede no modo de conexão (CMNS) e X.25 sobre TCP (XOT). Você pode encaminhar uma chamada RFC1536 X.25, mas não pode originá-la sobre um identificador de conexão de link de dados (DLCI) do Anexo G.
Para transportar tráfego IP e X.25 em uma interface do Frame Relay, você precisa usar dois DLCIs ou transportar o tráfego X.25 via XOT em um DLCI que suporte IP, em vez de um DLCI do Anexo G. Para obter mais informações, consulte a documentação do Anexo G (X.25 sobre Frame Relay). Consulte também Configuração do X.25 no Frame Relay (Anexo G) (documentação do Cisco® IOS Software Release 12.2).
R. O Always on Dynamic ISDN (AODI) tem sido suportado desde o Cisco IOS Software Release 11.3(3)T. Para obter mais informações, consulte Always On/Dynamic ISDN (AO/DI).
R. O comando X.25 hold-queue é usado para especificar o número máximo de pacotes a serem retidos por VC (circuito virtual) antes de tentar criar outro SVC (circuito virtual). Se não for possível criar outro VC, os pacotes serão descartados. Consulte o documento Referência de Comando X.25 (do Cisco IOS Software Versão 12.2) para obter mais informações. Para criar outro VC, é necessário o comando x25 nvc X em que X é o número de VCs que podem ser abertos atualmente em direção ao mesmo destino.
R. O comando hold-queue <length> {in/out} é um comando de baixo nível que controla quantos buffers recebidos podem ficar pendentes no roteador. Um driver se recusará a aceitar novos dados depois de exceder o limite de entrada da interface, que só poderá ser curado depois que alguns dos pacotes recebidos no roteador forem descartados. Esse comando não deve ser confundido com o comando X25 hold-queue e não está vinculado ao Link Access Procedure Balanced (LAPB) e X.25, além do fato de que o LAPB monitora o status do limite de entrada e emite um receptor não pronto (RNR) quando o serviço não pode mais receber I-frames. Consulte Cisco IOS Interface Command Reference (Cisco IOS Software Release 12.2) (Referência de comandos da interface do Cisco IOS [versão do software Cisco IOS 12.2]) para obter mais informações.
R. A razão para um aumento da fila de entrada pode ser porque a interface tem muito tráfego para tratar, especialmente quando esses pacotes são destinados ao próprio roteador, por exemplo, o Simple Network Management Protocol (SNMP). Quando estiver usando X.25 para transportar IP, você precisará fragmentar o datagrama de IP em diversos pacotes X.25.
Por exemplo, um datagrama IP poderia ser fragmentado em cinco pacotes X.25. Cada um desses pacotes X.25 é equipado com um bit M, exceto o último. No roteador Cisco remoto, é necessário aguardar o último pacote reconstruir o datagrama IP original. Em nosso exemplo acima, os primeiros quatro pacotes (aqueles com M-bit) precisam ser enfileirados. Eles são enfileirados na fila de entrada da interface. Isso ocorre apenas se a chamada for encerrada no roteador (por exemplo, se for encerrada com o mapa x25).
Se muitas chamadas forem terminadas no roteador, (como IP e QLLC [Qualified Logical Link Control]), a fila de entrada poderá crescer, pois todos os VCs estão enviando pacotes M-bit. Isso pode ter um efeito colateral negativo, pois o roteador envia um RNR na Camada 2 quando a fila de entrada atingiu o máximo. Você pode ajustar a fila de entrada usando o comando hold-queue x in.
R. A Cisco não suporta GAP. O GAP é um protocolo DEC proprietário que transporta X.25 do VAX através de um enlace de protocolo de serviços de rede (NSP - Network-Services Protocol) DECnet para o gateway X.25 que extrai as informações X.25 e as encaminha para a rede X.25. Para obter funcionalidade semelhante com o software Cisco IOS, use o Serviço de Rede Modo de Conexão (CMNS) (também conhecido como CONS em termos de DEC). O CMNS usa o X.25 no controle de link lógico, tipo 2 (LLC2) , que pode ser obtido no VAX com DECnet PhV e P.S.I. versão 5 ou posterior.
R. Primeiro, tente negociar um tamanho de pacote consistente para a chamada. Se você não puder fazer isso (uma razão é que a negociação do tamanho do pacote está desativada) e a confirmação local está ativada, então trate a segmentação e a remontagem do circuito de acordo com as recomendações X.25.
No exemplo abaixo, serial 1 é configurado para 128 e serial 0 é configurado para 256:
3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 5 PR 4 !--- Two packets of 128 incoming. 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 6 PR 4 3d22h: Serial0: X.25 O D1 Data (259) 8 lci 1024 M PS 5 PR 4 !--- One packet of 256 outgoing on other interface. 3d22h: Serial1: X.25 O D1 RR (3) 8 lci 1024 PR 7 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 7 PR 4 3d22h: Serial0: X.25 I D1 RR (3) 8 lci 1024 PR 6 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 0 PR 4 3d22h: Serial0: X.25 O D1 Data (259) 8 lci 1024 M PS 6 PR 4 3d22h: Serial1: X.25 O D1 RR (3) 8 lci 1024 PR 1 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 1 PR 4 3d22h: Serial0: X.25 I D1 RR (3) 8 lci 1024 PR 7 3d22h: Serial1: X.25 I D1 Data (131) 8 lci 1024 M PS 2 PR 4 3d22h: Serial0: X.25 O D1 Data (259) 8 lci 1024 M PS 7 PR 4
R. Sim, grupos de busca e balanceamento de carga X.25 são suportados. Este recurso foi apresentado na Versão 12.0(3)T do Software Cisco IOS. Consulte Configuração do Balanceamento de Carga X.25 para obter mais detalhes.
A. A ITU-T (anteriormente CCITT) definiu o padrão X.75 (sistema de sinalização de comutação de pacotes entre redes públicas que fornecem serviços de transmissão de dados) para suportar a interconexão de redes de dados públicas X.25. A Cisco não implementa isso.
Uma pilha de protocolo que transporta um fluxo de caracteres assíncrono sobre uma sessão LAPB sobre um canal B ISDN também é chamada de X.75, embora a única semelhança que ele tem com X.75 seja o uso do LAPB como o protocolo da camada de enlace (que X.75 compartilha com X.25). A Cisco chama esse LAPB Terminal Adapter (LAPB-TA) e isso é suportado. Consulte o LAPB-TA da ISDN para obter mais informações.
R. O software Cisco IOS sempre suportou a versão 1984 do X.25, e esse ainda é o caso no Cisco IOS Software Release 12.2. Antes do Cisco IOS Software Release 11.3, ao configurar o encapsulamento DDN ou BFE, a versão utilizada era 1980. Se o encapsulamento era X.25, a versão usada era 1984, com a adição da versão 1988 para os valores de throughput.
R. Nos Cisco IOS Software Releases 11.2 e anteriores, as chamadas de conversão com identificadores de protocolo (PIDs) fora do padrão foram aceitas incorretamente. O endereço de destino correspondeu à primeira entrada de conversão que não especificou Dados de Usuário de Chamadas (CUD).
Essa conversão é mais precisa no Cisco IOS Software Release 12.0. O PID deve ser chamado de PAD (0x01000000) e os dados de CUD devem ser esvaziados (a conversão ocorre se o PAD for 0x01000000, mas não ocorre se o campo de dados do CUD contiver dados). A linha de conversão deve corresponder a este valor. Isso é necessário porque o PID se refere a como um aplicativo trata a chamada recebida. No nosso caso, a tradução é sempre uma função PAD. Se o roteador receber uma chamada recebida com um PID incorreto, ele a recusará porque, no host remoto, o aplicativo não está se referindo a uma função PAD.
Há várias soluções alternativas para aceitar chamadas de entrada que não se referem a PAD. O mais comum é o comando x25 default-pad. Não presuma que uma chamada recebida com PID 0xC0000000 possa ser tratada sem erros para a aplicação PAD do roteador. Ambos os sistemas se referem a diferentes maneiras de lidar com a chamada. Isso pode funcionar, mas em algumas ocasiões, não haverá intercâmbio dos parâmetros X3, resultando em um caractere ilegível exibido no terminal ou com o corte da chamada.
Para um problema de PID, se uma chamada for recebida com PID 0x01000F00, tente usar cud \001.* no comando translation (001 este é o valor octal). Veja as desvantagens de se utilizar essa configuração, conforme explicado acima.
Para uma parte de dados CUD, tente a conversão. Isto é, traduza X.25 10 cud .* tcp 1.1.1.1. Aceita todas as chamadas PAD (com PID 0x01000000) qualquer que seja a porção de dados.
Consulte Configurando a conversão do protocolo e dispositivos assíncronos virtuais para obter mais informações.
R. Para chamadas recebidas, a tabela de mapa tem prioridade sobre a tabela de rota. Se uma entrada PAD de mapa correspondente for encontrada, ela será aplicada exclusivamente e a tabela de rotas não será consultada. A tabela de rotas é consultada somente depois que nenhuma entrada de mapa tiver sido encontrada.
Para chamadas de saída, um mapa configurado na interface não pode ser roteado. Todas as outras chamadas, PADs internos ou chamadas comutadas podem ser enviadas à tabela de roteamento. A primeira correspondência disponível é sempre utilizada.
R. No Cisco IOS Software Release 11.3 e posterior, quando o roteador solicita uma chamada limpa, ele espera uma confirmação limpa, que é o comportamento padrão de ponta a ponta. No Cisco IOS Software Release 11.2, o comportamento para chamar clear request é diferente. Fazer com que o Cisco IOS Software Release 11.2 envie uma confirmação clara requer um comando oculto xot-confirm-svc-reset no nível global. Além do comando acima, os comandos service tcp keepalive-in e service tcp keepalive-out e xot-keepalive devem ser habilitados nos roteadores Cisco IOS Software Release 11.2 e 11.3. Isso remove qualquer sessão SVCs e TCP de final único.
R. Atualmente, o XOT não permite nenhum comando como x25 default-pad, porque não há interface para fazer isso. No entanto, xot profile será suportado em uma versão posterior. A meta atual é o Cisco IOS Software Release 12.2-7.T.
R. Não é possível rotear novamente a chamada X.25 que um comando x25 map deseja originar. No entanto, a detecção de falha remota X.25 é um recurso interessante para detectar falha remota - por exemplo, onde um segundo roteador pode ser direcionado para ativar um mapa X.25.
R. O X.25 é compatível com até 2 MB. Você pode realizar a execução em uma velocidade mais alta mas, ao tentar fazer isso, considere a energia de processo necessária para controlar 4095 VCs a uma velocidade de, digamos, 34 MB. Isso teria um efeito negativo, portanto é recomendável que você mantenha uma velocidade de 2 MB.
R. Sim, o encapsulamento X.25 é suportado no ISDN. O X.25 pode ser configurado no modo físico ou no modo de discador. Para obter mais informações sobre como configurar o X.25 no modo físico, consulte Configuração do X.25. Para obter mais informações sobre a configuração de X.25 no modo de discador, consulte Encapsulamentos múltiplos dinâmicos para discagem sobre ISDN. Para obter mais informações sobre a configuração de X.25 no canal D, consulte Configuração de X.25 em ISDN.
R. Sim. Para obter mais informações, consulte Configuração de grupos de usuários fechados X.25.
R. A escolha da Internet Engineering Task Force (IETF) torna o encapsulamento compatível com RFC 1356 .
R. O enfileiramento de prioridade e o enfileiramento personalizado são suportados para interfaces X.25 a partir do Cisco IOS Software Release 11.3. Esse exemplo coloca um pacote Routing Information Protocol (RIP) na fila de alta prioridade.
interface Serial0 description Connection to Packet Handler ph3.F007 port 11 ip address 10.10.10.1 255.255.255.0 no ip directed-broadcast encapsulation x25 no ip mroute-cache x25 map ip 10.10.10.2 22222 packetsize 128 128 x25 map ip 10.10.10.3 33333 packetsize 128 128 x25 map ip 10.10.10.4 44444 packetsize 128 128 priority-group 2 ! priority-list 2 protocol ip high udp rip priority-list 2 protocol ip lowPara obter mais informações sobre o enfileiramento de prioridades, consulte Configuração do Enfileiramento de Prioridades . Para obter mais informações sobre enfileiramento personalizado, consulte Configuração de Enfileiramento Personalizado.
R. Sim, a compactação pode ser usada no X.25. Por exemplo:
interface Serial3/0:2 ip address 133.11.102.101 255.255.255.0 encapsulation x25 x25 address 3101 x25 map ip 133.11.102.210 3210 broadcast compressVocê precisa de um dicionário por X.25 VC, pois o dicionário é reinicializado quando o M bit=0 é recebido, e você pode receber fragmentos de X.25 intercalados com o Mbit = 1 em vários VCs. Como resultado, a memória necessária é de 24 kB * número de VCs para a compactação.
Observação: o algoritmo de compactação é redefinido no início de cada pacote X.25. Isso significa que a compressão de carga útil é mais eficiente quando grandes pacotes são usados.
R. Observe que nem todos os diagnósticos claros e padronizados são padrão. A maioria dos construtores X.25, ou hosts X.25, aplica seu próprio diagnóstico. Se esse for o caso, consulte a documentação apropriada. Para obter informações sobre os diagnósticos padrão, consulte Códigos de causa e diagnóstico X.25.
R. A expressão regular é uma boa ferramenta para tomar decisões diferentes em uma rota X.25. O regular-expression pode ser encontrado na documentação de Expressões regulares.
R. Consulte Configuração de DDN ou BFE X.25.
R. O temporizador de retransmissão (T1) determina quanto tempo um quadro enviado pode permanecer não confirmado. Para encontrar um valor adequado de T1, localize o comprimento máximo do pacote X.25 (como 128, 256, 1024) e multiplique por oito para obter um número de bits. Em seguida, divida pela velocidade da linha em Kbps. Isso fornece o tempo de transmissão em milissegundos. O tempo de transmissão do pacote ao Switch mais próximo é o mínimo para o valor de T1 LAPB. Use um fator de "segurança" de três ou quatro para obter um valor de T1 evitando retransmissões inúteis.
Para uma linha de 19,2 kbps e pacotes de 128 bytes, isso leva a um valor de 200 ms. Verifique as informações fornecidas pelo fornecedor de rede X.25, que normalmente informa um valor.
Não use ping para avaliar o tempo de transmissão. Isso fornece o tempo em toda a rede, e não no link ao qual o temporizador se aplica.
R. Sim, o failover é compatível com X.25. O comando x25 fail-over foi introduzido no Cisco IOS Software Release 12.1(1)T.
R. O recurso Protocol Translation (Conversão de Protocolo) fornece a conversão transparente de protocolos entre sistemas que executam diferentes protocolos. Mais informações sobre o recurso de conversão de protocolo estão disponíveis em Configurando a conversão de protocolo e dispositivos assíncronos virtuais.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
16-Jan-2002 |
Versão inicial |