Roteamento Novell/IPX

O Que São e Como Troubleshoot Questões Comuns de IP Novell e IPX

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice

Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Este documento fornece algum relativo à informação variado ao protocolo de IPX. Nossa ideia não é documentar inteiramente Novell, mas cria um pouco uma lista mínima de perguntas frequente classificadas por temas.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

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

Convenções

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

Informações de Apoio

Compreendendo os números de IPX de rede

Como com outros endereços de rede, os endereços de rede Novell IPX devem ser originais. Estes endereços são representados no formato hexadecimal e consistem em duas porções: um network number e um número de nó. O número de rede de IPX, que é atribuído pelo administrador de rede, é 32 bit por muito tempo. O número de nó, que é geralmente o endereço de controle de acesso de mídia (MAC) para um do Network Interface Cards do sistema (NIC), é 48 bit por muito tempo.

  • Rede

    • o número de bit 32 representado dentro encanta

    • Atribuído administrativamente

    • Escala: 0x00000001 - 0xFFFFFFFE

    • 0xFFFFFFFF = transmissão

    • 0xFFFFFFFE = rota padrão

  • Nó:

    • o número de bit 48 representado dentro encanta

    • MAC address do cartão NIC (pode administrativamente ser atribuído)

O uso do IPX de um MAC address para o número de nó permite o sistema de enviar Nós para prever que MAC address a se usar em um link de dados. (Ao contrário, porque a parcela do host de um endereço de rede IP não tem nenhuma correlação ao MAC address, os Nós IP devem usar o Address Resolution Protocol (ARP) para determinar o endereço MAC de destino.)

O método de endereçamento permitiu originalmente que 0xFFFFFFFE fosse usado como um endereço. Depois da introdução de NLSP, a rede -2 é usada para representar a rota padrão. Os roteadores Cisco tratarão 0xFFFFFFFE como uma rota padrão, embora seja ajustável.

Exemplos de endereços Network.Node

C15C0.0000.0000.0001

BAD.0000.123d.3423

Compreendendo números da rede internos e externos em servidores Novell

Desde a introdução do netware 3.x, a arquitetura de servidor foi construída modular e cada processo (gateway, roteamento, arquivo, cópia) comunica-se com o motor a multitarefas do OS central. Os motores do OS central são atribuídos um endereço de rede do IPX conhecido como o número interno de rede, e essa identificação de nó é sempre 0000.0000.0001. Consequentemente, cada server de Novell 3.x/4.x tem um número interno de rede com um número de rede externo limitado ao adaptador de rede. O adaptador de rede pode ser limitado aos endereços de rede múltipla cada um com um tipo de frame original. Além, os servidores Novell podem conter adaptadores e rota de rede múltipla entre os segmentos de rede separados. Um servidor NT de Microsoft que executa o IPX não aparecerá com a identificação de nó de 0000.0000.0001 e não usa o conceito do número de rede interna e externa à revelia.

/image/gif/paws/10564/33h.gif

Encapsulamento Novell

Há muitos encapsulamentos Novell diferentes. Para Ethernet somente, há tanto como como quatro. O tipo de encapsulamento é muito importante como dois dispositivos que usam métodos de encapsulamento diferentes no mesmo media não poderá comunicar-se. Os clientes Novell podem geralmente adaptar-se ao encapsulamento disponível em seus links, mas os servidores de IPX devem ter um tipo de encapsulamento consistente codificado.

Os nomes do encapsulamento são diferentes em Novell ou na terminologia Cisco. A tabela a seguir fornece um sumário das encapsulações IPX disponíveis para tipos diferentes de media.

Convenções de nomeação de encapsulamento de IPX

Convenção de nomeação do Cisco IOS Convenção de nomeação do interruptor do Cisco catalyst * Convenção de nomeação de software de Novell LSAP Descrição
Ethernet Novell-ether 8023RAW Ethernet_802.3 (cru) FFFF Ethernet sem o LLC ou a PRESSÃO
ARPA Ethernet II (EII) Ethernet_II 8137 Tipo 8137 s do Ethernet II
SAP 8023 Ethernet_802.2 E0E0 Ethernet com o envelope 802.2
SNAP SNAP Ethernet_SNAP AAAA Envelope + PRESSÃO s 802.2 dos Ethernet
FDDI SNAP SNAP FDDI_SNAP AAAA FDDI usando 802.2 + PRESSÃO
SAP SAP FDDI_802.2 E0E0 FDDI usando o envelope 802.2
Token Ring SAP n/a Token Ring E0E0 Token Ring com 802.2
SNAP n/a Ring_SNAP simbólico AAAA Token Ring com 802.2 + PRESSÃO

  • O ETHERNET_802.3 do tipo de frame é o encapsulamento de proprietário de Novell. Põem pacotes SPX/IPX diretamente dentro de 802.3 quadros e não usam 802.2 LLC nem AGARRAM-NOS. Este é NOVELL-ETHER do encapsulamento Novell na terminologia de Cisco.

  • O ETHERNET_II do tipo de frame é moldação “padrão” do Ethernet II. Os pacotes SPX/IPX são enchidos em quadros do Ethernet II, usando o tipo código 8137. Estes quadros diferem dos novell frame somente no tipo código do dois-octeto/campo do comprimento de frame; se não, são idênticos. Este é o encapsulamento Novell ARPA na terminologia de Cisco.

  • O tipo de frame ETHERNET_802.2 é o encapsulamento preferido de Novell para o netware 3.12, server do netware 4.X: é Ethernet com o envelope 802.2. Este é encapsulamento Novell SAP para 9.21 na terminologia de Cisco.

  • O ETHERNET_SNAP do tipo de frame é Ethernet com o envelope 802.2 + a PRESSÃO. Isto não é usado geralmente. Este é Novell Encapsulation SNAP na terminologia de Cisco.

* As configurações de IPX em Catalyst series switch aplicam-se somente para Ethernet às configurações de FDDI Bridging.

IPX Routing Protocols

Usando os protocolos alistados abaixo, as rotas e prestam serviços de manutenção a um roteador de IPX sabem do podem ser definidas e controlado dinamicamente:

  • SAP (protocolo service advertisement): Um protocolo de IPX que permita que os recursos de rede tais como server e Roteadores se tornem conhecidos aos clientes de rede. SAP é exigido determinando onde os serviços de rede individual residem na rede interna.

  • RIP (Routing Information Protocol): Um Interior Gateway Protocol (IGP) que usa o contagem de saltos e tiquetaqueia como métricas de roteamento. O contagem de saltos mede a distância entre uma fonte e um destino. O tempo de resposta round trip entre a fonte e o destino é medido nos tiquetaques, ou em 1/18 dos segundos intervalos. RASGUE aprende, seleciona, e mantém a tabela de roteamento. O RASGO é um protocolo de vetor de distância usado para trocar a informação de roteamento dentro de um sistema independente.

    • RASGUE e CAVE o trabalho junto em equipe para ajudar clientes, server, e Roteadores a encontrar serviços de rede, e rotas a cada serviço. São usados igualmente para comunicações de cliente com servidor assim como comunicações do roteador para roteador.

  • IPX EIGRP: O IGRP é o protocolo interior gateway routing de Cisco usado em internets TCP/IP e OSI. O IGRP usa a tecnologia de roteamento do vetor de distância de modo que cada roteador não precise de conhecer todos os relacionamentos do roteador/link para a toda a rede. Cada roteador anuncia destinos com uma distância correspondente. Cada roteador que ouve as informações ajusta a distância e a propaga para os roteadores vizinhos.

    • A informação de distância no IGRP é representada como um composto da largura de banda disponível, retardo, utilização de carga e confiabilidade do enlace. Isto permite que os ajustes finos da característica de enlace consigam caminhos ótimo que o EIGRP é uma versão de IGRP aprimorada. A mesma tecnologia de vetor de distância encontrada no IGRP também é usada no EIGRP, e a informação de distância subjacente permanece inalterada. As propriedades de convergência e a eficiência de operação desse protocolo melhoraram significativamente. Isso permite uma arquitetura aprimorada ao mesmo tempo em que investimentos existentes em IGRP são mantidos. Para detalhes no EIGRP, veja por favor o seguinte documento:

      Introdução ao IGRP aprimorado (EIGRP)

      Os módulos dependentes de protocolo são responsáveis por requisitos específicos do protocolo da camada de rede. Por exemplo, o módulo IPX-EIGRP é responsável pelo envio e pelo recebimento de pacotes EIGRP que são encapsulados em IPX. O IPX-EIGRP é responsável para analisar gramaticalmente o algoritmo de atualização em difusão dos pacotes EIGRP e da informação (DUPLO) da informação nova recebida. O IPX-EIGRP pede DUPLO para fazer a decisões de roteamento os resultados de que são armazenados na tabela de roteamento de IPX. O IPX-EIGRP fornece as seguintes características.

    • Redistribuição automática - As rotas RIP IPX são redistribuídas automaticamente no EIGRP e nas rotas IPX-EIGRP são redistribuídas automaticamente no RASGO sem comandos any que estão sendo entrados pelo usuário. A redistribução pode ser desligada com o uso do nenhum redistribui o subcomando de roteador do protocolo. IPX-RIP e IPX-EIGRP podem ser completamente desativados no roteador.

    • Largura de rede aumentada - Com RASGO IPX, a largura possível a maior de sua rede é 15 saltos. Quando o IPX-EIGRP é permitido a largura possível a maior é 224 saltos. Como a métrica EIGRP é grande o suficiente para suportar milhares de saltos, a única barreira para a expansão da rede é o contador de saltos da camada de transporte. A Cisco trata esse problema apenas incrementando o campo de controle de transporte quando um pacote IPX ultrapassou 15 roteadores, e o próximo salto para o destino foi conhecido via EIGRP. Quando uma rota RIP está sendo usada como o próximo salto para o destino, o campo de controle de transporte é incrementado como de costume.

    • Atualizações de SAP em incrementos – As atualizações completas de SAP são enviadas periodicamente até ser encontrado um vizinho de EIGRP; depois disso, somente quando houver alterações na tabela de SAP. Isso funciona tirando proveito do mecanismo de transporte confiável do EIGRP, portanto deve haver uma correspondência IPX-EIGRP para que os SAPs incrementais sejam enviados. Se não existir um correspondente em uma interface determinada, SAPs periódicos serão enviados para essa interface até que um correspondente seja encontrado. Esta funcionalidade é automática em interfaces serial e pode ser configurada em media LAN se desejada.

  • NLSP (protocolo netware link services): Este protocolo de roteamento pode ser usado conjuntamente com, ou em vez de SAP e do RASGO. Endereça as limitações do RASGO e do SAP quando são executadas em grande, internetworks complexa. Tipicamente, o NLSP usa menos largura de banda, é mais rápido em atualizar sua tabela de roteamento, e é mais escalável às grandes inter-redes do que o RASGO e o SAP. O NLSP não é um protocolo de uso geral do roteamento IPX.

Estudos de caso da rede Novell IPX

Casos Práticos 1: Interoperabilidade entre Cisco e 3Com em interfaces WAN

À revelia, os roteadores Cisco são configurados para as atualizações de SAP periódico que ocorrem cada 60 segundos em todas as relações. Contudo, em 3Com Router da empresa, a interface WAN é configurada para atualizações não-periódicos de SAP à revelia. As atualizações não-periódicos são as atualizações de SAP que ocorrem somente quando um link vem acima, quando o link está tragado administrativamente, ou quando a informação do serviço muda em vez de um intervalo periódico. Este parâmetro é apoiado para atualizações de SAP somente. Ao conectar um roteador Cisco com um 3Com Router que executa o IPX sobre uma interface WAN com uma configuração de IPX do padrão, as entradas do servidor de IPX no roteador Cisco aparecerão somente por 240 segundos depois que associação ou alteração de topologia devido à configuração padrão do 3Com Router que está sendo ajustado para atualizações não-periódicos de SAP. Para corrigir esta edição, uma alteração de configuração é exigida em Cisco ou no 3Com Router.

Para mudar o 3Com Router às atualizações de SAP periódico em uma interface WAN, emita as seguintes etapas:

  1. Verifique a configuração de IPX na interface WAN no 3Com Router emitindo o comando: mostre [! <port]|! *] - controle da seiva

    Exemplo: SH - SAP CONT

  2. Se o 3Com Router é configurado para “nonperiodic” na interface WAN, a configuração deverá ser mudada a “periódico” usando o comando: setdefault! <port> - seiva control=periodic

    Para mudar o roteador Cisco às atualizações não-periódicos IPX SAP em uma relação, emita o seguinte comando interface:

    mudanças-somente da seiva do intervalo da atualização IPX

Casos Práticos 2: Fila de transmissão do frame relay e perda de conectividade IPX pelas redes de frame relay

Um roteador Cisco que esteja configurado para o IPX e colocado enquanto o hub de uma perturbação do Frame Relay pode precisar de ter as alterações de configuração associadas com a fila de transmissão do Frame Relay. Este é um resultado da fila de transmissão do Frame Relay que opta um tamanho somente de uma interface única quando de facto a relação puder servir sites múltiplo. O tamanho de fila padrão da transmissão do Frame Relay é 64 e precisa de ser configurado como 64 vezes o número de subinterfaces. O tamanho da fila que é demasiado pequeno configurado pode conduzir às atualizações da perda de IPX RIP/SAP através de WAN. As atualizações da perda de IPX RIP/SAP causarão a perda de conectividade entre o hub e os locais remotos.

Exemplo: Demasiado pequeno configurado fila de transmissão do Frame Relay:

lt-3810b#show int s0
Serial0 is up, line protocol is up
 ...
Encapsulation FRAME-RELAY, crc 16, loopback not set
  ..
  Broadcast queue 61/64, broadcasts sent/dropped 17423/14021, interfacebroadcasts 42032
  Last input 3d19h, output 3d19h, output hang never
  Last clearing of "show interface" counters 00:00:07
  Input queue: 74/75/0 (size/max/drops); Total output drops: 14453
  Queueing strategy: weighted fair
  Output queue: 25/1000/64/1578 (size/max total/threshold/drops)

Diretrizes de configuração para configurar a fila de transmissão do Frame Relay

Fila de transmissão do Frame Relay

  • Para criar uma fila especial para que uma interface especificada guarde o tráfego de broadcast que replicated para a transmissão nos identificadores múltiplos da conexão de link de dados (DLCI), use o comando frame relay broadcast queue interface configuration:

  • taxa de pacote de informação da taxa de byte do tamanho da fila de broadcast do Frame Relay

Descrição da sintaxe

  • tamanho - Número de pacotes a realizar na fila de broadcast. A recomendação para a rede IPX RIP/SAP é ter 64 pacotes cronometra o número de locais remotos. Por exemplo, se há os locais remotos 7, configurar a profundidade de fila como 448.

  • taxa de byte - Máximo número de bytes a ser enviado por segundo. A recomendação é uso a configuração padrão de 256000 bytes por segundo

  • taxa de pacote de informação - Número máximo de pacotes a ser enviado por segundo. A recomendação é uso o padrão de 36 pacotes por segundo.

Casos Práticos 3: Inconsistência IPX SAP ao usar IPX EIGRP como IPX Routing Protocol

Ocasionalmente, pode haver uma perda de conectividade repentina a um servidor Novell específico ou ao serviço IPX. Os servidores Novell ou os serviços IPX podem desaparecer aleatoriamente das tabelas de SAP de IPX. Isto pode igualmente fazer com que os tamanhos de tabela de SAP variem por algumas seivas através da rede.

Se você está experimentando estes problemas, veja estes Bug de Software e promova-os a uma versão de software que não experimente estas edições.

Reveja estes Release Note:

CSCdp13795 - Inconsistência de IPX SAP com IPX EIGRP

Se você está usando o Enhanced Interior Gateway Routing Protocol (EIGRP) IPX, você pôde experimentar uma inconsistência em atualizações do protocolo service advertising (SAP) em um roteador remoto, se a interface serial é derrubada por um tempo curto e trazida então acima outra vez. Para verificar a edição, inscrever o comando clear ip eigrp neighbors EXEC, ou inscrever o comando no ipx linkup-request sap para as interfaces serial e verificar que o problema não reoccur.

CSCdk13645 - A tabela de SAP de IPX pode tornar-se incompatível depois que os servidores múltiplos são removidos da tabela

Ao usar as atualizações de SAP de acréscimo IPX EIGRP (RSUP), as tabelas de servidor entre dois ou mais vizinhos EIGRP pode tornar-se incompatível. Especificamente, o problema pode ocorrer quando somente três dúzias de servidores partem ao mesmo tempo, quando as rotas 2 aqueles serviços permanecerem na tabela de roteamento se há vizinhos ou trajetos do EIGRP múltiplo a um vizinho. A atualização flash para alguns dos server recentemente tragados não está sendo mandada para baixo a todas as relações, assim que alguns dispositivos têm os server removidos e outro não fazem. A ação alternativa é cancelar os vizinhos EIGRP IPX na unidade que mostra estes server que permanecem na tabela.

Uma atualização flash é um anúncio imediato de todas as mudanças na rede, e a aparência de serviços novos ou o desaparecimento dos serviços existentes. Enquanto o seguinte sample lab debug output mostra, a atualização flash está mandada a todas as relações que estão executando o IPX:

5d10h: IPXSAP: positing update to 1.ffff.ffff.ffff via Serial1 ( 
broadcast) (flash) 
5d10h: IPXSAP: positing update to 2.ffff.ffff.ffff via Serial0 ( 
broadcast) (flash) 
5d10h: IPXSAP: positing update to 100.ffff.ffff.ffff via Etherne 
t0 (broadcast) (flash)

CSCdm23488 - Seivas faltantes após a associação/para baixo

Nas configurações de rede com a interface IPX que interconecta um roteador local e um roteador remoto configurados com o IPX EIGRP SAP-incremental (o modo padrão no NON-LAN conecta quando o IPX EIGRP é usado), o roteador remoto pode perder algumas seivas se a relação do roteador local (a relação de onde os serviços IPX estão ouvidos mas não conectados ao roteador remoto) se submete a uma transição rápida down/up. O trabalho é ao redor restabelecer a adjacência IPX-EIGRP emitindo o comando clear ipx eigrp neighbors no roteador remoto.

A causa de raiz de CSCdm23488 é uma questão de cronometragem com os processos de software que são chamados pelo link de seguimento IPX para baixo e ligam acima das sequências. Quando um grande número serviços IPX são involvidos, a relação vem acima quando as seivas do veneno forem enviadas. Em consequência, as seivas do veneno cancelam os anúncios novos e impedem eficazmente que alguns serviços estejam anunciados.

CSCdx73624 - Seivas de falta IPX

Em uma topologia do Frame Relay do hub and spoke, dois spokes não podem receber as seivas de cada um se o nuvem de WAN está executando o RASGO IPX e o IPX EIGRP. O resultado é uma tabela incompatível de SAP. Como uma ação alternativa, RASGO do desabilitação IPX.

Passos de Troubleshooting

Se você observa um problema com seivas de falta, use os seguintes passos de Troubleshooting:

  • Se as seivas são instruídas através de um outro spoke do Frame Relay, o roteador de hub igualmente está faltando as seivas ou somente o roteador do spoke do local?

  • São a utilização você incremental ou as atualizações de SAP periódico?

  • Se você permitiu atualizações periódicas, determine se o roteador está recebendo atualizações refrescadas de SAP. Veja os contadores de SAP emitindo o comando show ipx traffic.

System Traffic for 0.0000.0000.0001 System-Name: SAMPLE 
 Time since last clear: 00:01:47 
 Rcvd: 733 total, 0 format errors, 0 checksum errors, 0 bad hop count, 
 4 packets pitched, 733 local destination, 0 multicast 
 Bcast: 732 received, 507 sent 
 Sent: 529 generated, 456 forwarded 
 0 encapsulation failed, 0 no route 
 SAP: 0 Total SAP requests, 0 Total SAP replies, 0 servers
  • É você perdedor todas as seivas de um servidor particular?

  • Há um relacionamento entre uma falha do link e as seivas dos desaparecidos? Se as seivas são perdidas após uma alteração de link, use as seguintes etapas:

    1. Desabilite o logging de console e permita o buffer que registra emitindo o comando logging buffered.

    2. Emita os comandos debug ipx eigrg events e debug ipx eigrp neighbor {neighbor ID}.

    3. Transição o estado do link da relação.

    4. Se você detecta as seivas faltantes, espere pelo menos cinco minutos para verificar que as seivas faltam certamente. Capture a saída do server IPX da mostra e mostre routecommands IPX em ambo o Roteadores do hub and spoke.

    5. Emita o comando clear ipx route na extremidade do spoke.

    6. Emita os comandos show ipx server e show ipx route verificar se todas as seivas estiveram aprendidas.

Se você não pode resolver o problema com as etapas acima, você pode precisar de emitir o comando debug ipx sap activity. O exemplo debuga mensagens é fornecido abaixo.

3d21h: IPXSAP pv03 from net C4545 rejected, route C0324002 not in table 

Oct 19 18:21:05 CDT: IPXEIGRP: SAP from FF16 rejected, route 2200 in table via different interface

Nota: Assegure-se de que você compreenda o impacto deste comando debug antes do permitir, desde que pode gerar uma grande quantidade de saída. Para minimizar o impacto de debuga ao roteador, nós recomendamos desabilitar o logging de console e permitir o buffer que registra com um tamanho de buffer suficiente.

Casos Práticos 4: O comando show IPX traffic indica erros de vários formatos

por exemplo: O comando é configurado como o lt-4500-3a-show ipx traffic. A saída é a seguinte:

System Traffic for 0.0000.0000.0001 System-Name: dc_gw
Rcvd: 49847808 total, 1974563 format errors, 0 checksum errors,150 bad hop count, 
310999 packets pitched, 1067549 local destination, 0 multicast
Bcast: 1072701 received, 1005206 sent
Sent: 2209133 generated, 48465603 forwarded
0 encapsulation failed, 3240 no route
SAP: 2174 SAP requests, 8 SAP replies, 1330 servers
899357 SAP advertisements received, 990129 sent
0 SAP flash updates sent, 535 SAP format errors, last seen from 0.0000.0000.0000
RIP: 91556 RIP requests, 22723 RIP replies, 152 routes
73769 RIP advertisements received, 20433 sent
1475 RIP flash updates sent, 0 RIP format errors
Echo: Rcvd 0 requests, 0 replies
Sent 0 requests, 0 replies
76 unknown: 76 no socket, 0 filtered, 0 no helper
0 SAPs throttled, freed NDB len 0
Watchdog:
0 packets received, 0 replies spoofed
Queue lengths:
IPX input: 0, SAP 0, RIP 0, GNS 0
SAP throttling length: 0/(no limit), 0 nets pending lost route reply
Delayed process creation: 0
EIGRP: Total received 0, sent 0
Updates received 0, sent 0
Queries received 0, sent 0
Replies received 0, sent 0
SAPs received 0, sent 0
Trace: Rcvd 0 requests, 0 replies
Sent 0 requests, 0 replies

Os erros de formato em um comando show ipx traffic são o número de pacotes ruins rejeitados (por exemplo, pacotes com um cabeçalho corrompido). Este contador inclui os pacotes IPX recebidos para um encapsulamento que o roteador não está configurado.

A maioria de PC em uma rede auto-detectam o tipo de frame de IPX em um Token Ring ou na rede Ethernet enviando pedidos GNS de todos os quatro tipos de frame possíveis. A relação no roteador é codificada duramente a um tipo de frame específico. Se a relação no roteador recebe um pacote IPX com um tipo de frame diferente do que o que está configurado, o pacote é deixado cair e do “o campo formato” é incrementado. Consequentemente, os PC configurados para o tipo de frame do padrão gravarão sempre pelo menos três erros de formato no roteador Cisco adjacente em cima da partida.

Refira comandos ipx de Novell para obter mais informações sobre do comando show ipx traffic.

Casos Práticos nº 5: SAPs de IPX não estão aparecendo na tabela do servidor IPX em nuvens de WAN

Os roteadores Cisco através de um nuvem de WAN mostrarão todas as rotas do IPX na tabela de roteamento de IPX. Contudo, nenhumas das seivas IPX estão aparecendo na tabela de servidor de IPX. A codificação da linha AMI não apoia pacotes com uma densidade dos zero da elevação. A codificação de linha deve ser a codificação B8ZS que, ao detectar uma densidade dos zero da elevação, para inverter o fluxo de dados para quebrar acima os zero. Os pacotes de SAP de IPX podem incluir um padrão de dados de 11 zeros consecutivos. Por exemplo, um tipo 4 servidor de arquivo tem um endereço IPX do ABCDEF.0000.0000.0001, que seja corrompido se o nuvem de WAN não apoia a densidade zero elevada. Se o pacote alcança um roteador remoto corrompido, estará deixado cair. Em consequência, as atualizações do RASGO IPX alcançarão roteadores remotos, mas os pacotes de SAP de IPX não, devido à densidade zero elevada.

A solução é mandar o provedor de serviços MACILENTO corretamente ajustar a codificação de linha a B8zs através de WAN.

Para verificar sua configuração, inicie um ping IP com um teste padrão de todos os zero através do nuvem de WAN em 500, 1000 e 1500 bytes. Se o ping IP é bem sucedido, a codificação de linha não é uma edição desde que o alto densidade zero sibilos do teste padrão é bem sucedido.

Router#ping
Protocol [ip]: 
Target IP address: 10.10.10.1
Repeat count [5]: 
Datagram size [100]: 500
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: 
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 0x0000 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 5, 500-byte ICMP Echoes to 10.10.10.1, timeout is 2 seconds:
Packet has data pattern 0x0000
!!!!!
Success rate is 100 percent (5/5)
Router#

Casos Práticos 6: As estações de trabalho não são capazes de se conectar a um dos servidores por meio da vizinhança de rede

Em alguns casos, as estações de trabalho podem ver todos os servidores Novell em uma vizinhança de rede, mas incapaz de conectar a alguns dos server com a vizinhança de rede. A fim anexar aos server na vizinhança de rede através dos VLAN ou através das redes múltiplas, as estações de trabalho cliente devem ter o cliente Novell 32 instalado ou permitir a propagação de tipo 20 IPX no Roteadores correspondente. Além, cada network number no terreno deve ser original através da toda a rede. Use a ferramenta IPX PING nos servidores Novell e na ferramenta PING IPX nos roteadores Cisco para verificar a Conectividade através de WAN.

Casos Práticos 7: Não é possível acessar os recursos do Citrix Winframe usando IPX nos Cisco Routers

Se a saída do comando de server IPX da mostra mostra que há mais de um servidor Winframe com a mesma contagem do salto/tiquetaque afastado, a seguir, somente SAP da primeira entrada será enviado à revelia ao cliente.

Este não é um problema para um servidor Novell, desde que o cliente aceitará primeiro SAP, vai ao primeiro server, e obtém então reorientado ao server da escolha do cliente se há um servidor preferido. Winframe não tem essa funcionalidade. Se o cliente se estabelece para o nome do servidor “x”, mas obtém SAP para o nome do servidor “y,” desde que “y” é primeiro na tabela de SAP, a seguir o cliente nunca conectará.

A solução é adicionar o comando ipx gns-round-robin como um comando global no roteador com o winframe múltiplo SAP da mesma distância. O roteador arredondamento robin com as respostas de SAP e o cliente obterá SAP para o server correto, mesmo se não é primeiro SAP na tabela de SAP do roteador.

Casos Práticos 8: Login Novell IPX lento

A maioria de causa comum para o início de uma sessão do Novell lento é uma edição conhecida como o passeio da árvore. Quando um agente do cliente submete um pedido ao NDS, o pedido não está recebido sempre por um Nome do servidor que seja qualificado para cumprir o pedido. O Nome do servidor que recebe o pedido deve encontrar um Nome do servidor que possa cumprir o pedido. Diversos Nomes do servidor podem precisar de ser contactado antes que um server qualificado esteja encontrado. Para encontrar a informação, um Nome do servidor inicia uma busca até que uma réplica esteja encontrada que contenha a informação desejada. Este processo é chamado passeio da árvore. Enquanto a informação de réplica pode ser alcançada rapidamente, o passeio da árvore não é um problema. Contudo, se a informação de réplica está somente disponível através de um enlace lento, tal como um link MACILENTO, atrasos pode ocorrer. Todo o aplicativo que usar o NDS pode causar a árvore que anda, mas o passeio da árvore pode ser minimizado com bom projeto da árvore de NDS.

Problemas de login e definições lentos comuns pelo Web site de Novell:

TID 10051665    Troubleshooting Slow Novell Login Problems

TID 10014302    NW5 client slow logging into IPX server

TID 2950722     Slow NT Login in Pure IP Environment

TID 10020376    The clients are getting a Slow Network Login

TID 10024740    Troubleshooting IP Login Issues

TID 10016768    Login is very slow from specific machines

TID 10021852    Slow login over a WAN link due to Contextless Login

Troubleshooting Geral

Para identificar o que está causando potencialmente o problema de login lento, obtenha um rastreamento de pacotes do problema que ocorre, capturando todos os pacotes enviados a e da estação de trabalho. Dois rastreamentos de pacotes serão necessários para determinar exatamente o problema: um rastreamento de pacotes da porta de servidor e um outro rastreamento de pacotes da estação de trabalho. Obtendo dois rastreamentos de pacotes, será muito fácil determinar se o problema é relacionado às redes derrubando pacote.

Casos Práticos #9: Troubleshooting de Entradas Corrompidas da tabela SAP IPX

As entradas IPX SAP que indicam caracteres inválidos, as redes fantasma, ou caráteres bit-deslocados/bit-trocados são muito provavelmente entradas corrompidas de SAP. Os caracteres inválidos da amostra incluem (@! ~^)). Desde que não há nenhuma soma de verificação da camada 3 (L3) no quadro IPX SAP, o corrompimento de dados pode ocorrer com atualizações IPX SAP. Esta corrupção não pode ser causada pela corrupção da camada 2 (L2) porque o CRC no quadro L2 seria inválido e o roteador deixaria cair o quadro. As seivas corrompidas IPX são causadas sempre pelo hardware defeituoso. Encontrar a fonte de SAP de IPX corrompido é razoavelmente simples ao usar o exclusive do RASGO IPX; Use simplesmente o contagem de saltos para encontrar a fonte. Com IPX EIGRP, o Troubleshooting é mais difícil, contudo.

Com caminhos redundantes e uma topologia dada laços usando IPX EIGRP, uma entrada do SAP corrompido pode ficar para sempre, não cronometrando para fora mesmo quando o dispositivo original foi desligado. A razão que as seivas não desaparecerão de um ambiente misturado EIGRP e de RASGO são devido ao fato de que quando você tem caminhos paralelos através de uma rede, o RASGO e o EIGRP passarão as entradas de SAP para a frente e para trás. Este comportamento impedirá que as seivas cronometrem nunca para fora. Quando o EIGRP recebe atualizações Roteadores de dois ou mais diferentes das atualizações de SAP, o EIGRP passará as atualizações de novo no RASGO do EIGRP se a entrada do RASGO parte. O EIGRP igualmente preservará o contagem de saltos do RASGO, que faz encontrando a fonte mais difícil.

Somente os efeitos acima descritos circunstância dando laços SAP, não rotas. Isto é porque SAP sempre apontará à rota a mais curto e não observa loop de roteamento. SAP não é um protocolo de roteamento. Remover o EIGRP no trajeto inteiro permitirá que os SAP corrompidos envelheçam para fora.

Devido o comportamento de IPX EIGRP e de entradas de tabela do IPX sap corrupto do Troubleshooting, usa os seguintes procedimentos de Troubleshooting em isolar os SAP de IPX corrompido ao usar IPX EIGRP:

  1. Durante um indicador da parada de rede, o desabilitação IPX EIGRP e o RASGO do uso para encontrar exatamente a fonte de entradas do SAP corrompido. Desde que o RASGO usa o contagem de saltos no caminho de rede, determinar a fonte ou a origem deve ser razoavelmente simples. Pesquisar defeitos desse modo supõe que as famas corrompidas devem ser geradas durante a janela de tempo ocioso. Desde que o corrompimento de IPX SAP é devido ao hardware, o problema não pode ocorrer frequentemente e somente ocorrer aleatoriamente períodos de tempo. Sem os SAP corrompidos atualmente que estão sendo gerados na rede, não haverá nenhuma maneira de determinar a fonte. Todos os SAP corrompidos colados na tabela EIGRP partirão uma vez que o EIGRP é removido.

  2. Encontre um origem comum ou uma origem dos SAP corrompidos. Se lá um origem comum às seivas, ele pode ser simples isolar a edição e não tem que executar como o Troubleshooting intrusivo como em etapa 1.

    Todos os SAP corrompidos estão sendo causados pelo hardware defeituoso em algum lugar na rede. Isto inclui todo o roteador, Switches L3, server que executam IPX (não apenas servidores Novell), e estações de trabalho que executam o IPX. Até agora, Cisco nunca mandou uma edição do IOS Software contribuir às seivas IPX corrompidos.

  3. Às seivas IPX corrompidos da ação alternativa que afetam a conectividade de rede, configurar os filtros IPX que incluem filtros GNS, filtros GGS, e filtros de SAP para passar somente servidores válidos na rede. Além, adicionar o comando ipx sap follow-route-path minimizará o número de SAP corrompidos. Isto é porque quando o comando ipx sap follow-route-path é usado, o roteador seleciona serviços individuais (seivas) em atualizações de SAP. O roteador olha o número de rede de destino de cada entrada de SAP. Se a relação de recepção é uma das melhores relações para alcançar a rede de destino de SAP, essa entrada de SAP está aceitada. Se não, a entrada de SAP é rejeitada. Se um roteador está recebendo os SAP corrompidos, é provável a rota pode ser corrompido também.

Casos Práticos #10: A lista de servidores do comando show IPX servers unsorted pode mostrar os servidores que não estão funcionando

Em certos casos, quando o arredondamento robin IPX GNS é configurado, o roteador pode experimentar uma edição que possa fazer com que um serviço da métrica baixa seja movido na tabela além do mais baixo grupo métrico de serviços. Isto causará SAP apresenta para parecer fora de serviço. Este é comportamento conhecido, e todo o efeito secundário deste comportamento pode ser resolvido usando filtros de emissor GNS para permitir somente que os server específicos respondam ao GNS.

Se você está experimentando estes problemas, veja o seguinte Bug de Software e promova-o a uma versão de software que não experimente estas edições.

CSCds54733 - saídas dos servidores não selecionados IPX da mostra não está em ordem

A saída do comando show ipx server unsorted indica uma tabela de SAP que não esteja em ordem. Quando a tabela estiver neste estado, as respostas GNS SAP não podem proporcionar o serviço o mais próximo como devem. A tabela misordered resulta de permitir o arredondamento robin GNS. Como uma ação alternativa, arredondamento robin do desabilitação GNS emitindo o comando no ipx gns-round-robin.

Estudos de caso de IP do Novell 5.X

Casos Práticos 1: Configuração Básica do Cisco Router Necessária para os Clientes Fazerem Logon no Novell IP Network Entre Limites da Rede

À revelia, os clientes IP de Novell descobrem Serviços IP através do Multicast. A menos que um outro método for configurado, os clientes IP tentarão descobrir o server pelo protocolo service location (SLP) que usa IGMP (multicasting). À revelia, os IOS Router não enviarão pacotes de transmissão múltipla.

A solução de roteador básica é permitir globalmente o comando ip multicast-routing e permitir o comando ip pim dense-mode sob cada VLAN respectivo ou interface física.

Configuração de exemplo:

Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router
!
boot system bootflash:c6msfc-js-mz.120-7.XE1.bin
boot bootldr bootflash:c6msfc-boot-mz.120-7.XE1
!
ip subnet-zero
no ip domain-lookup
!
ip multicast-routing
ip dvmrp route-limit 20000
ip cef
cns event-service server
!
!
!
interface Vlan1
ip address 10.1.1.1 255.255.255.0
no ip directed-broadcast
ip pim dense-mode
!
interface Vlan11
ip address 10.1.2.1 255.255.255.0
no ip directed-broadcast
ip pim dense-mode
!
interface Vlan12
ip address 10.1.3.1 255.255.255.0
no ip directed-broadcast
ip pim dense-mode
!
ip classless
no ip http server
!
!
!
line con 0
transport input none
line vty 0 4
login
transport input lat pad mop telnet rlogin udptn nasi
!
end
Router#

Há outros dois métodos por que as estações de trabalho cliente podem alcançar Novell 5.0 recursos através dos limites de rede sem a necessidade de permitir o mutlicast-roteamento.

Configuração Novell #1 (documento de Novell: 2944038)

Adicionar o nome do servidor e as entradas de endereço IP no arquivo nwhost na estação de trabalho. O arquivo nwhost é ficado situado na estação de trabalho no diretório Novell\Client32 em estações de trabalho de Win95 e de Win98. Tem as amostras que são fáceis de seguir.

Em uma estação de trabalho de NT, em vez de NWHost, o cliente usa o arquivo de host padrão de Microsoft TCP/IP. Edite o arquivo de host para adicionar o nome do servidor e o endereço. O trajeto a este arquivo é Winnt/System32/Drivers/Etc/Hosts.

Configuração Novell #2 (do documento 2944038 de Novell)

Carga SLPDA.NLM no server do netware 5. Isto define o server como um agente de diretório. Adicionar o endereço IP de Um ou Mais Servidores Cisco ICM NT do server que executa o SLPDA.NLM sob propriedades do cliente, aba do lugar do serviço, lista do agente de diretório. Clique sobre a caixa ao lado da caixa do agente de diretório etiquetada “estática.” Com um agente de diretório estático definido, o cliente não Multicast para um agente de diretório, mas enviará um unicast ao agente do diretório especificado.

Para uma vista geral de SLP (protocolo service location) e um exame dos agentes de diretório, veja o tid 2943614 em support.novell.com

Casos Práticos 2: A habilitação do IP de transmissão múltipla dentro da rede de produção derruba redes IPX existentes

As redes podem experiennce uma perda da conectividade de IPX repentina e completa para o PC cliente.

Isto pode acontecer porque o software do cliente 3.x do Novell netware preferirá o IP para o protocolo de camada de rede sobre o IPX à revelia. Consequentemente, se um server somente IP de Novell 5.X não configurado corretamente para o início de uma sessão e o IP Multicasting do Novell netware dentro da rede é permitido, todas as máquinas cliente preferirão a conexão ao server de Novell 5.X. Se o server de Novell 5.X não está corretamente ciente de recursos de rede existente, os clientes não poderão aceder aos recursos existentes.

Para resolver esta edição, configurar o roteamento IP Multicast para excluir o SLP ou configurar corretamente os server do Novell netware 5.X.

Casos Práticos 3: Por que Novell IP Não Funciona por Meio de um Cisco Router Executando NAT?

As implementações de NAT traduzem endereços IP de Um ou Mais Servidores Cisco ICM NT nos cabeçalhos de pacote de informação e as circunstâncias especiais procuram a porção de dados do pacote e traduzem referências de endereços IP incorporados. Contudo, o software de NAT Cisco atual não traduz referências encaixadas IP de Novell para o NDS ou o SLP nas porções de dados do pacote IP. Em consequência, os dispositivos na rede pública tentarão contactar recursos através dos endereços privados NON-traduzidos. Desde que as redes públicas não poderão às redes privadas, as conexões falharão. A solução alternativa para criar conexões IP de Novell com o NAT é usar uma solução de VPN.

Para mais informação, veja o TID 2948010 em support.novell.com

Casos Práticos 4: Logon de Novell IP lento

O Troubleshooting de Login IP do Novell lento é o mesmo que o login de IPX lento. Veja os Casos Práticos #8 sob Casos Práticos de Novell IPX.

Perguntas comuns de configuração

Por que não consigo configurar mais de 200 redes IPX no meu roteador?

Um roteador Cisco pode segurar mais de 200 Redes IPX em sua tabela de roteamento, por exemplo, mas você não pode configurar mais de 200 interfaces IPX em um roteador (que usa o comando ipx network). O limite tem sido alcançado somente recentemente agora que nós temos os switch de camada 3 que podem fornecer este número de relações. Este número é codificado nos IO e não será mudado provavelmente. Os switch de camada 3 podem executar mais de 200 relações porque a maioria das funções de switching são seguradas por alguns asics especializados que offload o processador principal tanto quanto o tráfego IP. Das interfaces IPX da necessidade a potência de CPU muito mais segurar o processo RIP/SAP, e mesmo aproximar-se o limite atual pode ser crítica.

Por que não posso executar o ping em um host Novell a partir do meu roteador?

Um roteador Cisco executa dois tipos de sibilo IPX:

  • Cisco IPX ping: este é o protocolo de proprietário que de Cisco do padrão um roteador se usará quando você tenta sibilar um endereço IPX.

  • Ping Novell IPX: este é único que os servidores Novell podem executar, e não é compatível com aplicação de Cisco.

Você pode usar o Cisco IPX ping para testar a Conectividade entre os dispositivos Cisco configurados para o IPX. Se você quer sibilar um servidor Novell, você tem que configurar o roteador para enviar o ping Novell IPX, usando o ipx ping-default novell do comando global configuration

Você pode igualmente emitir um comando extended ipx ping e selecionar a opção de eco padrão Novell.

O servidor Novell deve ter o que responde carregado para responder a um eco de Novell (sibilo). Para sibilar de um servidor Novell, um deve igualmente carregar o IPXPING.NLM no server. Nós observamos, no teste ocasional, aquele:

  • Os server do netware 3.x, os server do netware 4.0x, os clientes NETX, os clientes de VLM (v.1.20a), e o cliente MS para o netware não respondem aos ping Novell.

  • O netware 4.10 server, o netware MPR v3.x, o cliente 32, e o cliente DOS/Win95 MS respondem aos ping Novell.

Naturalmente, o sibilo pode igualmente falhar por outras razões do que uma má combinação no tipo de protocolo do sibilo. O sucesso do sibilo é igualmente dependente da tabela de roteamento de IPX (deve haver uma rota ao endereço de destino), a integridade do link (perdas de pacotes), filtrando, e assim por diante. Diretrizes a recordar ao usar o sibilo:

  • Quando sibilar um server é possível, assegure-se de que todas as edições da conectividade de IPX estejam endereçadas.

  • Quando o sibilo está falhando, na parte superior de todas as edições do possível problema de conectividade (de um problema complexo do roteamento IPX a um problema da funcionalidade do link), recorde que pode haver um problema simples com o server que não executa a funcionalidade de IPX ping. Significa que, infelizmente, não há frequentemente nada muito concluir quando um sibilo IPX a um server está falhando.

/image/gif/paws/10564/33a.gif

Neste exemplo, nós temos dois Roteadores conectados diretamente através de sua interface Ethernet no BABÁ da Rede IPX. Do roteador1, se nós sibilamos a relação router2, o roteador usa-se primeiramente à revelia, protocolo de proprietário de Cisco:

router1#ping ipx baba.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte IPX cisco Echoes to BABA.0000.0000.0002, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

Nós podemos forçar o protocolo do ping Novell usando o comando extended ping:

router1#ping ipx
Target IPX address: baba.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Novell Standard Echo [n]: y
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to BABA.0000.0000.0002, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

A outra possibilidade é ajustar o protocolo do sibilo do padrão para ser Novell um:

router1#conf t

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

router1(config)#ipx ping-default novell 

router1(config)#^Z

2w1d: %SYS-5-CONFIG_I: Configured from console by console

router1#ping ipx baba.0.0.2


Type escape sequence to abort.

Sending 5, 100-byte IPX Novell Echoes to BABA.0000.0000.0002, timeout is 2 seconds:

!!!!!

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

router1#

Mudando o sibilo datilografe a Novell é somente importante quando você tenta sibilar um host que executa o protocolo de Novell. Não sibila um host de Novell não significa necessariamente que a Conectividade a este host é quebrada (não todos os anfitriões de Novell respondem ao ping Novell). Sibilar um roteador é-lhe uma boa maneira de conectividade de IPX dos testes.

Por Que Não é Possível Configurar o IPX Routing?

Você deve ter o IOS Software correto para configurar o roteamento IPX.

Muito frequentemente, um roteador é entregado com um software padrão no flash e este software padrão não pode apoiar o IPX (mesmo se você pagou uma licença pelo suporte de IPX). Você então tem que promover seu roteador ao software que você é licenciado para. O suporte de IPX é geralmente parte do conjunto de recursos do desktop, que é identificado frequentemente com um “d” no nome da imagem:

c6sup-ds-mz.121-1.E2.bin

Veja este conjunto de recursos do desktop como um conjunto de recursos mínimo que inclui o suporte de IPX. Conjunto de recursos da “empresa” (identificado com “j” no lugar o “d” acima), que inclui o conjunto de recursos do desktop, naturalmente, igualmente apoiará o IPX. Verifique os Release Note de IOS para ver se há as características exatas disponíveis nos IO que você está executando.

O que é o comando ipx pad-process-switched-packets?

Este comando é usado controlando se os pacotes de comprimento ímpares estão acolchoados, assim que para ser enviado como pacotes de comprimento planos em uma relação. O comando ipx pad-process-switched-packets afeta pacotes comutados por processamento somente, assim que você deve desabilitar o interruptor rápido antes que o comando ipx pad-process-switched-packets tenha todo o efeito. O comando era necessária devido a alguns anfitriões IPX que rejeitaram os pacotes de Ethernet que não são acolchoados. Determinadas topologias podem conduzir a tais pacotes que estão sendo enviados em uma rede dos Ethernet remotas. Sob circunstâncias específicas, acolchoar em mídias intermediárias pode ser usado como uma solução temporária para este problema.

Esse comando está habilitado por padrão. Contudo, a especificação da unidade Ethernet de Novell diz que os pacotes IPX devem “ser evenized” pelo dispositivo de envio. Isto é devido aos dispositivos legado que tiveram problemas com pacotes de comprimento ímpar e não devem ser uma edição atualmente, mas a exigência persiste.

Um dispositivo não seguinte o requisito de Novell legado pôde produzir pacotes de comprimento ímpar. Os Pacotes ímpares puderam igualmente resultar ao distribuir de uma encapsulação IPX a uma outra encapsulação IPX diferente. Alguns encapsulamentos têm o comprimento diferente e uma mudança no encapsulamento pode produzir um pacote de comprimento ímpar.

Os Cisco Routers suportam o recurso de extensão de pacotes IPX para congestionamento de rede curva enviando pacotes maiores de atualização de RIP/SAP?

Esta é uma característica suportada. À revelia, um pacote RIP IPX contém 25 rotas e um pacote de SAP de IPX contém as seivas 7. O número de rotas e de seivas pelo pacote do RASGO e do SAP pode ser mudado mudando o tamanho de pacote de atualização respectivo. Veja a documentação no sap-max-packetsize IPX e o IPX rasgo-MAX-packetsize no comando ios prover para mais detalhes.

Apesar de configurar todos os servidores Novell e Roteadores para o IP somente, eu ainda estou vendo quadros IPX em farejadores de rastreamento. Por que isso ocorre?

O software de cliente Novell 3.x à revelia enviará quadros para o IP e o IPX em cima da inicialização na tentativa de entrar à rede Novell apesar da configuração de rede. A solução é desabilitar manualmente todos os protocolos de IPX no cliente PC.

Por que a habilitação de IPX EIGRP em uma interface de VLAN desabilita o IPX MLS dessa interface?

O MLS IPX é desabilitado com EIGRP IPX desde que enviar entre o RASGO e os domínios de EIGRP exige traduções dos campos específicos na porção de dados (Transmit Control) de pacotes de rota. Uma relação do roteador de IPX quando permitida para o RIP/NLSP, terá a contagem do salto máximo de 16. Quando um roteador está no limite de um domínio de roteamento NLSP/RIP e EIGRP, a relação está configurada com o EIGRP e o NLSP/RIP. É necessário remover o apoio MLS para essa relação se o salto máximo é configurado para ser 16 ou menos porque neste caso, o valor do transmit control (TC) estará traduzido em vez do incremento por 1 quando um pacote atravessa de um domínio de roteamento a outro. O MLS-SE não tem o conhecimento sobre o protocolo de roteamento que está sendo usado e o hardware MLS não poderá reescrever corretamente o campo do transmit control (TC).

“Os mls IPX estarão desabilitados no <vlan_id> de Vlan devido mensagem ao uso do eigrp” aparecem somente se os saltos máximos IPX estão ajustados a 16 quando o IPX EIGRP está configurado. Para todos valores restantes (17-254) nenhum tal mensagem de advertência é indicado. O IPX MLS trabalha muito bem para um valor do salto de 16 embora há um aviso.

O comando aumentar o valor do transmit control (TC) acima de 16 é value> dos <max_hops dos SALTOS MÁXIMOS IPX

Não há nenhumas desvantagem/vantagem específicas em aumentar o contagem de saltos.

Problemas comuns de conectividade

Entendendo o processo de logon do cliente IPX

Como um cliente conecta a uma rede Novell?

Se um cliente precisa de encontrar um server em uma árvore a mais próxima específica do servidor de diretório (NDS), o cliente transmitirá um tipo SAP 3 para o pedido do Get Nearest Directory Service do tipo de serviço 0278 (GNDS). Todo o servidor de NDS (configurado para responder aos pedidos GNS e GNDS) situado no mesmo segmento roteado que o cliente responderá com o nome da árvore de NDS que pertence a e de seu número de IPX interno. O cliente verificará o nome da árvore na resposta contra o nome da árvore que precisa (de acordo com o que o cliente se ajustou como sua árvore preferida). Se é a árvore correta o cliente transmitirá um pedido do RASGO para uma rota ao número de IPX interno forneceu na resposta. O server responderá dizendo que é a rota a esse número de IPX interno. O cliente unicast um pedido estabelecer uma conexão a esse server e começar o processo de autenticação. Se o server no segmento local não é um servidor de NDS que não responderá ao pedido inicial GNDS porque pode somente fornecer o tipo de serviço 0004, não 0278. Nenhuns servidores de NDS que não guardam réplicas NDS não responderão ao pedido. Se nenhumas das respostas contêm o nome correto da árvore de NDS, o cliente emitirá um tipo-1 de SAP para o pedido do tipo de serviço 0278 (GGDS). Todos os servidores de NDS situados no mesmo segmento roteado responderão com uma lista de serviços, apesar da configuração de servidor A MAIS PRÓXIMA da RESPOSTA GET. O cliente lerá todas as respostas ao GGDS que procura o nome correto da árvore de NDS. Uma vez que encontra uma entrada para a árvore correta, tentará estabelecer uma conexão a esse server. O cliente tentará estabelecer uma conexão à primeira entrada que contém o nome da árvore correto, não o mais próximo desde isto uma consulta geral de serviços, a pergunta não a mais próxima do serviço. Se o cliente está pedindo um servidor de encadernação (ou o cliente tem somente um servidor preferido ajustado em sua configuração de cliente) que o mesmo processo ocorrerá, simplesmente o tipo de serviço do pedido será 0004 em vez de 0278. Adicionalmente, se o server tem o conjunto de servidor O MAIS PRÓXIMO da RESPOSTA GET a FORA de então o server não responderá aos pedidos GNS (tipo de serviço 0004) ou GNDS (tipo de serviço 0278)

Fluxograma para o início de uma sessão do cliente Novell

NDS (Novell 4.11)

  1. Em cima da inicialização, o cliente enviará um pedido GNDS. Se o cliente é configurado ao automóvel detecte o tipo de frame, o cliente enviará quatro GNDS, um para cada tipo de frame.

  2. Todos os servidores locais (ou os roteadores Cisco se segmento sem servidor) responderão com uma resposta de GNDS.

    O cliente usará a primeira resposta de GNDS se os servidores múltiplos ou o Roteadores respondem ao pedido GNDS. A resposta de GNDS conterá o número interno de rede e o nome da árvore do servidor respectivo.

  3. Se a resposta de GNDS tem a árvore correta, o cliente emitirá um pedido do RASGO para o número de IPX interno fornecido na resposta de GNDS.

Como um roteador Cisco escolhe o server para incluir em uma resposta de GetNearestServer (GNS)?

O comando show ipx server unsorted mostrará em primeiramente posiciona o nome do server que será usado para responder ao pedido seguinte GNS. No Software Release 9.21 ou Mais Recente, use o comando ipx gns-round-robin permitir o Balanceamento de carga das respostas aos pedidos GNS entre serviços da métrica igual. A maneira que os server são pedidos é descrita no seguinte documento: Como os servidores são classificados?

O que é a sequência de conexão do cliente com e/ou sem servidor preferido?

Para a sequência de conexão sem servidor preferido, emita as seguintes etapas:

  1. Encontre o serviço (pergunta & a resposta GNS)

  2. Encontre a rota para prestar serviços de manutenção (pergunta & a resposta do RASGO)

  3. Faça a conexão ao server o mais próximo

  4. Obtenha a informação de servidor de arquivo

  5. Negocie o tamanho de buffer

  6. Cancele a conexão anterior

  7. Obtenha a data e hora do servidor de arquivo

Para a sequência de conexão com servidor preferido, emita as seguintes etapas:

  1. Encontre o serviço (pergunta & a resposta GNS)

  2. Encontre a rota para prestar serviços de manutenção (pergunta & a resposta do RASGO)

  3. Faça a conexão ao server o mais próximo

  4. Obtenha a informação de servidor de arquivo

  5. Negocie o tamanho de buffer

  6. Leia o valor do proprietário do “servidor preferido” armazenado no server o mais próximo

  7. Encontre a rota ao servidor preferido

  8. Crie a conexão ao servidor preferido

  9. Obtenha a informação de servidor de arquivo do servidor preferido

  10. Negocie o tamanho de buffer

  11. Cancele a conexão do serviço com o server o mais próximo

  12. Cancele a conexão anterior com servidor preferido

  13. Obtenha a data e hora do servidor de arquivador

Isto ainda exige a pergunta/resposta GNS do server o mais próximo, mas não termina a sequência de conexão com o server o mais próximo. Usa o server o mais próximo para aprender como obter ao servidor preferido. Uma vez a rota ao servidor preferido é instruída, destrói a conexão com o server o mais próximo e repete a sequência de conexão com o servidor preferido.

Como você filtra respostas aos pedidos GNS ou GGS?

É útil controlar o mecanismo usos de um roteador responder a um pedido do cliente GNS. A fim responder a um cliente, os IO selecionam um dos server conhecidos pelo roteador. Os IO fornecem uma maneira de impedir que alguns server nesta lista estejam usados, usando o comando ios:

saída-gns-filtro IPX {access-list-number|nome}

Este comando, uma vez aplicado a uma relação, assegurar-se-á de que o roteador esteja fornecendo somente aos clientes um server o mais próximo que combina a lista de acesso especificada.

Conectando clientes à rede

Por que não posso eu conectar meu cliente quando anexado diretamente a um interruptor?

As edições que podem resultar desta configuração são descritas inteiramente no seguinte documento usando Portfast e em outros comandos fixar atrasos da conectividade de inicialização de estação de trabalho.

Basicamente, se você tem um PC conectado diretamente a uma porta no Catalyst Switch, certifique-se de que você tem os recursos de portfast permitidos. Para ajustá-la com o CatOS, use o comando:

set spantree portfast enable <module/port>

Adicionalmente, se você tem o entroncamento e os módulos capacitado de canalização (por exemplo, WS-X5225R no catalizador 5000 e todos os módulos do catalizador 6000 são entroncamento/canalização capaz) você tem que se certificar de que você os desligou manualmente, usando os comandos seguintes:

set trunk <module/port> off set port channel <module/port-range> off

Do software 5.2 na família do Catalyst 4000/5000 e de 5.4 no Catalyst 6000 Family, estes três comandos podem ser empacotados em um único comando macro:


set port host <module/port>

Há alguma licença ou questão de servidor que afetem a conexão?

A primeira coisa que um cliente Novell de conexão faz é enviar um pedido GNS (obtenha o server o mais próximo). Este pedido é respondido por um server ou por um roteador. O cliente tenta então conectar usando o server especificado na resposta. Há dois problemas comuns que podem conduzir a uma falha da conexão:

  • O server contactado não responde ao GNS. Se o número interno de rede do server o mais próximo não é 0000.0000.0001, a seguir é provavelmente um servidor NT que ignore o GNS.

  • O server contactado é ser executado curto das licenças. Somente um número limitado de clientes podia conectar, tentativas adicionais está falhando.

Em ambos os casos, se um roteador Cisco é involvido, verifique que server é dado ao cliente que usa o comando show ipx server unsort. Você pode então usar o comando ipx output-gns-filter filtrar os server que não devem ser dados como uma resposta.

Haverá Problemas de conexão devido para duplicar endereços IPX ou MAC?

Normalmente, todos os endereços IPX na rede devem ser diferentes, porque um MAC address é parte de eles. Contudo, há muitos casos onde o usuário pode codificar um MAC address, neste caso, toda atenção do pagamento à unicidade deste endereço. Também, seja muito cuidadoso não duplicar um endereço IPX ao cortarar-col a configuração de um roteador a outro por exemplo. Isto é extremamente importante para as interfaces WAN que usam o MAC address definido no comando ipx routing. No exemplo seguinte, o roteador A e as configurações B foram duplicados. O administrador de rede mudou a Rede IPX no cada relações mas esqueceu-a atualizar a linha do roteamento IPX, que é a mesma em ambas as configurações.

/image/gif/paws/10564/33g.gif

Uma interface serial não tem seu próprio MAC address. O roteador usará o MAC address especificado no comando ipx routing construir o endereço IPX de suas interfaces serial. Neste caso, o roteador A e o roteador B terão o exato o mesmo endereço AAA.0000.0C14.11E1 IPX. Naturalmente, há muitas outras maneiras de cair no problema de endereço duplicado. O TAC vê muitos problemas de conectividade causados pelo endereçamento duplicado, seja assim muito cuidadoso ao atribuir uma Rede IPX ou um MAC address.

Em um dado enlace:

  • Todos os server e Roteadores devem ser configurados com números de rede de IPX originais para um encapsulamento dado.

  • Todos os endereços MAC devem ser originais.

Exibindo servidores e serviços

Por que não posso eu alcançar um server/serviço específicos?

Se um cliente está tentando alcançar um server através de um roteador Cisco, use o comando show ipx server no roteador:

Se o server/serviço que você está procurando não está entre aqueles alistados quando você emitir o comando show ipx server, e lá é nenhuma lista de acesso na configuração que quebraria a Conectividade, a seguir o roteador muito provavelmente não a causa do problema. Se você não vê o serviço no roteador, certifique-se de que a Rede IPX do server aparece na tabela de roteamento. Emita um comando show ipx route mostrar a tabela de roteamento de IPX. Um serviço não será anunciado se o roteador não tem uma rota à rede correspondente.

Se o server está anexado diretamente ao roteador mas ainda não aparece quando o server IPX da mostra está emitido, seja certo que você configurou a mesma Rede IPX com a mesma encapsulação IPX no server e no roteador.

/image/gif/paws/10564/33b.gif

Neste exemplo, seja certo que o servidor Novell está configurado com SNAP de encapsulamento e que o endereço IPX é BORRACHO. Se o encapsulamento é errado, os pacotes enviados pelo server estarão rejeitados pelo roteador. Se as Redes IPX não combinam, o server indicará um Mensagem de Erro que aponta a essa má combinação.

No roteador, o comando show ipx traffic dará alguma informação util, infelizmente para o dispositivo inteiro, não para uma relação específica. Atenção do pagamento ao campo " erro de formato ". Será incrementado cada vez que o roteador recebe um pacote com o encapsulamento errado. Se este contador está aumentando, você é muito provável ter uma incompatibilidade de encapsulamento.

O [<interface>] do comando show ipx interface dá detalhes relativos IPX para uma relação específica. Resume o tipo de encapsulamento, o endereço IPX, e a lista de acesso configurada para a relação. Quando pesquisar defeitos o server/prestam serviços de manutenção à visibilidade, é útil certificar-se de uma relação específica esteja recebendo atualizações do RASGO e do SAP de um vizinho. Isto é possível usando este comando.

Por que não posso eu alcançar um servidor de IPX com o RConsole?

Quando o RASGO e o EIGRP levarem a informação de rede, SAP leva a informação do serviço. Cada pacote de SAP de IPX gerado por um roteador Cisco pode levar até sete entradas 64-byte SAP mais 32 bytes de despesas gerais IPX (para um total de 480 bytes), além do que a carga adicional de encapsulamento de mídia. Quando são levados dentro dos pacotes EIGRP, os pacotes de SAP de IPX consistem em um cabeçalho EIGRP padrão com um valor do opcode de 6, seguido pelo payload padrão de um pacote IPX SAP padrão sem o cabeçalho de IPX original.

Em um intercâmbio de pacotes típico de SAP, um cliente Netware transmitirá SAP pergunta para encontrar um servidor de diretório, como indicado pelo campo do tipo de servidor de SAP (veja a lista do serviço de Novell SAP). Os pacotes de resposta de SAP contêm o endereço do IPX interno dos server que oferecem serviços de diretório. O cliente envia então uma transmissão do RASGO para encontrar o trajeto ao endereço do IPX interno do server.

As seguintes etapas estabelecem uma conexão de rconsole:

  1. O cliente do RConsole transmite um pedido de SAP que procura um server. Especificamente, o RConsole manda uma pergunta do general serviços para o tipo server 0x107. O roteador Cisco deve ser permitido para anunciar o tipo server 0x107 para que o RConsole trabalhe no PC. O cliente envia um pedido de SAP da consulta do server mesmo que seja registrado atualmente em um server.

    • Se há um server no segmento, responde ao cliente.

    • Se os clientes IPX estão em um segmento sem servidor, o roteador escolhe a primeira entrada de SAP em sua lista não variada para responder ao pedido GNS dos clientes IPX. Em alguns casos, a primeira entrada de SAP no roteador é o server errado. Emita o comando show ipx server unsorted capturar isto. Como uma ação alternativa, crie uma lista de acessos de SAP para obstruir esse server e para aplicá-lo como o filtro GNS.

  2. O cliente envia um pedido do RASGO para o endereço do IPX interno do primeiro server que respondeu.

  3. Uma vez que o cliente aprende a maneira a mais rápida de obter ao server, envia-lhe um pacote de requisição da conexão SPX.

Se você é incapaz de fazer uma conexão de rconsole a um servidor netware particular, use as seguintes etapas para determinar se a causa é uma questão de rede ou uma questão de servidor:

  • Pode você ver algum server? Alguns server? Server que são locais? Server que são através de WAN?

  • O outro tráfego IPX é afetado?

  • Que a tabela de servidor de IPX olha como no roteador o mais próximo?

  • Você vê a rede interna ID do server na tabela de roteamento de IPX do roteador?

  • Indique a Rede IPX que você está vindo de e o server em que você está tentando ao RConsole:

  • Você está usando o netware 4.11 ou o netware 5? É IP de Novell? Pode você sibilar o server do netware 5? Ou seja tente conectar pelo IP contra por nome. Em caso afirmativo, o DNS não é resolved.

Em alguns casos, uma base de dados corrompida em um server causa problemas de conexão SPX, particularmente porque a base de dados corrompida é enviada a outros server. Frequentemente, você pode fixar este problema executando o utilitário de reparo DS. Contudo, se o reparo DS não restaura o banco de dados, uma repartição do server pode ser exigida. Se você não pode fazer uma conexão de rconsole usando o número interno de rede, o problema é com o servidor netware.

Novell igualmente publica dicas técnica em linha em uma base de conhecimentos. A seguinte ponta pode ser útil pesquisar defeitos a edições do RConsole da perspectiva dos servidores de IPX. Esta ponta é fornecida como um recurso para clientes Cisco.

O “RCONSOLE -4.10-112 SPX estabelece a conexão não é estabelecido uma conexão ao servidor desejado.”

  1. O REMOTE.NLM é carregado no server? O RSPX.NLM é carregado?

  2. Você verificou o DS e certificado lhe é saudável e esse tudo está sincronizando?

  3. Os erros podem ser causados por um roteador que esteja filtrando para fora o RConsole SAP. O tipo SAP 0107 é o RConsole SAP, e não deve ser filtrado para fora se o RConsole é trabalhar corretamente.

  4. Um cartão ruim NIC pode proibir o cliente de estabelecer a conexão SPX.

  5. Faça o absolute certo que todos seus números de rede de IPX são originais. Este é a razão do número um pela qual o RConsole falha, mas às vezes o mais duro pesquisar defeitos.

  6. Force o tipo de frame no cliente em vez de Auto-detectar o tipo de frame.

Solução

Na tela do RConsole, a imprensa INS e entra no número interno de rede IPX do servidor de destino. O número interno de rede IPX do server pode ser encontrado pela CONFIGURAÇÃO de datilografia no console de servidor. Se manualmente entrar no número interno de rede IPX permite que o RConsole trabalhe, poder-se-ia significar que a tabela de soquete IPX nesse server esteve excedida. Aumente o tamanho da tabela de soquete do máximo IPX: INETCFG - > protocolos - > IPX - parâmetros >IPX/SPX - tamanho da tabela de soquete do >Maximum IPX. O padrão é 1200. Aumente este valor a 2400 inicialmente. O server precisa de ser recarregado a fim restaurar este tamanho de tabela.

Por que eu não ver todos meus server em uma topologia de hub e spoke?

/image/gif/paws/10564/33f.gif

No diagrama acima, nós temos um roteador de hub conectado através de uma interface ponto a multiponto a diverso outro. Esta é redes de hub and spoke típicas de um Frame Relay. Todo o Roteadores é conectado na mesma Rede IPX A. Spoke que o Roteadores anuncia sua rede local X e Y ao hub, mas você não vê a rede Y na tabela de roteamento do roteador X (e similarmente você não vê X na tabela do roteador Y). Este problema é relacionado diretamente ao horizonte dividido. O RASGO não anuncia uma rota na relação onde aprendeu dele. Basicamente, o roteador de hub aprendido sobre a rede X em seu serial0 da interface WAN, conectado à rede A, e a ele nunca anunciará a parte traseira X no serial0. O roteador Y, igualmente conectado através do serial0 ao roteador de hub, nunca ouvir-se-á sobre a rede X.

As especificações Novell não permitem que o horizonte dividido seja desabilitado para o RASGO, tão lá são duas soluções principal disponíveis com roteadores Cisco:

  • Substitua a interface ponto a multiponto com diversas interfaces Point-to-Point. Isto pode ser feito criando diversas subinterfaces no serial0 do roteador de hub. O problema é que você precisa de atribuir um network number diferente para cada link de ponto a ponto criado, que significa uma mudança no método de endereçamento e um aumento do tamanho de tabela de roteamento.

  • Substitua o RASGO com o IPX EIGRP. Este último protocolo de roteamento permite a remoção do horizonte dividido (que usa o no ipx split-horizon eigrp do comando) e executa-a melhor em enlaces de WAN lentos (atualizações de acréscimo, e assim por diante). A única desvantagem é que todo o Roteadores deve ser Cisco em WAN.

Por que NetBios sobre o IPX não está dirigindo meu roteador?

Isto ocorre porque NetBios sobre o IPX confia em pacotes IPX do tipo de transmissão 20, isso não deve ser enviada por um roteador. A fim ter estes pacotes específicos enviados por um roteador, configurar o comando ipx type-20-propagation em cada relação que propagará o tráfego de netbios:

/image/gif/paws/10564/33cc.gif

Configuração do roteador1 Configuração do roteador2
ipx routing 0000.0000.0001

!

interface Ethernet0

 ipx network A

 ipx type-20-propagation

!

interface Ethernet1

 ipx network C

!

interface Serial0

 ipx network 1

 ipx type-20-propagation

 
ipx routing 0000.0000.0002

!

interface Ethernet0

 ipx network B

 ipx type-20-propagation

!

interface Serial0

 ipx network 1

 ipx type-20-propagation

 

Esta configuração inclui somente a divisória relevante IPX. Neste exemplo, hospede A e Host B estão executando NetBios sobre o IPX. O roteador1 e o roteador2 têm muito uma configuração de IPX básica. O comando ipx type-20-propagation foi adicionado em cada interface única que é suposta para retransmitir NetBios sobre o tráfego IPX. No este as considerações, os Ethernet de interface 1 do roteador1 não o precisam, porque não há nenhum host de Netbios no segmento de Ethernet.

Note que o comando type-20-propagation, embora imperativo, terá um impacto no desempenho em sua rede.

Problemas de desempenho

Uso de memória para rotas RIP e SAPs

IOS 10.0, 10.2 10.3 e acima
Rota 180 bytes para cada rota, adicionam bytes dos 50 pés para cada trajeto adicional se maximum-path > 1 160 bytes para cada rota, adicionam 70 bytes para cada adição se maximum-path > 1
SAP 200 bytes para cada SAP, adicionam 4030 bytes para cada tipo SAP 200 bytes para cada SAP, adicionam 4030 bytes para cada tipo SAP, e adicionam bytes dos 50 pés para cada trajeto adicional

Balanceamento de carga IPX no Cisco router

/image/gif/paws/10564/33e.gif

Se o roteador Z está configurado com o comando ipx maximum-paths 2 e o Roteadores A e B o obtém à mesma rede de destino no mesmo número de saltos, o roteador Z enviará então cada pacote ao destino ao roteador A e B em um estilo round-robin, com lento-interruptor e switching rápido.

Seja cuidadoso que neste caso particular, se você carrega o equilíbrio sobre trajetos da largura de banda desigual e você tem o pburst permitido, os pacotes estragados podem resultar. Umas versões de netware mais novas devem segurar este umas versões de netware melhor do que mais velhas, mas valem a tentativa remover a função de balanceamento de carga ou o pburst quando você está pesquisando defeitos um problema de desempenho nesta configuração. Desde IO 11.1, você pode igualmente permitir o compartilhamento de carga por host usando o comando ipx per-host-load-share. O compartilhamento de carga por host transmite o tráfego através do múltiplo, caminhos de custo iguais ao garantir que os pacotes para um host final dado tomam sempre o mesmo trajeto.

Desempenho ruim quando type-20-propagation estiver habilitada

A ajuda de IP em um roteador não é recomendada em uma rede, mas o comando ipx type-20-propagation não é recomendado igualmente, tanto quanto a carga de tráfego. Com um comando IP helper, o roteador toma um pacote de transmissão e transforma-o em um pacote do unicast (ou na transmissão direcionada) a fim enviá-la no segmento seguinte. Com o comando ipx type-20-propagation, o roteador toma-a uma transmissão e para a frente como a transmissão. O pacote do tipo 20 contém uma lista de todas as redes já idas completamente e o roteador nunca enviá-la-á para trás em uma rede que aparece nesta lista.

/image/gif/paws/10564/33d.gif

Deixe-nos supor o comando ipx type-20-propagation é permitido em cada relação, com três segmentos entre o roteador1 e os 2 (uma configuração comum com catalizador 5000 e RS conectados junto por um trunkof 20 VLAN, por exemplo).

  1. O PC1 emite uma transmissão do tipo 20.

  2. O roteador1 obtém o e para a frente uma cópia em cada segmento A B e em C (com lista do segmento D).

  3. O roteador2 obtém três cópias e para a frente cada um delas (a lista do segmento é DA para o primeiro DB para o segundo DC para o terço) aos dois outros segmentos que fazem a 6 mais cópias do pacote (o DA é envia a B e C, DB a A e a C, DC a A e B).

  4. O roteador1 obtêm estas seis cópias (SOLHA, DAC, DBA, DBC, DCA, DCB) e dianteiro todo ao último segmento que não o considerou.

  5. O roteador1 obtém os seis pacotes (DABC, DACB, DBAC, DBCA, DCAB, DCBA) e deixa-os cair todos porque têm o todo o cruzado todos os segmentos.

Com este exemplo nós podemos ver que cada transmissão gerará 15 mais pacotes entre os dois Roteadores. Com quatro links (VLAN) entre dois Roteadores você tem 64 pacotes. Com cinco links entre dois Roteadores você tem 325 pacotes, e assim por diante. Consequentemente, usar este comando causará um número aumentado de pacotes, que podem retardar ou fechar sua rede.

Para melhorar a situação, use os comandos seguintes:

Quando estes são configurados, nós certificamo-nos que o tipo 20 está vindo dentro em uma relação que seja uma rota principal de volta à fonte. Se não é, nós deixamos cair o pacote. Quando nós estamos indo enviar um pacote, nós verificamos se a rede/relação que nós a estamos enviando a não é uma rota de volta à fonte deste tipo 20 pacote, ou então nós a deixamos cair. Isto é além do que os oito saltos que verificam para ver se há laços que os atendimentos da especificação de roteador IPX para que nós façam com tipo 20s.

Configuração da lista de acesso

Filtrando um intervalo de redes IPX

A lista de acesso extendida IPX permite que você filtre uma escala das redes. Por exemplo, você pode ter uma grande Rede IPX. Todas as Redes IPX começam com o e o. As redes não precisam de ir a algum Roteadores, assim que eu filtrei cada um que usa os comandos seguintes:

interface Serial0



     ipx output-network-filter 805



     !



     access-list 805 deny  A43C0100



     access-list 805 deny  A43C0101



     access-list 805 deny  A43C0102



     .

     .

     .

Esta lista de acesso continua para 120 linhas. Como posso eu filtrar as Redes IPX que começam com o A43?

Tentativa usando o comando seguinte:

access-list 905 deny any A4300000.0000.0000.0000 FFFFF.FFFF.FFFF.FFFF

Seja certo incluem uma linha para permitir as rotas que você quer. Toda a palavra-chave representará “todos os protocolos” e é um argumento requerido. Os trabalhos de máscara no mesmo princípio que o wildcard mask IP. Os bit do host devem ser especificados, se não você não terá a opção da máscara. Você pode usar a lista de acesso extendida IPX em todas as mesmas maneiras que você pode usar a versão padrão. Se você está usando o protocolo netware link services (NLSP) como seu protocolo de roteamento, você precisará de usar áreas múltiplas assim que você pode rotas de filtro nos limites de área.

Depuração

Ao ver a saída de pacotes IPX debugar alguns pacotes são marcados como “Pacote ruim.” Por que esses pacotes são marcados como "Pacotes incorretos?"

Exemplo:

IPX: unable to forward, no helper A0000001.0000.0000.0001(455)to B0000001.ffff.ffff.ffff(455) typ 4
IPX: Fa0/0:A000000.0000.0000.0001->B00000001.ffff.ffff.ffff ln=173 tc=01, bad pkt

Isto pode ocorrer porque o soquete 455 é o número do soquete de NetBIOS e o endereço de destino da camada de MAC do pacote é transmissão. Este pacote estará deixado cair pelo roteador à revelia a menos que a propagação de tipo 20 IPX ou um ajudante-endereço IPX forem configurados. Veja a documentação em permitir a propagação de tipo 20 para mais detalhes em enviar a estes NetBIOS sobre transmissões direcionada IPX.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 10564