Roteamento Novell/IPX

Perguntas freqüentes sobre IPX Parte II

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 dá respostas para perguntas mais frequentes sobre o IPX.

Q. Que tipos SAP há?

x4 - File server
x2E - TCP/IP service
x47 - Novell print server
x107 - Remote console netware driver (RSPX)
x30C - Print sharing device
x4808 - Sitelock.nlm

Q. Que é o significado do “veneno SAP” no comando show ipx traffic?

A. SAP envenena (ou veneno SAP) é uma atualização de SAP que seja enviada por um dispositivo IPX. Quando o dispositivo IPX já não ouve um serviço, notifica a rede que esse serviço é inacessível. É o mesmo como SAP regular atualiza salvo que o contagem de saltos é ajustado a 16. É completamente normal ver um número diferente de zero de seivas do veneno na saída do comando show ipx traffic. Isto acontece quando um roteador (o trajeto a um serviço) ou um PC (o serviço próprio) foi recarregado ou por qualquer motivo se tornou inacessível.

Q. Como os roteadores Cisco seguram as seivas do veneno?

A. Parte 1: 9.1 Gerenciamento de SAP do veneno

  1. O roteador recebe um veneno SAP.
  2. Se a fonte de veneno SAP combina a fonte dos pares do nome do servidor/tipo de servidor de SAP na tabela de SAP, o roteador marca SAP como envenenado e ajusta um temporizador de um minuto. Se os endereços não são os mesmos, o pacote do veneno está rejeitado. Depois que o temporizador de um minuto expira, a entrada está removida da tabela do serviço, e um pacote de SAP do veneno é mandado todas relações restantes.
  3. Se o roteador recebe uma atualização de SAP que contenha uma métrica do NON-veneno dentro do tempo um pares combinados do nome do servidor/tipo de servidor está marcada “envenenado,” ele suprime da entrada do veneno e substitui-a com a entrada nova. Se nenhuma entrada nova é recebida, o temporizador do veneno expira, e a entrada é removida.

Parte 2: 9.21 e Gerenciamento mais atrasado de SAP do veneno

9.21 e um comportamento mais atrasado conformam-se à “especificação de roteador IPX” do Novell, Inc.

  1. O roteador recebe um veneno SAP.
  2. O roteador marca a entrada como envenenada e ajusta um temporizador de um minuto.
  3. O roteador gera imediatamente um pacote de SAP do veneno para este serviço para fora todas relações restantes.
  4. Quando o temporizador de um minuto expira, e, se o roteador não recebeu uma boa métrica nova para o serviço, o serviço está removido da tabela.

Em ambos os casos, quando um serviço é marcado como envenenado, a métrica associada com ela é 16, ou inacessível, e nenhum obtenha o serviço o mais próximo ou SAP pergunta os pacotes é respondido que contêm este serviço em uma resposta.

Q. Como um roteador Cisco escolhe o server para incluir em uma resposta de servidor a mais próxima da obtenção?

A. Parte 1: 9.1 Comportamento

O server do tipo pedido com o mais baixo hopcount é considerado o server “o mais próximo”. Se mais de um server do tipo pedido compartilha do mais baixo hopcount, primeiro na tabela de SAP está escolhido. Os server novos do mesmos tipo e hopcount que um que já existe na tabela são colocados na tabela antes da entrada extant. Esta é uma tabela de SAP da amostra:

    Total Novell Servers: 1

    Type   Name            Net Address              Port Hops    Interface
    4     MAGNOLIA        42.0000.0000.0001::0451      1        Ethernet2

As respostas para obter os pedidos os mais próximos do server para o tipo 4 contêm a MAGNÓLIA. Se um server novo do tipo 4, também um salto afastado, era instruído, a tabela olha como esta:

    Total Novell Servers: 1

    Type   Name            Net Address              Port Hops    Interface
     4     NEWSERVER       AA.0000.0000.0001::0451      1        Ethernet1
     4     MAGNOLIA        42.0000.0000.0001::0451      1        Ethernet2

Agora as respostas futuras para obter os pedidos os mais próximos do server para o tipo 4 contêm o NEWSERVER em vez da MAGNÓLIA.

Parte 2 9.21 e comportamento mais atrasado

O server do tipo pedido com a mais baixa métrica da rota é considerado o server “o mais próximo”. Se mais de um server do tipo pedido compartilha da mais baixa métrica, primeira na tabela de SAP está escolhido, a menos que o processamento round robin GNS das respostas de GNS for permitido. Os server novos do mesmos tipo e métrica que esse que já existe na tabela são colocados na tabela antes da entrada extant. Se o arredondamento robin GNS é permitido, as respostas são equilibradas entre os server desse tipo com medidor igual da rota. Por exemplo, olhe esta tabela de SAP:

    1 Total IPX Servers

    Table ordering is based on routing and server info

          Type   Name            Net Address       Port   Route  Hops    Itf
    P      4     MAGNOLIA        42.0000.0000.0001::0451   3/02     2    Et2

As respostas para obter os pedidos os mais próximos do server para o tipo 4 contêm a MAGNÓLIA. Se um server novo do tipo 4 com a mesma métrica era instruído, a tabela olha como esta:

    2 Total IPX Servers

    Table ordering is based on routing and server info

          Type   Name            Net Address       Port   Route  Hops    Itf
    P      4     MAGNOLIA        42.0000.0000.0001::0451   3/02     2    Et2
    P      4     NEWSERVER       AA.0000.0000.0001::0451   3/02     2    Et1

Observe que os 9.21 e a tabela mais atrasada são por nome ordem classificada com os tipos dos custos iguais. A fim ver a tabela nas respostas da ordem GNS são usados, usam o comando show ipx server unsort.

     router>show ipx server unsort
     Codes: S - Static, I - Incremental, P - Periodic, H - Holddown
     2 Total IPX Servers

     Table ordering is based on routing and server info

          Type   Name            Net Address       Port   Route  Hops    Itf
    P      4     NEWSERVER       AA.0000.0000.0001::0451   3/02     2    Et1
    P      4     MAGNOLIA        42.0000.0000.0001::0451   3/02     2    Et2

Agora as respostas futuras para obter os pedidos os mais próximos do server para o tipo 4 contêm o NEWSERVER. Se um outro server novo com a mesma métrica é ouvido de, a tabela olha como esta:

    3 Total IPX Servers

    Table ordering is based on routing and server info

          Type   Name            Net Address       Port   Route  Hops    Itf
    P      4     ANEWSERVER      AB.0000.0000.0001::0451   3/02     2    Et1
    P      4     MAGNOLIA        42.0000.0000.0001::0451   3/02     2    Et2
    P      4     NEWSERVER       AA.0000.0000.0001::0451   3/02     2    Et1

A ordem não escolhida olha como esta:

    3 Total IPX Servers

    Table ordering is based on routing and server info

          Type   Name            Net Address       Port   Route  Hops    Itf
    P      4     ANEWSERVER      AB.0000.0000.0001::0451   3/02     2    Et1
    P      4     NEWSERVER       AA.0000.0000.0001::0451   3/02     2    Et1
    P      4     MAGNOLIA        42.0000.0000.0001::0451   3/02     2    Et2

O primeiro pedido GNS para o tipo 4 serviço é respondido com ANEWSERVER; o segundo pedido GNS é respondido com NEWSERVER; o terceiro pedido é respondido com MAGNÓLIA; e o quarto é respondido com ANEWSERVER.

Q. Como o equilíbrio da carga de IPX trabalha no roteador Cisco?

                   |   ------------     ------------   |
                   |---| router A |--\--| router C |---|
|   ------------   |   ------------     ------------   |   ------------
|---| router Z |---|                                   |---| router X |
|   ------------   |   ------------     ------------   |   ------------
                   |---| router B |--\--| router D |---|
                   |   ------------     ------------   |

A. Se o roteador Z é configurado com IPX MAX-PATH 2, e o Roteadores A e B o obterá à mesma rede de destino na mesma métrica da rota (o roteador X), o roteador Z envia pacotes a esse destino, que alterna entre os dois trajetos, com o switching lento de IPX e o interruptor rápido IPX. Quando o switching independente ou o switching IPX SSE IPX são permitidos, o Balanceamento de carga ocorre na pela base de destino, como faz com balanceamento de TCP/IP.

Q. O modo PBURST, que permite que os pacotes múltiplos sejam proeminentes sem um reconhecimento, afeta o Balanceamento de carga?

A. Os clientes Novell e os server são os únicos dispositivos que são envolvidos em negociações PBURST/LIPx. Cisco está livre escolher o que trajeto que pensa é o melhor para o pacote, assim, se o maximum-path IPX é maior de um, os pacotes podem tomar um trajeto diferente e chegar fora de serviço. A estação de destino tem que tratar a requisição de pacotes. Umas versões mais velhas do netware não seguram pacotes estragados muito bem. Certifique-se que você executa as correções de programa as mais atrasadas que se referem a PBURST/LIPx e aos NLM os mais atrasados para o desempenho o melhor PBURST/LIPx.

Q. Como eu inundo transmissões globais IPX?

A. Parte 1: 9.1 Comportamento

Quando os roteadores Cisco usarem os pacotes do “ajudante”, que usam a característica do ajudante-endereço, o roteador para a frente que o pacote de transmissão recebeu ao endereço IPX configurado no comando helper-address nessa relação. No caso da inundação, o helper address (endereço do ajudante) é -1.ffff.ffff.ffff na relação receptiva, e o pacote é mandado a todas relações restantes que executam o IPX, com o network number dessa relação colocada no campo da rede da fonte do pacote.

Por exemplo, se sua Rede IPX contém segmentos da Rede IPX 10, mas somente dois daqueles segmentos são inundados com o tráfego IPX/NetBIOS, você configuram endereços de rede específicos no ajudante-endereço.

      Interface ether 0
      ipx network 1000
      ipx helper-address 1011.ffff.ffff.ffff

Na rede distante, você tem esta configuração:

      Interface ether 0
      ipx network 1011
      ipx helper-address 1000.ffff.ffff.ffff

Estas transmissões são consideradas somente em segmentos de rede 1000, 1011 e as redes entre eles (o caminho roteado entre eles). Se -1.ffff.ffff.ffff (inundação) é usado, as transmissões estão enviadas em todo o 10 dos segmentos de rede.

Os helper addresss (endereço do ajudante) múltiplos para o IPX são apoiados na liberação 9.1 e mais alto.

Parte 2: 9.21 Comportamento

Aplique o comando ipx type-20-propagation a todas as relações que precisam de receber ou envie estes pacotes. Refira o capítulo 19 do manual de configuração do Produtos do roteador para obter mais informações sobre das facilidades de propagação de Novell NetBIOS/Type-20.

Em umas versões de manutenção mais novas, o ajudante do tipo 20 do comando ipx desliga os 9.21 e o Gerenciamento mais atrasado type-20-propagation destes pacotes e usa o estilo 9.1 da configuração do ajudante-endereço IPX a fim enviar estes pacotes.

Q. Como eu impeço pacotes inundados da circulação infinita através de minha rede?

A. A topologia onde esta ocorre é quando você inunda (não ajudante através dos endereços direcionado), e lá é caminhos múltiplos de volta à fonte do pacote de NETBIOS. Há os casos onde dar laços de alguns pacotes de transmissão ocorre. Os protetores podem ser postos no lugar para impedir as transmissões extra indesejáveis, que são parte de um tráfego normal IPX/NetBIOS:

  1. Evite o comando ipx helper-address -1 ffff ffff ffff. Sempre que possível use endereços direcionado.
  2. Configurar as ajudante-lista IPX para identificar que os pacotes você querem enviado, e usam estes comandos global:
           netbios-socket-input-checks  Limit input of non-type 20 netbios
                                        bc packets
           type-20-input-checks         Do additional input checks on type 20
                                        propagation packets
           type-20-output-checks        Do additional output checks on type 20
                                        propagation packets
    
    Por exemplo, talvez você quer somente as transmissões de pacote do tipo 20 IPX enviadas, e não as transmissões usadas pela versão de shareware original da desgraça do jogo da rede. Em um sistema IO 10.2-based, você pode criar uma lista do ajudante que use a lista de acesso 901:
           access-list 901 permit 20 -1 0 -1 0
           access-list 901 deny -1
    

Q. Que são IPX “tiquetaques,” e Cisco usa-os para calcular o atraso?

A. Um tiquetaque é uma unidade de 1/18th do atraso aproximadamente de segundo longo; há 18.21 tiquetaques num segundo. Os tiquetaques são usados para medir quanto tempo toma um pacote para alcançar um destino. O campo dos tiquetaques de uma rota do IPX é sempre pelo menos uma. Seu valor é usado pelo shell do netware para determinar quanto tempo deve esperar uma resposta de um servidor de arquivo e por roteadores NETWARE para fazer decisões de roteamento.

Em 9.1, nós levamos a informação dos tiquetaques na tabela de roteamento mas não a usamos para decidir a melhor ruta a um destino. Em lugar de, nós usamos o contagem de saltos a essa rede. Os tiquetaques adicionais a adicionar a uma rota que atravessam Cisco em 9.1 são baseados na configuração de retardo de interface.

Em 9.21 e em umas versões do IOS mais atrasadas, os tiquetaques são a métrica de roteamento preliminar para determinar o melhor caminho a um destino. Os tiquetaques adicionais a adicionar a uma rota que atravessam Cisco são determinados “pelo atraso x IPX” configurado para essa relação. À revelia, todas as interfaces de LAN têm valores dos tiquetaques de 1, e todas as interfaces WAN têm valores dos tiquetaques do 6. Para o cálculo dinâmico de tiquetaques para interfaces WAN, uso IPXWAN, que é apoiado na liberação 10.0 e mais atrasado.

Q. Que o meio do “erro de formato” da “no tráfego IPX mostra” indica?

A. Um erro de formato ocorre quando um roteador recebe um pacote IPX com um tipo diferente da encapsulação IPX do que a relação do roteador, ou quando o comprimento do pacote recebido é menor de 30 bytes ou maior do que a unidade de transmissão máxima de interface (MTU).

Q. Pode você explicar o comando " ipx routing "?

A. O endereço no [address] do roteamento do comando novell é somente relevante para linhas da série NON-IPXWAN. As relações com um endereço do hardware da camada do Mac usam esse endereço como o endereço de host IPX. Linhas de série que não mandam um endereço do hardware da camada do Mac usar o endereço especificado no comando " ipx routing ". Se nenhum endereço é especificado no comando " ipx routing ", o MAC address da primeira relação da IEEE está usado como o endereço de host. Se não há nenhuma relação da IEEE no roteador ou não estão acima de quando o roteamento IPX está permitido, o sistema gera um endereço pseudo--MAC aleatório para usar-se.

      hostname Router
      !
      enable password SwR4dWeQ
      !
      ipx routing 0000.0c19.2b58
      !
      interface Serial 1
      ipx network FC01
      ...
      Router>show ipx int ser 1
      Serial1 is up, line protocol is up
      IPX address is FC01.0000.0c19.2b58 [up] line-up, RIPPQ: 0, SAPPQ: 0

O IPXWAN usa um método diferente para determinar seu endereço de host IPX. Refira o RFC1634 para detalhes.

Q. Como eu configuro o IPX sobre o Frame Relay?

A. Use estes comandos:

     int serial 0
     encap frame-relay
     ipx network 100
     frame-relay inverse-arp ipx DLCI

Você possivelmente tem que traçar um identificador da conexão de link de dados (DLCI) ao endereço IPX se o roteador remoto não apoia o ARP inverso que este exemplo traça o roteador remoto com um endereço IPX de 100.0000.0c00.1122 a DLCI 123.

     frame-relay map novell 100.0000.0c00.1122 123 broadcast

Q. Que sobre todos os tipos da encapsulation do Ethernet de Novell?

A. O ETHERNET_802.3 do tipo de frame é o encapsulamento de proprietário de Novell. Puseram pacotes SPX/IPX diretamente dentro de 802.3 quadros; não usam 802.2 LLC nem AGARRAM-NOS. O resultado é não padronizado e pode causar problemas quando misturado com o tráfego 802.3/.2 “real”. Isto é chamado do “novell-ether 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 encapsulados em quadros do Ethernet II com tipo código 8137. Estes quadros são os mesmos como os novell frame à exceção do tipo código do dois-octeto/comprimento de frame colocam. Isto é chamado o “encapsulamento Novell ARPA” na terminologia de Cisco.

O ETHERNET_SNAP do tipo de frame, ou o Cisco Novell Encapsulation SNAP, são um pacote de Ethernet com um cabeçalho SNAP.

O tipo de frame ETHERNET_802.2, ou o encapsulamento Novell SAP de Cisco, são o encapsulamento 802.3 real com 802.2 LLC. Este é o encapsulamento padrão padrão novo de Novell no netware 3.12 e no netware 4.x. O encapsulamento padrão de Cisco para quadros IPX em Ethernet é ainda novell-ether, ou na nomenclatura do ETHERNET_802.3 de Novell.

     router(config-if)# ipx encapsulation?
       arpa   Novell Ethernet_II
       HDLC   HDLC on Serial Links
       novell-ether   Novell Ethernet 802.3
       sap   IEEE 802.2 on Ethernet, Token Ring, and FDDI
       snap   IEEE 802.2 SNAP on Ethernet, Token Ring, and FDDI

Q. Que se eu tenho lotes do tráfego de Novell em minha rede, mas eu precisamos de girar sobre debugar?

A. Desabilite o registo ao console, e registre-o a um servidor de SYSLOG. Use estes comandos na configuração fazer isto:

      no logging console
      logging "ip address of syslog server"

Q. Como eu uso uma máscara para números de rede de IPX em uma lista de acesso?

A. Em 9.1, não há nenhuma máscara para o network number; as máscaras são para endereços de rementente e destinatário. Esta é a sintaxe para a lista de acesso:

access-list number {deny|permit} novell-source network[.source-address [source-mask]] 
novell-destination-network[.destination-address [destination-mask]]

A fim permitir todos os network number que começam com 817axxxx (817a0000 - 817affff), você tem que datilografar dentro todos os network number.

      access-list 801 permit 817a0000
      access-list 801 permit 817a0001
      ...
      access-list 801 permit 817affff

Em 9.21 e mais atrasado, permitir que todos os network number comecem com 817axxxx (817a0000 - 817affff) é muito mais fácil devido às máscaras de rede. As máscaras de rede são permitidas em 900 (listas de acesso extendida) e 1000 SAP filtram listas de acesso. Está aqui a sintaxe para o comando:

access-list access-list-number {deny | permit} protocol [source-network[.source-node[source-network-mask.]source-node-mask] source-socket[destination-network[.destination-node[destination-network-mask. destination-node-mask]destination-socket]] 

Aqui está um exemplo:

   access-list 901 permit -1 817a0000.0000.0000.0000 ffff.ffff.ffff.ffff
 

Q. Você tem que permitir o DECNet antes de Novell nos roteadores Cisco que executam ambos os protocolos?

A. Antes de 8.2, quando o DECNet foi começado em um roteador, todas as relações do roteador foram mudadas de modo que o endereço do nível do Mac caísse dentro da escala DEC. Isto significou que o DECNet teve que ser começado antes de todo o outro protocolo que usasse o MAC address como parte de seu endereço de protocolo (como Novell e o XNS). 8.2 mudaram a implementação de decnet de modo que somente as relações que foram atribuídas um custo do DECNet tivessem seu MAC address mudado. Se você executa o DECNet e o Novell na mesma relação, você precisa de começar primeiramente o DECNet. A fim ser seguro, você deve sempre começar o DECNet primeiramente em um ambiente misto.

Q. É Cisco ciente do BIGPACK.NLM e do PBURST.NLM, e eles é apoiado?

A. Novell disse-nos sobre um módulo carregável do netware que operasse sobre o fileserver e o software do cliente mais novo. Ao mesmo tempo, este NLM estava em duas porções: Modo de intermitência e grande apoio da negociação do pacote. Ambas as peças são empacotadas agora no mesmo PBURST.NLM chamado NLM. O netware 3.12 e o netware 4.x têm PBURST/LIPx construído no NOS.

O PBURST.NLM é projetado compensar um problema com netware 3.11 ou os clientes/server mais adiantados. Quando a estação de trabalho entra ou diplomatas a um fileserver, a estação de trabalho e o server devem negociar um valor máximo do tamanho do pacote. Este é o tamanho de buffer de pacote da estação de trabalho ou o tamanho de buffer de pacote do servidor de arquivo, qualquer é menor. Se há um roteador entre o fileserver e a estação de trabalho, um tamanho padrão de 576 bytes está usado porque o fileserver não pode determinar se todo o Roteadores e segmentos no trajeto podem segurar um grande tamanho do pacote.

O LIPx parte de PBurst intercepta o pedido do tamanho do pacote do negócio e duplica o procedimento acima exatamente, salvo que ignora a verificação do roteador. Depois que LIPx foi carregado no fileserver, todas as estações de trabalho que anexam o uso o tamanho de pacote negociado o maior, apesar do Roteadores que intervem. Desde que não há nenhuma verificação do roteador, há uma possibilidade de uma falha de estabelecimento de sessão se todo o Roteadores que intervem não é configurado corretamente.

A intermitência de pacote de informação IPX/NCP é completamente independente do roteador Cisco. Os testes foram executados com as versões atual de nosso software, e nenhum problema foi observado. O throughput IPX fim-a-fim aumentou o uso do modo de intermitência, que aumenta o número de pacotes que podem ser enviados antes que um ACK esteja exigido.

Q. Os pacotes dos netbios Novell exigem ajudante-lista?

A. O NetBIOS de Novell executa sobre o IPX. As perguntas iniciais de NetBIOS geralmente tomam o formulário dos broadcasts locais e, em 9.1, exigem um helper address (endereço do ajudante) alcançar o servidor de destino. Uma vez que um helper address (endereço do ajudante) foi aplicado a uma relação, NetBIOS está enviado ao endereço definido no ajudante-endereço. Em 9.21 e mais atrasado, as transmissões dos netbios Novell são enviadas com o comando ipx type-20-propagation.

Q. Que são todos os valores do protocolo possível e do soquete para listas de acesso extendida?

A. O roteador Cisco pode filtrar em TODO O valor nos campos do “protocolo” e do “soquete” na lista de acessos. Estão aqui alguns valores bem conhecido para estes campos:

     IPX protocol (or packet) types:
       0  Unknown (could be any of the below, check socket to see what it is)
       1  Routing information protocol (RIP)
       2  Echo packet (ping)
       4  Internet Packet Exchange (IPX)
       5  Sequenced Packet Exchange (SPX)
      17  NetWare Control Protocol (NCP)
      20  NetBIOS Name Packet

     Novell socket numbers:
       0x451  NCP
       0x452  SAP
       0x453  RIP
       0x455  NetBIOS
       0x456  Diagnostics
       0x457  Serialization Packets
       0x4000 - 0x6000  Ephemeral sockets; used for interaction with file
                   servers and other network communications
       0x8000 - above Sockets assigned by Novell to third parties or
           themselves.

Q. Como grande é o RASGO IPX e CAVA atualizações?

A. O tamanho de um pacote RIP IPX gerado por um dispositivo Cisco é até entradas do RASGO do oito byte dos 50 pés mais 32 bytes do IPX aéreo (para um total de 432 bytes), mais a carga adicional de encapsulamento de mídia.

O tamanho de um pacote de SAP de IPX gerado pelo roteador Cisco é até sete entradas 64-byte SAP mais 32 bytes do IPX aéreo (para um total de 480 bytes), mais a carga adicional de encapsulamento de mídia.

Q. Que faz meio dos “usos” na tabela de roteamento de IPX?

A. O contador " usos " associado com cada rota é incrementado cada vez que a rota é escolhida como o trajeto para um pacote IPX. Não significa necessariamente que esse muitos pacotes estiveram enviados com sucesso com essa rota, simplesmente aquele a rota foi escolhido que muitas vezes. É ainda possível depois que o contador " usos " é incrementado para rejeitar o pacote devido ao tamanho do MTU excedido para a interface de saída, a falha da lista de acesso de emissor, uma fila de saída completa, etc.

Q. Que tipo SAP eu tenho que permitir que o RCONSOLE trabalhe?

A. O RCONSOLE manda do “uma pergunta 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.

Q. Como o switching rápido IPX é executado?

A. O switching rápido IPX é baseado na informação no cache rápido de switch. As entradas são criadas com base na informação derivada do primeiro pacote comutado por processamento a um destino fornecido. Quando o destino estiver diretamente em uma rede conectada, ou “os trajetos máximos IPX” estiverem ajustados a 1 (o padrão), pode nunca haver mais de uma entrada rápida de cache de switch a um destino fornecido.

Quando “os trajetos máximos” são ajustados a um valor maior de 1, as rotas de custo igual múltiplas (às redes remotas) podem ser mantidas na tabela de roteamento. Neste caso, as entradas rápidas de cache de switch múltiplas são criadas, também.

Na presença das entradas de cache múltiplo, o algoritmo de IPX fastswitch é simples: nós arredondamento robin entre entradas.

Está aqui o exemplo de saída do esconderijo IPX da mostra:

                Destination   Interface    MAC Header
    *    365.0000.0c02.8cf9   Ethernet0    00000C028CF900000C028CFB8137
    *    164.0000.0c01.d878   TokenRing0   000030802D7D0000304060DFE0E003
                              @TokenRing1  000030802D7E0000304060DFE0E003

Os pacotes sucessivos destinados para 164.0.0c01.d878 são enviados com o TR0, então o TR1, então o TR0, etc.

Em 9.0 e em 8.3, o algoritmo round-robin é o mesmo, mas o destino rápido de cache de switch é mantido pela rede, não pelo host. Assim olha como este:

               Destination   Interface    MAC Header
    *                  365   Ethernet0    00000C028CF900000C028CFB8137
    *                  164   TokenRing0   000030802D7D0000304060DFE0E003
                             @TokenRing1  000030802D7E0000304060DFE0E003

Consequentemente, você vê uma pequena diferença no comportamento de fastswitch quando o compartilhamento de carga é permitido. Os pacotes de entrada sucessivos destinados para uma rede remota dada são relações elegíveis mandadas em uma base round-robin, mas os pacotes para um host dado são distribuídos entre as relações dependentes da mistura de tráfego destinada para a rede remota.

Q. Há uma maneira de controlar que server responde ao pedido GNS?

A. Nós respondemos a pedidos GNS em 9.1 com o server que aparece na parte superior da tabela do serviço. A fim mudar que serviço está na parte superior da tabela em 9.1, você pode um ou outro filtro que presta serviços de manutenção para fora completamente com um Input-sap-filter (então ninguém pode alcançar esse server através deste roteador), ou você pode definir SAP estático para o serviço que você quer aparecer na parte superior da tabela. A fim fazer isto, dê que estático CAVE um contagem de saltos mais baixo do que o server que está na parte superior da tabela para esse tipo de serviço, ou para fazer o server que está na parte superior da pena mais baixa da lista na tabela com SAP estático definido para esse serviço, que faz seu contagem de saltos mais distante ausente.

Em 9.21 e mais atrasado, a melhor maneira de controlar que server responde uma resposta de GNS é usar um saída-gns-filtro.

Q. Faz o comando? do “servidor preferido” de Novell do apoio de Cisco

A. Meio: o comando preferred server no cliente é usado como este:

  1. O cliente carreg e envia uma transmissão do obter pacote de servidor mais próximo.
  2. Se não há nenhum servidor local, o roteador responde a este com o server que é parte superior da lista (em 9.21 e mais atrasado, parte superior da lista não variada).
  3. O cliente envia então um pedido do RASGO para o número interno de rede do server.
  4. O roteador responde com os saltos e os tiquetaques à rede.
  5. O cliente abre uma sessão de NCP com o NearestServer.
  6. O cliente envia em uma consulta de encadernação ao NearestServer para o servidor preferido.
  7. O cliente envia um pedido do RASGO para o servidor preferido.
  8. As disconexões do cliente do NearestServer e conectam a PreferredServer.

    Nota: Os clientes podem somente anexar ao OS do netware dispositivos, e somente os dispositivos de netware podem responder ao pedido da consulta de encadernação. Os roteadores Cisco não são dispositivos de netware, mas nós distribuímos os pacotes de NCP ao server o mais próximo.


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: 10548