Routing IPX / Novell

Introducción y resolución de problemas frecuentes de Novell IP e IPX.

25 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Abril 2015) | Comentarios


Contenido

Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Este documento proporciona algún relacionado con la información diverso al protocolo IPX. Nuestra idea no es documentar completamente el Novell, sino crea bastante una lista mínima de preguntas frecuentes clasificadas por los temas.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Antecedentes

Comprensión de los números de la red IPX

Como con otras direcciones de red, los direccionamientos de red Novell IPX deben ser únicos. Estos direccionamientos se representan en el formato hexadecimal y consisten en dos porciones: un network number y un número de nodo. El número de red IPX, que es asignado por el administrador de la red, es 32 bits de largo. El número de nodo, que es generalmente el Media Access Control (MAC) Address para uno del Network Interface Cards del sistema (NIC), es 48 bits de largo.

  • Red

    • número de bit 32 representado en el hex.

    • Administrativo asignado

    • Rango: 0x00000001 - 0xFFFFFFFE

    • 0xFFFFFFFF = transmitido

    • 0xFFFFFFFE = ruta predeterminado

  • Nodo:

    • número de bit 48 representado en el hex.

    • Dirección MAC del indicador luminoso LED amarillo de la placa muestra gravedad menor NIC (puede administrativo ser asignado)

El uso IPX de una dirección MAC para el número de nodo permite al sistema para enviar los Nodos para predecir qué dirección MAC a utilizar en un link de datos. (En cambio, porque la porción del host de un IP Network Address no tiene ninguna correlación al MAC address, los Nodos IP deben utilizar el Address Resolution Protocol (ARP) para determinar el MAC address del destino.)

El esquema de direccionamiento permitió originalmente que 0xFFFFFFFE fuera utilizado como direccionamiento. Después de la introducción de NLSP, la red -2 se utiliza para representar la ruta predeterminado. Los routeres Cisco tratarán 0xFFFFFFFE como ruta predeterminado, aunque sea ajustable.

Ejemplos de los direccionamientos Network.Node

C15C0.0000.0000.0001

BAD.0000.123d.3423

Información sobre números de redes internas y externas en servidores Novell

Desde la introducción del Netware 3.x, la arquitectura del servidor se ha construido modular y cada proceso (gateway, encaminamiento, archivo, impresión) comunica con el motor multitarea del OS del núcleo. Los motores del OS del núcleo se asignan un IPX Network Address conocido como el número de red interno, y ese ID del nodo es siempre 0000.0000.0001. Por lo tanto, cada servidor del Novell 3.x/4.x tiene un número de red interno con un número de red externa limitado al adaptador de red. El adaptador de red se puede limitar a las direcciones de red múltiples cada uno con un tipo de trama único. Además, los servidores Novell pueden contener los adaptadores y la ruta de Red múltiple entre los segmentos de red separados. Un servidor de Microsoft NT que ejecuta el IPX no aparecerá con el ID del nodo de 0000.0000.0001 y no utiliza el concepto de número de red interna y externa por abandono.

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

Encapsulación en Novell

Hay muchos diversos encapsulados de Novell. Para los Ethernetes solamente, hay tanto como cuatro. El tipo de encapsulación es muy importante como dos dispositivos usando diversos métodos de encapsulación en el mismo media no podrá comunicar. Los clientes Novell pueden generalmente adaptarse a la encapsulación disponible en sus links, pero los servidores IPX deben tener un tipo de encapsulación constante puesto en hard-code.

Los nombres de la encapsulación son diferentes en el Novell o terminología de Cisco. La tabla siguiente proporciona un resumen de los encapsulados IPX disponibles para diversos tipos de media.

Convenciones para la asignación de nombres de la encapsulación IPX

Convención para nombres del Cisco IOS Convención para nombres del Switch del Cisco Catalyst * Convención de denominación de software del Novell LSAP Descripción
Ethernet Novell-ether 8023RAW Ethernet_802.3 (sin procesar) FFFF Ethernetes sin el LLC o la BROCHE
ARPA Ethernet II (EII) Ethernet_II 8137 Tipo 8137 s del Ethernet II
SAP 8023 Ethernet_802.2 E0E0 Ethernetes con el sobre 802.2
SNAP SNAP Ethernet_SNAP AAAA Sobre + BROCHE s 802.2 de los Ethernetes
FDDI SNAP SNAP FDDI_SNAP AAAA FDDI usando 802.2 + BROCHE
SAP SAP FDDI_802.2 E0E0 FDDI usando el sobre 802.2
Token Ring SAP n/a Token Ring E0E0 Token Ring con 802.2
SNAP n/a Ring_SNAP simbólico AAAA Token Ring con 802.2 + BROCHE

  • El tipo de trama ETHERNET_802.3 es encapsulación propietaria del Novell's. Ponen los paquetes SPX/IPX directamente dentro de 802.3 tramas y no utilizan 802.2 LLC ni ROMPEN. Éste es el encapsulado de Novell NOVELL-ETHER en la terminología de Cisco.

  • El ETHERNET_II del tipo de trama es el enmarcar “estándar” del Ethernet II. Los paquetes SPX/IPX se rellenan en las tramas del Ethernet II, usando el código 8137 del tipo. Estas tramas diferencian de las tramas de Novell solamente en el campo del código/de la longitud de trama del tipo two-octet; si no, son idénticas. Éste es el encapsulado de Novell ARPA en la terminología de Cisco.

  • El tipo de trama ETHERNET_802.2 es encapsulación preferida Novell's para el Netware 3.12, los servidores del Netware 4.X: es Ethernet con el sobre 802.2. Éste es encapsulado de Novell SAP para 9.21 en la terminología de Cisco.

  • El ETHERNET_SNAP del tipo de trama es Ethernetes con el sobre 802.2 + la BROCHE. Esto no se utiliza generalmente. Éste es Novell Encapsulation SNAP en la terminología de Cisco.

* Las configuraciones de IPX en los Catalyst Series Switch solicitan solamente las configuraciones de Ethernet a FDDI Bridging.

Protocolos de ruteo IPX

Usando los protocolos enumerados abajo, las rutas y mantienen un Router IPX saben del se pueden definir y manejar dinámicamente:

  • SAP (protocolo service advertisement): Un protocolo IPX que permite que los recursos de red tales como servidores y Routers se sabía a los clientes de red. El SAP se requiere para determinar donde los servicios de red individual residen en la red interna.

  • RIP (Routing Information Protocol): Un Interior Gateway Protocol (IGP) que utiliza el conteo saltos y hace tictac como métricas de ruteo. El conteo saltos mide la distancia entre una fuente y un destino. El tiempo de respuesta de ida y vuelta entre la fuente y el destino se mide en las señales, o 1/18 de los segundos intervalos. RASGUE aprende, selecciona, y mantiene la tabla de ruteo. El RIP es un protocolo del vector distancia usado para intercambiar la información de ruteo dentro de un sistema independiente.

    • Trabajo del RIP y de SAP junto en equipo para ayudar a los clientes, a los servidores, y al Routers a encontrar los servicios de red, y las rutas a cada servicio. También los utilizan para las comunicaciones entre cliente y servidor así como las comunicaciones del router a router.

  • EIGRP IPX: El IGRP es el protocolo interior gateway routing de Cisco usado en el internets TCP/IP y OSI. El IGRP utiliza la tecnología de ruteo del vector de distancia de modo que cada router no necesite conocer todas las relaciones del router/del link para toda la red. Cada router anuncia destinos con una distancia correspondiente. Cada router que escucha la información ajusta la distancia y la propaga a los routers vecinos.

    • Se representa a la información de distancia en IGRP como un compuesto de ancho de banda disponible, demora, uso de carga y confiabilidad de link. Esto permite que los ajustes finos de la característica de link alcancen los trayectos óptimos que el EIGRP es una versión mejorada de IGRP. La tecnología de vector de igual distancia que se usa en IGRP también se emplea en EIGRP. Además, la información de la distancia subyacente no presenta cambios. Las propiedades de convergencia y la eficacia de operación de este protocolo han mejorado significativamente. Esto permite una arquitectura mejorada y, a la vez, retiene la inversión existente en IGRP. Para los detalles en el EIGRP, vea por favor el documento siguiente:

      Introducción al (EIGRP) del IGRP mejorado

      Los módulos que dependen del protocolo son responsables por los requisitos específicos del protocolo de capa de red. Por ejemplo, el módulo IPX-EIGRP es responsable del envío y la recepción de paquetes EIGRP que son encapsulados en IPX. El IPX-EIGRP es responsable de analizar el algoritmo difusor de actualización de los paquetes EIGRP y de la información (DUAL) de la nueva información recibida. El IPX-EIGRP pide DUAL hacer las decisiones de ruteo los resultados cuyo se salvan en el tabla de IPX Routing. El IPX-EIGRP proporciona las características siguientes.

    • Redistribución automática - Las rutas del RIP IPX se redistribuyen automáticamente en el EIGRP y las rutas IPX-EIGRP se redistribuyen automáticamente en el RIP sin los comandos any que son ingresados por el usuario. La redistribución se puede apagar con el uso del ningún redistribuye el subcomando de router del protocolo. Ambos, el IPX-RIP y el IPX-EIGRP pueden desactivarse completamente desde el router.

    • Mayor ancho de red - Con el RIP IPX, el ancho posible más grande de su red es 15 saltos. Cuando se habilita el IPX-EIGRP el ancho posible más grande es 224 saltos. Dado que la métrica de EIGRP es lo suficientemente grande para admitir miles de saltos, la única barrera para expandir la red es el contador de saltos de la capa de transporte. Cisco soluciona este problema con sólo incrementar el campo de control de transporte cuando un paquete IPX ha atravesado 15 routers y el próximo salto al destino fue aprendido vía EIGRP. Cuando una ruta RIP se utiliza como el siguiente salto a destino, el campo de control de transporte se incrementa como es habitual.

    • Actualizaciones de SAP incrementales – Las actualizaciones de SAP completas se envían periódicamente hasta que se encuentra un vecino EIGRP y, de ahí en adelante, sólo cuando hay cambios en la tabla SAP. Esto funciona al aprovechar el mecanismo de transporte confiable de EIGRP; por lo tanto, un par IPX-EIGRP debe estar presente para el envío de los SAP graduales. Si no existe un par en una interfaz particular, entonces se enviarán los SAP periódicos en esa interfaz hasta que se encuentre un par. Estas funciones son automáticas en las interfaces seriales y se pueden configurar en el medio LAN si están deseadas.

  • NLSP (protocolo netware link services): Este Routing Protocol se puede utilizar conjuntamente con, o en vez de SAP y del RIP. Dirige las limitaciones del RIP y del SAP cuando se implementan en grande, las interconexiones complejas. Típicamente, el NLSP utiliza menos ancho de banda, es más rápido en la puesta al día de su tabla de ruteo, y es más scalable al internetworks grande que el RIP y SAP. El NLSP no es un protocolo de uso general del IPX Routing.

Estudios de casos de la red Novell IPX

Caso Práctico nº 1: Cisco a interfuncionamiento 3Com en Interfaces de WAN

Por abandono, configuran a los routeres Cisco para las actualizaciones de SAP periódico que ocurren cada 60 segundos en todas las interfaces. Sin embargo, en los 3Com Router de la empresa, la interfaz de WAN se configura para las actualizaciones no periódicas de SAP por abandono. Las actualizaciones no periódicas son las actualizaciones de SAP que ocurren solamente cuando sube un link, cuando el link se traga administrativo, o cuando la información de servicios cambia en vez de un intervalo periódico. Este parámetro se soporta para las actualizaciones de SAP solamente. Al conectar a un router Cisco con un 3Com Router que ejecuta el IPX sobre una interfaz de WAN con una configuración de IPX predeterminada, las entradas del servidor IPX en el router Cisco aparecerán solamente por 240 segundos después de que conexión o cambio de la topología debido a la configuración predeterminada del 3Com Router que es fijado para las actualizaciones no periódicas de SAP. Para corregir este problema, un cambio de configuración se requiere en Cisco o el 3Com Router.

Para cambiar al 3Com Router a las actualizaciones de SAP periódico en una interfaz de WAN, publique los pasos siguientes:

  1. Verifique la configuración de IPX en la interfaz de WAN en el 3Com Router publicando el comando: ¡muestre [! <port]|¡! *] - control de la savia

    Ejemplo: SH - SAP CONT

  2. Si configuran al 3Com Router para “aperiódico” en la interfaz de WAN, la configuración necesitará ser cambiada a “periódico” usando el comando: ¡setdefault! <port> - savia control=periodic

    Para cambiar al router Cisco a las actualizaciones no periódicas IPX SAP en una interfaz, publique el comando interface siguiente:

    cambios-solamente de la savia del intervalo de la actualización IPX

Caso Práctico nº 2: Cola de difusión de retransmisión de tramas y pérdida de conectividad IPX en redes de retransmisión de tramas

Un router Cisco que se configura para el IPX y se coloca mientras que el concentrador de una nube de Frame Relay puede necesitar tener cambios de configuración asociados a la cola de broadcast de Frame Relay. Éste es un resultado de la cola de broadcast de Frame Relay que omite los tamaños solamente de una sola interfaz mientras que de hecho la interfaz puede servir los sitios múltiples. Los tamaños de cola predeterminados del broadcast de Frame Relay son 64 y necesitan ser configurados como 64 veces el número de interfaces secundarias. Los tamaños de la cola que son demasiado pequeños configurado pueden dar lugar a las actualizaciones de la pérdida de IPX RIP/SAP a través de WAN. Las actualizaciones de la pérdida de IPX RIP/SAP causarán la pérdida de conectividad entre el concentrador y los sitios remotos.

Ejemplo: Demasiado pequeño configurada cola de broadcast de 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)

Pautas de configuración para configurar la cola de broadcast de Frame Relay

Cola de transmisión de Frame Relay

  • Para crear una cola especial para que una interfaz especificada lleve a cabo el tráfico de broadcast que se ha replicado para la transmisión en los identificadores de conexión de link de datos múltiples (DLCI), utilice el comando frame relay broadcast queue interface configuration:

  • velocidad de paquetes de la velocidad de byte de los tamaños de la cola de broadcast del Frame Relay

Descripción de la Sintaxis

  • tamaños - Número de paquetes a sostenerse en la cola de broadcast. La recomendación para la red IPX RIP/SAP es tener 64 paquetes mide el tiempo del número de sitios remotos. Por ejemplo, si hay 7 sitios remotos, configure la profundidad de espera en cola como 448.

  • velocidad de byte - Cantidad máxima de bytes que se enviará por segundo. La recomendación es uso la configuración predeterminada de 256000 bytes por segundo

  • velocidad de paquetes - Cantidad máxima de paquete que se enviará por segundo. La recomendación es uso el valor por defecto de 36 paquetes por segundo.

Caso Práctico nº 3: Incoherencia de IPX SAP cuando se utiliza IPX EIGRP como protocolo de ruteo IPX

De vez en cuando, puede haber una pérdida de conectividad súbita a un servidor Novell específico o al servicio IPX. Los servidores Novell o los servicios IPX pueden desaparecer aleatoriamente de las tablas IPX SAP. Esto puede también hacer los tamaños de la tabla de SAP variar por algunas savias a través de la red.

Si usted está experimentando estos problemas, vea estos bug de software y actualicelos a una versión de software que no experimente estos problemas.

Revise estos Release Note:

CSCdp13795 - Incongruencia IPX SAP con el EIGRP IPX

Si usted está utilizando el Enhanced Interior Gateway Routing Protocol (EIGRP) IPX, usted puede ser que experimente una inconsistencia en las actualizaciones del protocolo service advertising (SAP) en un router remoto, si la interfaz serial se derriba por un tiempo breve y después se saca a colación otra vez. Para verificar el problema, ingresar el EXEC del comando clear ip eigrp neighbors, o ingresar el comando no ipx linkup-request sap para las interfaces seriales y verificarlo que no ocurre de nuevo el problema.

CSCdk13645 - La tabla IPX SAP puede llegar a ser contraria después de que los servidores múltiples se quiten de la tabla

Al usar las actualizaciones graduales de SAP del EIGRP IPX (RSUP), las tablas del servidor entre dos o más vecinos EIGRP puede llegar a ser contrario. Específicamente, el problema puede ocurrir cuando salen únicamente tres docenas de servidores al mismo tiempo, mientras que las rutas a esos servicios siguen siendo en la tabla de ruteo si hay vecinos o trayectorias del EIGRP múltiple a un vecino. Abajo la actualización de Flash para algunos de los servidores recientemente tragados no se está enviando a todas las interfaces, así que algunos dispositivos tienen los servidores quitados y otros no hacen. La solución alternativa está borrar a los vecinos IPX EIGRP en la unidad que muestra estos servidores que siguen habiendo en la tabla.

Una actualización de Flash es un anuncio inmediato de cualquier cambio en la red, y el aspecto de los nuevos servicios o la desaparición de los servicios existentes. Mientras que el sample lab debug output siguiente muestra, la actualización de Flash se envía a todas las interfaces que estén ejecutando el 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 - Savias que falta después de la conexión/abajo

En configuraciones de red con la interfaz IPX que interconecta un router local y un router remoto configurados con el EIGRP IPX SAP-ampliado (el modo predeterminado en el NON-LAN interconecta cuando se utiliza el EIGRP IPX), el router remoto puede perder algunas savias si la interfaz del router local (la interfaz del donde oyen pero no están conectados a los servicios IPX con el router remoto) experimenta una transición rápida down/up. El trabajo alrededor es restablecer la adyacencia IPX-EIGRP publicando el comando clear ipx eigrp neighbors en el router remoto.

La causa raíz de CSCdm23488 es un problema de sincronización con los procesos del software que son llamados por el siguiente enlace IPX abajo y conectan encima de las secuencias. Cuando un gran número de servicios IPX están implicados, la interfaz sube mientras que se están enviando las savias del veneno. Como consecuencia, las savias del veneno reemplazan los nuevos anuncios y evitan con eficacia que hagan publicidad algunos servicios.

CSCdx73624 - Savias perdidas IPX

En una topología de Frame Relay del hub and spoke, dos spokes pueden no recibir las savias de cada uno si la nube de WAN está ejecutando el RIP IPX y el EIGRP IPX. El resultado es una tabla contraria de SAP. Como solución alternativa, RIP de la neutralización IPX.

Pasos para la resolución de problemas

Si usted observa un problema con las savias perdidas, utilice los pasos de Troubleshooting siguientes:

  • ¿Si las savias son doctas vía otro spoke del Frame Relay, el router de eje de conexión también está faltando las savias o solamente al router radial local?

  • ¿Es usted el usar ampliado o las actualizaciones de SAP periódico?

  • Si usted ha habilitado las actualizaciones periódicas, determine si el router está recibiendo las actualizaciones restauradas SAP. Vea los contadores de SAP publicando el 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
  • ¿Es usted perdidoso todas las savias de un servidor determinado?

  • ¿Hay una relación entre una falla de link y las savias de los desaparecidos? Si las savias se pierden después de un cambio de link, utilice los pasos siguientes:

    1. Inhabilite el registro de la consola y habilite el registro del buffer publicando el comando logging buffered.

    2. Publique los comandos debug ipx eigrg events y debug ipx eigrp neighbor {neighbor ID}.

    3. Transición el estado del link de la interfaz.

    4. Si usted detecta las savias que falta, espere por lo menos cinco minutos para verificar que las savias faltan de hecho. Capture la salida del servidor IPX de la demostración y muestre los routecommands IPX en ambo el Routers del hub and spoke.

    5. Publique el comando clear ipx route en el extremo del spoke.

    6. Publique los comandos show ipx server y show ipx route de verificar si se han aprendido todas las savias.

Si usted no puede resolver el problema con los pasos antedichos, usted puede necesitar publicar el comando debug ipx sap activity. Los mensajes del debug del ejemplo se proporcionan abajo.

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: Asegúrese que usted entienda el impacto de este comando debug antes de habilitarlo, puesto que puede generar una gran cantidad de salida. Para minimizar el impacto de los debugs al router, recomendamos el inhabilitar del registro de la consola y el habilitar del registro del buffer con los tamaños de búfer suficiente.

Caso Práctico nº 4: El comando show IPX traffic indica varios errores de formato

por ejemplo: El comando se configura como lt-4500-3a-show ipx traffic. El resultado es el siguiente:

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

Los errores de formato en un comando show ipx traffic son el número de malos paquetes desechados (por ejemplo, los paquetes con un encabezado corrompido). Este contador incluye los paquetes IPX recibidos para una encapsulación que no configuran al router.

La mayoría de los PC en una red auto-detectan el tipo de trama de IPX en un Token Ring o la red Ethernet enviando las peticiones GNS de los cuatro tipos de trama posibles. La interfaz en el router se cifra difícilmente a un tipo de trama específico. Si la interfaz en el router recibe un paquete IPX con un diverso tipo de trama que se configura qué, se cae el paquete y se incrementa el “campo del formato”. Por lo tanto, los PC configurados para el tipo de trama predeterminado registrarán siempre por lo menos tres errores de formato en el router Cisco colindante sobre el lanzamiento.

Refiera a los comandos ipx del Novell para más información sobre el comando show ipx traffic.

Caso Práctico nº 5: Los IPX SAP no aparecen en la tabla de servidor IPX en las nubes de WAN

Los routeres Cisco a través de una nube de WAN mostrarán todas las rutas de IPX en el tabla de IPX Routing. Sin embargo, ningunas de las savias IPX están apareciendo en la tabla de servidor IPX. La codificación de la línea AMI no soporta los paquetes con una densidad de los ceros del alto. La codificación de línea debe ser la codificación B8ZS que, al detectar una densidad de los ceros del alto, invertir la secuencia de datos para romper para arriba los ceros. Los Paquetes IPX SAP pueden incluir un patrón de datos de 11 ceros consecutivos. Por ejemplo, un servidor de archivos del tipo 4 tiene un direccionamiento IPX del ABCDEF.0000.0000.0001, que será corrompido si la nube de WAN no soporta la densidad de alto cero. Si el paquete alcanza un router remoto corrompido, será caído. Como consecuencia, las actualizaciones del RIP IPX alcanzarán los routeres remotos, pero los Paquetes IPX SAP no, debido a la densidad de alto cero.

La solución es tener el proveedor de servicio PÁLIDO correctamente fijar la codificación de línea a B8zs a través de WAN.

Para verificar su configuración, inicie un ping IP con un modelo de todos los ceros a través de la nube de WAN en 500, 1000 y 1500 bytes. Si el ping IP es acertado, la codificación de línea no es un problema puesto que la alta densidad cero ping del modelo es acertada.

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#

Caso Práctico nº 6: Las estaciones de trabajo no se pueden conectar a uno de los servidores por medio de la vecindad de la red

En algunos casos, los puestos de trabajo pueden ver todos los servidores Novell en una vecindad de la red, pero incapaz de conectar con los servidores uces de los con la vecindad de la red. Para asociar a los servidores en la vecindad de la red a través de los VLA N o a través de las Redes múltiples, las estaciones de trabajo del cliente deben tener el cliente Novell 32 instalado o habilitar la propagación tipo 20 IPX en el Routers correspondiente. Además, cada network number en el campus debe ser único a través del toda la red. Utilice la herramienta del PING IPX en los servidores Novell y la herramienta del PING IPX en los routeres Cisco para verificar la Conectividad a través de WAN.

Caso Práctico nº 7: No es posible obtener acceso a recursos de Citrix Winframe con IPX en routers Cisco

Si la salida de comando de los servidores IPX de la demostración muestra que hay más de un servidor Winframe con la misma cuenta del salto/de la señal lejos, después, por abandono solamente SAP de la primera entrada será enviado al cliente.

Esto no es un problema para un servidor Novell, puesto que el cliente validará primer SAP, va al primer servidor, y después consigue reorientado al servidor de la opción del cliente si hay servidor preferido. Winframe no tiene esas funciones. Si configuran para Nombre del servidor “x”, pero consigue al cliente SAP para Nombre del servidor “y,” puesto que “y” es primera en la tabla de SAP, después el cliente nunca conectará.

La solución es agregar el comando ipx gns-round-robin como comando global en el router con el winframe múltiple SAP de la misma distancia. El router ordenamiento cíclico con las respuestas de SAP y el cliente conseguirá SAP para el servidor correcto, incluso si no es primer SAP en la tabla de SAP del router.

Caso Práctico nº 8: Inicio de sesión en IPX Novell lento

La mayoría de la causa común para Novell lenta el login es un problema conocido como recorrer del árbol. Cuando un agente del cliente somete una petición al NDS, la petición no es recibida siempre por un Servidor de nombres que se califique satisfacer la petición. El Servidor de nombres que recibe la petición debe encontrar a un Servidor de nombres que pueda satisfacer la petición. Varios Servidores de nombres pueden necesitar ser entrado en contacto antes de que se localice un servidor calificado. Para encontrar la información, un Servidor de nombres inicia una búsqueda hasta que se encuentre una reproducción que contiene la información deseada. Se llama este proceso el recorrer del árbol. Mientras la información de la réplica se pueda acceder rápidamente, el recorrer del árbol no es un problema. Sin embargo, si la información de la réplica está solamente disponible a través de un link lento, tal como un link PÁLIDO, los retardos puede ocurrir. Cualquier aplicación que utilice el NDS puede causar el árbol que recorre, pero recorrer del árbol se puede minimizar con el buen diseño del árbol de NDS.

Problemas de inicio de sesión y resoluciones lentos comunes por el sitio web del 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

Resolución general de problemas

Para identificar qué potencialmente está causando el problema de inicio de sesión lento, obtenga una traza del paquete del problema que ocurre, capturando todos los paquetes enviados a y desde el puesto de trabajo. Dos trazas del paquete serán necesarias determinar el problema exactamente: una traza del paquete del puerto de servidor y otra traza del paquete del puesto de trabajo. Obteniendo dos trazas del paquete, será muy fácil determinar si el problema se relaciona con las redes que está eliminando paquetes.

Caso práctico #9: Resolución de problemas de entradas de la tabla IPX SAP corruptas

Las entradas IPX SAP que visualizan los caracteres no válidos, las redes fantasmas, o los caracteres bit-desplazados/bit-intercambiados son muy probablemente entradas corrompidas de SAP. ¡Los caracteres no válidos de la muestra incluyen (@! ~^)). Puesto que no hay suma de comprobación de la capa 3 (L3) en la trama IPX SAP, la corrupción de datos puede ocurrir con las actualizaciones IPX SAP. Esta corrupción no se puede causar por la corrupción de la capa 2 (L2) porque el CRC en la trama L2 sería inválido y el router caería la trama. Las savias corrompidas IPX son causadas siempre por el hardware defectuoso. Encontrar la fuente de SAP corruptos IPX es bastante simple al usar la exclusiva del RIP IPX; Utilice simplemente el conteo saltos para encontrar la fuente. Con el EIGRP IPX, el troubleshooting es más difícil, sin embargo.

Con los trayectos redundantes y una topología colocada usando el EIGRP IPX, una entrada del SAP corrupto puede permanecer para siempre, no midiendo el tiempo hacia fuera incluso cuando se ha apagado el dispositivo original. La razón que las savias no desaparecerán de un EIGRP mezclado y entorno del RIP es debido al hecho de que cuando usted tiene trayectos paralelos a través de una red, el RIP y el EIGRP pasarán las entradas de SAP hacia adelante y hacia atrás. Este comportamiento evitará que las savias midan el tiempo nunca hacia fuera. Cuando el EIGRP recibe las actualizaciones a partir Routers dos o más diversos de las actualizaciones de SAP, el EIGRP pasará las actualizaciones nuevamente dentro del RIP del EIGRP si sale la entrada del RIP. El EIGRP también preservará el conteo saltos del RIP, que hace localizando la fuente más difícil.

La condición de colocación descrita arriba efectúa solamente SAP, no las rutas. Esto es porque SAP señalará a la ruta más corta y no nota siempre los loopes de la encaminamiento. SAP no es un Routing Protocol. La eliminación del EIGRP en la trayectoria entera permitirá que los SAP corruptos envejezcan hacia fuera.

Debido el comportamiento del EIGRP IPX y de las entradas de tabla del IPX SAP corrupto del troubleshooting, utiliza los procedimientos deTroubleshooting siguientes en el aislamiento de los SAP corruptos IPX al usar el EIGRP IPX:

  1. Durante una ventana de la interrupción de la red, EIGRP de la neutralización IPX y RIP del uso para localizar exactamente la fuente de entradas del SAP corrupto. Puesto que el RIP utiliza el conteo saltos en el trayecto de red, determinar la fuente o el origen debe ser bastante simple. La localización de averías de este modo asume que las famas corruptas se deben generar durante la ventana de inactividad. Puesto que la corrupción SAP IPX es debido al hardware, el problema puede ocurrir con frecuencia y no ocurrir solamente al azar los períodos de tiempo. Sin los SAP corruptos que son generados actualmente en la red, no habrá manera de determinar la fuente. Todos los SAP corruptos pegados en la tabla del EIGRP saldrán una vez que se quita el EIGRP.

  2. Encuentre una fuente común o un origen de los SAP corruptos. Si allí un origen común a las savias, él puede ser simple aislar el problema y no tuvo que realizarse como Troubleshooting intrusivo como en el paso 1.

    Todos los SAP corruptos están siendo causados por el hardware defectuoso en alguna parte en la red. Esto incluye cualquier router, el Switches L3, los servidores que ejecutan IPX (no apenas servidores Novell), y los puestos de trabajo que ejecutan el IPX. Hasta la fecha, Cisco nunca ha hecho que un problema del software IOS contribuya a los IPX SAP corruptos.

  3. Trabajo-alrededor de los IPX SAP corruptos que afectan a la conectividad de red, la configuración IPX filtra incluir los filtros GNS, el GGS filtra, y los filtros de SAP para pasar solamente los servidores válidos en la red. Además, agregar el comando ipx sap follow-route-path minimizará el número de SAP corruptos. Esto es porque cuando utilizan al comando ipx sap follow-route-path, el router defiende los servicios individuales (savias) en las actualizaciones de SAP. El router mira el número de red de destino de cada entrada de SAP. Si la interfaz de recepción es una de las mejores interfaces para alcanzar la red de destino de SAP, se valida esa entrada de SAP. Si no, se desecha la entrada de SAP. Si un router está recibiendo los SAP corruptos, es probable la ruta puede ser corrupto también.

Caso práctico #10: Es posible que el listado de servidores a partir del comando show ipx servers unsorted muestre servidores fuera de servicio.

En ciertos casos, cuando se configura el ordenamiento cíclico IPX GNS, el router puede experimentar un problema que pueda hacer un servicio del valor bajo de la medición ser movido en la tabla más allá del grupo métrico más bajo de servicios. Esto causará SAP presenta para aparecer fuera de servicio. Éste es comportamiento sabido, y cualquier efecto secundario de este comportamiento se puede solucionar usando los filtros de salida GNS para permitir solamente que los servidores específicos contesten al GNS.

Si usted está experimentando estos problemas, vea el bug de software siguiente y actualicelo a una versión de software que no experimente estos problemas.

CSCds54733 - ouput de los servidores desordenados IPX de la demostración no está en la orden

La salida del comando show ipx server unsorted visualiza una tabla de SAP que no esté en la orden. Mientras que la tabla está en este estado, las contestaciones GNS SAP pueden no proporcionar el servicio más cercano como deben. La tabla misordered resulta de habilitar el ordenamiento cíclico GNS. Como solución alternativa, ordenamiento cíclico de la neutralización GNS publicando el comando no ipx gns-round-robin.

Estudios de casos Novell 5.X IP

Caso Práctico nº 1: Configuración básica del router Cisco necesaria para que los clientes inicien sesión en la red IP de Novell a través de los límites de la red

Por abandono, los clientes IP del Novell descubren los Servicios IP vía el Multicast. A menos que se configure otro método, los clientes IP intentarán descubrir el servidor por el protocolo service location (SLP) que utiliza IGMP (multidistribución). Por abandono, los routeres IOS no remitirán los paquetes de multidifusión.

La solución del router básica es habilitar el comando ip multicast-routing global y habilitar el comando ip pim dense-mode bajo cada VLAN respectivo o interfaz física.

Configuración de ejemplo:

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#

Hay dos otros métodos por los cuales las estaciones de trabajo del cliente pueden acceder el Novell 5.0 recursos a través de los límites de red sin la necesidad de habilitar la mutlicast-encaminamiento.

Configuración de Novell #1 (documento del Novell: 2944038)

Agregue Nombre del servidor y las entradas de IP Address en el NWHost en el puesto de trabajo. El NWHost está situado en el puesto de trabajo en el directorio Novell\Client32 en los puestos de trabajo de Win95 y de Win98. Tiene muestras que sean fáciles de seguir.

En una estación de trabajo NT, en vez de NWHost, el cliente utiliza el archivo de host estándar de Microsoft TCP/IP. Edite el archivo de host para agregar Nombre del servidor y el direccionamiento. La trayectoria a este archivo es Winnt/System32/Drivers/Etc/Hosts.

Configuración de Novell #2 (del documento 2944038 del Novell)

Carga SLPDA.NLM en el servidor del Netware 5. Esto define el servidor como agente de directorio. Agregue la dirección IP del servidor que ejecuta el SLPDA.NLM bajo propiedades del cliente, lengueta de la ubicación del servicio, lista del agente de directorio. Haga clic en el rectángulo al lado del rectángulo del agente de directorio etiquetado los “parásitos atmosféricos.” Con un agente de directorio estático definido, el cliente no Multicast para un agente de directorio, sino enviará un unicast al agente del directorio especificado.

Para una descripción de SLP (protocolo service location) y una discusión de los agentes de directorio, vea el tid 2943614 en support.novell.com

Caso Práctico nº 2: La habilitación de IP Multicast dentro de la red de producción desactiva las redes IPX existentes

Las redes pueden experiennce una pérdida de conectividad IPX súbita y completa para PC del cliente.

Esto puede suceder porque el software de cliente 3.x del Novell Netware preferirá el IP para el protocolo de capa de red sobre el IPX por abandono. Por lo tanto, si un servidor IP solamente del Novell 5.X no configurado correctamente para el login y la multidifusión IP del Novell Netware dentro de la red se habilita, todas las máquinas del cliente preferirán la conexión al servidor del Novell 5.X. Si el servidor del Novell 5.X no es correctamente consciente de los recursos de red existente, los clientes no podrán acceder a los recursos existentes.

Para resolver este problema, configure el IP Multicast Routing para excluir el SLP o para configurar los servidores del Novell Netware 5.X correctamente.

Caso Práctico nº 3: Por qué Novell IP no trabaja a través de un router Cisco que ejecute NAT

Las implementaciones NAT traducen los IP Addresses en los encabezados de paquete y las circunstancias especiales buscan la porción de datos del paquete y traducen las referencias de IP Address incluidos. Sin embargo, software NAT de Cisco actual no traduce las referencias integradas IP del Novell para el NDS o el SLP en las porciones de datos del paquete del IP. Como consecuencia, los dispositivos en la red pública intentarán entrar en contacto los recursos vía las direcciones privadas NON-traducidas. Puesto que las redes públicas no podrán a las redes privadas, las conexiones fallarán. La solución alternativa para crear las conexiones IP del Novell con el NAT es utilizar una solución de VPN.

Para más información, vea el TID 2948010 en support.novell.com

Caso Práctico nº 4: Conexión IP lenta de Novell

Novell lenta el Troubleshooting de inicio de sesión IP es lo mismo que los ingresos al sistema IPX lentos. Vea el caso práctico #8 conforme a los casos prácticos del Novell IPX.

Preguntas comunes de configuración

¿Por qué no puedo configurar más de 200 redes IPX en el router?

Un router Cisco puede manejar más de 200 redes IPX en su tabla de ruteo, por ejemplo, solamente usted no puede configurar más de 200 interfaces IPX en un router (usando el comando ipx network). El límite se ha alcanzado solamente recientemente ahora que tenemos switches de la capa 3 que puedan proporcionar este número de interfaces. Este número está puesto en hard-code en el IOS y no será cambiado probablemente. Los switches de la capa 3 pueden implementar más de 200 interfaces porque la mayoría de las funciones de Switching son manejadas por algún ASIC especializado que descargue el procesador principal por lo que el tráfico IP. Las interfaces IPX necesitan mucho más las energías en la CPU manejar el proceso RIP/SAP, e incluso el conseguir cerca del límite actual puede ser crítico.

¿Por qué no puedo hacer ping a un host Novell desde mi router?

Un router Cisco implementa dos tipos de ping IPX:

  • Cisco IPX ping: éste es el protocolo de propietario predeterminado de Cisco que un router utilizará cuando usted intenta hacer ping un direccionamiento IPX.

  • Ping de Novell IPX: éste es el único que los servidores Novell pueden ejecutar, y no es compatible con la implementación de Cisco.

Usted puede utilizar el Cisco IPX ping para probar la Conectividad entre los dispositivos de Cisco configurados para el IPX. Si usted quiere hacer ping un servidor Novell, usted tiene que configurar al router para enviar el ping de Novell IPX, usando el ipx ping-default novell del comando global configuration

Usted puede también publicar un comando extended ipx ping y seleccionar la opción de eco estándar Novell.

El servidor Novell debe tener respondedor cargado para contestar a una generación de eco del Novell (ping). Para hacer ping de un servidor Novell, uno debe también cargar el IPXPING.NLM en el servidor. Hemos observado, en la prueba casual, eso:

  • Los servidores del Netware 3.x, los servidores del Netware 4.0x, los clientes NETX, los VLM Client (v.1.20a), y el cliente MS para el Netware no responden a los ping de Novell.

  • El Netware 4.10 servidores, v3.x del Netware MPR, el cliente 32, y el cliente DOS/Win95 MS responde a los ping de Novell.

Por supuesto, el ping puede también fallar por otros motivos que una discordancía en el Tipo de protocolo del ping. El éxito del ping es también dependiente en el tabla de IPX Routing (debe haber una ruta a la dirección destino), la integridad del link (pérdidas del paquete), filtrando, y así sucesivamente. Guías de consulta a recordar al usar el ping:

  • Cuando hacer ping un servidor es posible, asegúrese de que se hayan abordado todos los problemas de la conectividad IPX.

  • Cuando el ping está fallando, en la tapa de todos los problemas de la conectividad posible (de un problema complejo del IPX Routing a un problema de las funciones del link), recuerde que puede haber un problema sencillo con el servidor que no implementa la funcionalidad ping de IPX. Significa que, desafortunadamente, no hay a menudo nada mucho concluir cuando un ping IPX a un servidor está fallando.

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

En este ejemplo, tenemos dos Routers conectado directamente vía su interfaz de Ethernet en el BIZCOCHO BORRACHO de la red IPX. Del router1, si hacemos ping la interfaz router2, el router primero utiliza por abandono, protocolo de propietario 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

Podemos forzar el protocolo del ping de Novell usando el 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

La otra posibilidad es fijar el protocolo predeterminado del ping para ser el Novell's uno:

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#

El cambio del tipo del ping al Novell's es solamente importante cuando usted intenta hacer ping un protocolo corriente del Novell del host. El no poder hacer ping un host del Novell no significa necesariamente que la Conectividad a este host está quebrada (no todos los hosts del Novell responden al ping de Novell). Hacer ping a un router es una buena manera de conectividad IPX de la prueba a él.

¿Por qué no puedo configurar el ruteo IPX?

Usted debe tener el software IOS correcto para configurar el IPX Routing.

Muy a menudo, entregan un router con un software predeterminado en el Flash y este software predeterminado puede no soportar el IPX (incluso si usted pagó una licencia el soporte IPX). Usted entonces tiene que actualizar a su router al software que le autorizan para. El soporte IPX es generalmente parte del conjunto de características de escritorio, que se identifica a menudo con una “d” en el nombre de la imagen:

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

Vea este conjunto de características de escritorio como conjunto de características mínimo incluyendo el soporte IPX. Conjunto de características de la “empresa” (identificado con “j” en lugar el “d” arriba), que incluye el conjunto de características de escritorio, por supuesto, también soportará el IPX. Marque los Release Note de IOS para las características exactas disponibles en el IOS que usted está ejecutando.

¿Qué es el comando ipx pad-process-switched-packets?

Este comando se utiliza para controlar si los paquetes de longitud impares están completados, así que ser enviado como paquetes de longitud uniformes en una interfaz. El comando ipx pad-process-switched-packets afecta a los paquetes process-switched solamente, así que usted debe inhabilitar la transferencia rápida antes de que el comando ipx pad-process-switched-packets tenga cualquier efecto. El comando era necesario debido a algunos hosts IPX que rechazaron los paquetes Ethernet que no se completan. Ciertas topologías pueden dar lugar a tales paquetes que son remitidos sobre una red de las Ethernet remotas. Bajo condiciones específicas, el completar en el medio intermedio se puede utilizar como solución provisoria para este problema.

Este comando está activado como opción predeterminada. Sin embargo, el driver Ethernet del Novell que la especificación dice los paquetes IPX debe “evenized” por el dispositivo remitente. Esto es debido a los dispositivos antiguos que tenían problemas con los paquetes de longitud impares y no deben ser un problema actualmente, pero el requisito persiste.

Un dispositivo no siguiente el requerimiento de legado Novell pudo producir los paquetes de longitud impares. Los Paquetes impares pudieron también resultar al rutear a partir de un encapsulado IPX a otro diverso encapsulado IPX. Algunas encapsulaciones tienen diversa longitud y un cambio en la encapsulación puede producir un paquete de longitud impar.

¿Los routers de Cisco admiten la característica IPX Packet Extension (Extensión de paquete IPX) para desviar la congestión de la red enviando grandes paquetes de actualización RIP/SAP?

Esto es una característica admitida. Por abandono, un paquete RIP IPX contiene 25 rutas y un Paquete IPX SAP contiene 7 savias. El número de rutas y de savias por el paquete del RIP y de SAP puede ser cambiado cambiando los tamaños de paquete de actualización respectivos. Vea la documentación en el sap-max-packetsize IPX e IPX RIP-MAX-packetsize en la referencia del comando ios para más detalles.

A pesar de configurar todos los servidores Novell y Routers para el IP solamente, todavía estoy viendo los capítulos IPX en las trazas de sniffer. ¿Por qué ocurre esto?

El software cliente Novell 3.x por abandono enviará las tramas para el IP y el IPX sobre el bootup en un intento por iniciar sesión a la red Novell sin importar la configuración de red. La solución es inhabilitar manualmente todos los protocolos IPX en el cliente PC.

¿Por qué al activar IPX EIGRP en una interfaz de VLAN, se desactiva IPX MLS en la interfaz correspondiente?

El MLS IPX se inhabilita con el EIGRP IPX puesto que el envío entre el RIP y los dominios EIGRP requiere las traducciones de los campos específicos en la porción de datos (Transmit Control) de paquetes de Routes. Una interfaz del Router IPX cuando está habilitada para el RIP/NLSP, tendrá la cuenta del salto máximo de 16. Cuando un router está en el límite de un dominio de ruteo NLSP/RIP y del EIGRP, la interfaz se configura con el EIGRP y el NLSP/RIP. Es necesario quitar el soporte MLS para esa interfaz si el salto máximo se configura para ser 16 o menos porque en este caso, el valor del transmit control (TC) será traducido en vez de ser incrementado por 1 cuando un paquete atraviesa a partir de un dominio de ruteo a otro. El MLS-SE no tiene conocimiento sobre el Routing Protocol que es utilizado y el hardware MLS no podrá reescribir el campo del transmit control (TC) correctamente.

Los “mls IPX serán inhabilitados en el <vlan_id> de Vlan debido mensaje al uso del eigrp” aparecen solamente si los saltos máximos IPX se fijan a 16 cuando se configura el EIGRP IPX. Para el resto de los valores (17-254) no se visualiza ningún tal mensaje de advertencia. El IPX MLS trabaja muy bien para el valor del salto de 16 aunque hay una advertencia.

El comando de aumentar el valor del transmit control (TC) sobre 16 es value> de los <max_hops de los SALTOS MÁXIMOS IPX

No hay desventaja/ventaja específicas en el aumento del conteo saltos.

Problemas comunes de conectividad

Comprensión del proceso de registro del cliente IPX

¿Cómo un cliente conecta con una red Novell?

Si un cliente necesita localizar un servidor en un árbol más cercano específico del Servidor del directorio (NDS), el cliente transmitirá un tipo SAP 3 para la petición del Get Nearest Directory Service del tipo de servicio 0278 (GNDS). Cualquier servidor NDS (configurado para responder a las peticiones GNS y GNDS) situado en el mismo segmento ruteado que el cliente responderá con el nombre del árbol de NDS que pertenece a y de su número IPX interno. El cliente marcará el nombre del árbol en la contestación contra el nombre del árbol que necesita (según lo que ha fijado el cliente como su árbol preferido). Si es el árbol correcto el cliente transmitirá un pedido del RIP una ruta al número IPX interno proporcionó en la contestación. El servidor responderá el decir ese él es la ruta a ese número IPX interno. El cliente unicast una petición de establecer una conexión a ese servidor y de comenzar el proceso de autenticación. Si el servidor en el segmento local no es servidor NDS que no responderá a la petición inicial GNDS porque puede proporcionar solamente el tipo de servicio 0004, no 0278. Ninguna servidores NDS que no llevan a cabo las reproducciones NDS no responderán a la petición. Si ningunas de las contestaciones contienen el nombre correcto del árbol de NDS, el cliente publicará un tipo 1 de SAP para la petición del tipo de servicio 0278 (GGDS). Todos los servidores NDS situados en el mismo segmento ruteado responderán con una lista de servicios, sin importar el servidor establezca MÁS CERCANO de la CONTESTACIÓN GET. El cliente leerá todas las contestaciones al GGDS que busca el nombre correcto del árbol de NDS. Una vez que encuentra una entrada para el árbol correcto, intentará establecer una conexión a ese servidor. El cliente intentará establecer una conexión a la primera entrada que contiene el nombre del árbol correcto, no el más cercano desde esto una consulta de servicio general, la interrogación no más cercana del servicio. Si el cliente está pidiendo un servidor Bindery (o el cliente hace solamente un servidor preferido fijar en su configuración del cliente) que ocurrirá el mismo proceso, sólo el tipo de servicio de la petición será 0004 en vez de 0278. Además, si el servidor tiene servidor establezca MÁS CERCANO de la CONTESTACIÓN GET a de entonces el servidor no responderá a las peticiones GNS (tipo de servicio 0004) o GNDS (tipo de servicio 0278)

Organigrama para el login del cliente Novell

NDS (Novell 4.11)

  1. Sobre el bootup, el cliente enviará una petición GNDS. Si configuran al cliente al auto detecte el tipo de trama, el cliente enviará cuatro GNDS, uno para cada tipo de trama.

  2. Todos los servidores locales (o los routeres Cisco si segmento sin servidor) contestarán con una respuesta GNDS.

    El cliente utilizará la primera respuesta GNDS si los servidores múltiples o el Routers contestan a la petición GNDS. La respuesta GNDS contendrá el número de red interno y el nombre del árbol del servidor correspondiente.

  3. Si la respuesta GNDS tiene el árbol correcto, el cliente publicará un pedido del RIP el número IPX interno proporcionado en la respuesta GNDS.

¿Cómo un router Cisco escoge el servidor para incluir en una respuesta de GetNearestServer (GNS)?

El comando show ipx server unsorted mostrará en primero coloca el nombre del servidor que será utilizado para contestar a la petición siguiente GNS. En el Software Release 9.21 o Posterior, utilice el comando ipx gns-round-robin de habilitar el Equilibrio de carga de las respuestas a las peticiones GNS entre los servicios de métrico igual. La manera que se piden los servidores se describe en el documento siguiente: ¿Cómo se ordenan los servidores?

¿Con cuál es la Secuencia de conexión del cliente y/o sin el servidor preferido?

Para la secuencia de conexión sin el servidor preferido, publique los pasos siguientes:

  1. Encuentre el servicio (interrogación y la contestación GNS)

  2. Encuentre la ruta para mantener (interrogación y la contestación del RIP)

  3. Haga la conexión al servidor más cercano

  4. Consiga la información del servidor de archivos

  5. Negocie los tamaños de almacén intermedios

  6. Borre la conexión anterior

  7. Consiga la fecha y hora del servidor de archivos

Para la secuencia de conexión con el servidor preferido, publique los pasos siguientes:

  1. Encuentre el servicio (interrogación y la contestación GNS)

  2. Encuentre la ruta para mantener (interrogación y la contestación del RIP)

  3. Haga la conexión al servidor más cercano

  4. Consiga la información del servidor de archivos

  5. Negocie los tamaños de almacén intermedios

  6. Lea el valor de propiedad del “servidor preferido” salvado en el servidor más cercano

  7. Encuentre la ruta al servidor preferido

  8. Cree la conexión al servidor preferido

  9. Consiga la información del servidor de archivos del servidor preferido

  10. Negocie los tamaños de almacén intermedios

  11. Borre la conexión del servicio con el servidor más cercano

  12. Borre la conexión anterior con el servidor preferido

  13. Consiga la fecha y hora del servidor de archivos

Esto todavía requiere la interrogación/la contestación GNS del servidor más cercano, pero no completa la secuencia de conexión con el servidor más cercano. Utiliza el servidor más cercano para aprender cómo conseguir al servidor preferido. La ruta al servidor preferido es una vez docta, destruye la conexión con el servidor más cercano y relanza la secuencia de conexión con el servidor preferido.

¿Cómo usted filtra las respuestas a las peticiones GNS o GGS?

Es útil controlar el mecanismo las aplicaciones de un router de contestar a una petición del cliente GNS. Para contestar a un cliente, el IOS selecciona uno de los servidores sabidos por el router. El IOS proporciona una manera de evitar que algunos servidores en esta lista sean utilizados, usando el comando ios:

salida-gns-filtro IPX {access-list-number|nombre}

Este comando, una vez aplicado a una interfaz, se asegurará de que el router esté proporcionando solamente a los clientes a un servidor más cercano que corresponde con la lista de acceso especificada.

Conexión de clientes a la red

¿Por qué no puedo conectar a mi cliente cuando está asociado directamente a un Switch?

Los problemas que pueden resultar de esta configuración se describen completamente en el documento siguiente usando Portfast y otros comandos de reparar los retardos de la conectividad de inicialización de la estación de trabajo.

, Si usted tiene un PC conectado directamente con un puerto en el switch de Catalyst, aseegurese básicamente que usted hace la característica portfast habilitar. Para fijarla con el CatOS, utilice el comando:

set spantree portfast enable <module/port>

Además, si usted tiene enlace y los módulos con capacidad de canalización (por ejemplo, el WS-X5225R en el Catalyst 5000 y todos los módulos del Catalyst 6000 son enlace/canalización capaz) usted tiene que aseegurarse que usted los ha apagado manualmente, usando los siguientes comandos:

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

Del software 5.2 en la familia del Catalyst 4000/5000 y a partir del 5.4 en el Catalyst 6000 Family, estos tres comandos se pueden liar en un solo comando macro:


set port host <module/port>

¿Hay licencia o problemas de servidor que afecten a la conexión?

La primera cosa que lo hace un cliente Novell de conexión es enviar una petición GNS (consiga el servidor más cercano). Esta petición es contestada por un servidor o un router. El cliente entonces intenta conectar usando el servidor especificado en la contestación. Hay dos problemas frecuentes que pueden llevar a un error de la conexión:

  • El servidor entrado en contacto no contesta al GNS. Si el número de red interno del servidor más cercano no es 0000.0000.0001, después es probablemente un servidor NT que ignorará el GNS.

  • El servidor entrado en contacto está ejecutando el cortocircuito de las licencias. Solamente un número limitado de clientes podía conectar, las tentativas adicionales está fallando.

En ambos casos, si un router Cisco está implicado, marque qué servidor se da al cliente que usa el comando show ipx server unsort. Usted puede entonces utilizar el comando ipx output-gns-filter de filtrar los servidores que no se deben dar como respuesta.

¿Habrá problemas en la conexión debido para duplicar el IPX o las direcciones MAC?

Normalmente, todos los direccionamientos IPX en la red deben ser diferentes, pues una dirección MAC es parte de ellos. Sin embargo, hay muchos casos donde el usuario puede poner en hard-code una dirección MAC, en este caso, mucha atención de la paga a la unicidad de este direccionamiento. También, tenga muy cuidado de no duplicar un direccionamiento IPX al cortar y pegar la configuración a partir de un router a otro por ejemplo. Esto es extremadamente importante para las interfaces de WAN que utilizan la dirección MAC definida en el comando ipx routing. En el siguiente ejemplo, han duplicado al router A y las configuraciones B. El administrador de la red cambió la red IPX en cada las interfaces pero olvidó poner al día la línea del IPX Routing, que es lo mismo en ambas configuraciones.

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

Una interfaz serial no tiene su propia dirección MAC. El router utilizará la dirección MAC especificada en el comando ipx routing de construir el direccionamiento IPX de sus interfaces seriales. En este caso, el router A y el router B tendrán el exacto el mismo direccionamiento AAA.0000.0C14.11E1 IPX. Por supuesto, hay muchas otras maneras de bajar en el problema de la dirección duplicada. TAC ve muchos problemas de conectividad causados por el direccionamiento duplicado, tenga tan muy cuidado al asignar una red IPX o una dirección MAC.

En un link dado:

  • Todos los servidores y Routers se deben configurar con los números de red IPX únicos para una encapsulación dada.

  • Todas las direcciones MAC deben ser únicas.

Cómo ver servidores y servicios

¿Por qué no puedo acceder un servidor/un servicio específicos?

Si un cliente está intentando acceder un servidor a través de un router Cisco, utilice el comando show ipx server en el router:

Si el servidor/el servicio que usted está buscando está entre ésos enumerados cuando usted publica el comando show ipx server, y allí no es ninguna lista de acceso en la configuración que rompería la Conectividad, después el router muy probablemente no la causa del problema. Si usted no ve el servicio en el router, aseegurese que la red IPX del servidor aparece en la tabla de ruteo. Publique un comando show ipx route de mostrar el tabla de IPX Routing. Un servicio no será hecho publicidad si el router no tiene una ruta a la red correspondiente.

Si el servidor se asocia directamente al router pero todavía no aparece cuando se publica el servidor IPX de la demostración, esté seguro que usted ha configurado la misma red IPX con el mismo encapsulado IPX en el servidor y en el router.

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

En este ejemplo, esté seguro que el servidor Novell está configurado con el SNAP de encapsulado y que el direccionamiento IPX es BEBÉ. Si la encapsulación es incorrecta, los paquetes enviados por el servidor serán desechados por el router. Si las redes IPX no hacen juego, el servidor visualizará un mensaje de error que señala a esa discordancía.

En el router, el comando show ipx traffic dará una cierta información útil, desafortunadamente para el dispositivo entero, no para una interfaz específica. Atención de la paga al campo "error de formato". Será incrementada cada vez que el router recibe un paquete con la encapsulación incorrecta. Si este contador está aumentando, usted es muy probable tener una discordancia de encapsulado.

El [<interface>] del comando show ipx interface da los detalles relacionados IPX para una interfaz específica. Resume el tipo de encapsulación, el direccionamiento IPX, y la lista de acceso configurada para la interfaz. Cuando las localizaciones de averías del servidor/mantienen la visibilidad, es útil marcar que una interfaz específica está recibiendo las actualizaciones del RIP y de SAP de un vecino. Esto es posible usando este comando.

¿Por qué no puedo acceder un servidor IPX con el RConsole?

Mientras que el RIP y el EIGRP llevan la información de red, SAP lleva la información de servicios. Cada Paquete IPX SAP generado por un router Cisco puede llevar hasta siete entradas 64-byte SAP más 32 bytes de los gastos indirectos IPX (para un total de 480 bytes), además de la tara de encapsulación de medio. Cuando se llevan dentro de los paquetes EIGRP, los Paquetes IPX SAP consisten en un encabezado EIGRP estándar con un valor del opcode de 6, seguido por la carga útil estándar de un paquete IPX SAP estándar sin el encabezado IPX original.

En un intercambio de paquetes típico de SAP, Netware Client transmitirá SAP preguntan para localizar a un Servidor del directorio, según lo indicado por el campo del tipo de servidor de SAP (véase la lista del servicio de SAP del Novell). Los paquetes de respuesta de SAP contienen IPX interno el direccionamiento de los servidores que ofrecen los servicios de directorio. El cliente entonces envía un broadcast del RIP para localizar la trayectoria al direccionamiento del servidor IPX interno.

Los pasos siguientes establecen una conexión RConsole:

  1. El cliente del RConsole transmite una petición de SAP que busca un servidor. Específicamente, el RConsole envía una interrogación de general servicios para los servidores del tipo 0x107. El router Cisco debe ser permitido para anunciar los servidores del tipo 0x107 para que el RConsole trabaje en el PC. El cliente envía una petición de SAP de las operaciones de búsqueda del servidor aunque se registra actualmente en un servidor.

    • Si hay un servidor en el segmento, responde al cliente.

    • Si los clientes IPX están en un segmento sin servidor, el router escoge la primera entrada de SAP en su lista sin ordenar para contestar a la petición GNS de los clientes IPX. En algunos casos, la primera entrada de SAP en el router es el servidor incorrecto. Publique el comando show ipx server unsorted de capturar esto. Como solución alternativa, cree una lista de acceso de SAP para bloquear ese servidor y para aplicarlo como filtro GNS.

  2. El cliente envía un pedido del RIP IPX interno el direccionamiento del primer servidor que respondió.

  3. Una vez que el cliente aprende la manera más rápida de conseguir al servidor, le envía un paquete de pedidos de la conexión SPX.

Si usted no puede hacer una conexión RConsole a un servidor Netware determinado, utilice los pasos siguientes para determinar si la causa es un problema de red o un problema de servidor:

  • ¿Puede usted ver servidores? ¿Algunos servidores? ¿Servidores que son locales? ¿Servidores que están a través de WAN?

  • ¿Se afecta el otro tráfico IPX?

  • ¿Qué la tabla de servidor IPX parece en el router más cercano?

  • ¿Usted ve la red interna ID del servidor en el tabla de IPX Routing del router?

  • Indique la red IPX que usted está viniendo de y el servidor en el cual usted está intentando al RConsole:

    • show version

    • ‘show run’

    • muestre el servidor IPX

    • show ipx route

  • ¿Es usted el Netware que usa 4.11 o el Netware 5? ¿Es IP del Novell? ¿Puede usted hacer ping el servidor del Netware 5? Es decir intente conectar por el IP contra por nombre. Si es así el DNS no se resuelve.

En algunos casos, las bases de datos corruptas en un servidor causan los problemas de conexión SPX, determinado pues las bases de datos corruptas se remiten a otros servidores. A menudo, usted puede reparar este problema funcionando con la utilidad de reparación DS. Sin embargo, si la reparación DS no puede restablecer la base de datos, una reinicialización del servidor puede ser requerida. Si usted no puede hacer una conexión RConsole usando el número de red interno, el problema está con el servidor Netware.

El Novell también publica los consejos técnicos en línea en una base de conocimiento. La extremidad siguiente puede ser útil localización de averías de los problemas del RConsole desde la perspectiva de los servidores IPX. Esta extremidad se proporciona como recurso para los clientes de Cisco.

El “RCONSOLE -4.10-112 SPX establece la conexión no podida para establecer una conexión al servidor deseado.”

  1. ¿El REMOTE.NLM se carga en el servidor? ¿Se carga el RSPX.NLM?

  2. ¿Usted ha marcado el DS y aseegurado le es sano y eso todo está sincronizando?

  3. Los errores se pueden causar por un router que esté filtrando hacia fuera el RConsole SAP. El tipo SAP 0107 es el RConsole SAP, y no debe ser filtrado hacia fuera si el RConsole es trabajar correctamente.

  4. Un mún indicador luminoso LED amarillo de la placa muestra gravedad menor NIC puede prohibir al cliente de establecer la conexión SPX.

  5. Haga el absoluto seguro que todos sus números de red IPX son únicos. Esto es la razón de número uno por la que el RConsole falla, pero a veces el más duro para resolver problemas.

  6. Fuerce el tipo de trama en el cliente en vez de Auto-detectar el tipo de trama.

Solución Aternativa

En la pantalla del RConsole, la prensa INS y ingresa el número de red interno IPX del servidor de destino. El número de red interno IPX del servidor puede ser encontrado tecleando los CONFIG en la consola del servidor. Si manualmente ingresar el número de red interno IPX permite que el RConsole trabaje, podría significar que la Tabla de socket IPX en ese servidor se ha excedido. Aumente los tamaños de la Tabla de socket del máximo IPX: INETCFG - > protocolos - > IPX - parámetros >IPX/SPX - tamaños de la Tabla de socket del >Maximum IPX. El valor por defecto es 1200. Aumente este valor a 2400 inicialmente. El servidor necesita ser reiniciado para reajustar estos tamaños de la tabla.

¿Por qué no veo todos mis servidores en un topologia Hub y Spoke?

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

En el diagrama antedicho, tenemos un router de eje de conexión conectado vía una interfaz punto a multipunto con varios otros. Ésta es redes de hub and spoke típicas de un Frame Relay. Todo el Routers está conectado en los mismos routeres radiales de la red IPX A. hace publicidad de su red local X y Y al concentrador, pero usted no ve la red Y en la tabla de ruteo del router X (y usted no ve semejantemente X en la tabla del Router Y). Este problema se relaciona directamente con el horizonte partido. El RIP no hace publicidad de una ruta en la interfaz donde aprendió de ella. Básicamente, el router de eje de conexión aprendido sobre la red X en su serial0 de la interfaz de WAN, conectado con la red A, y él nunca hará publicidad de la parte posterior X en el serial0. El Router Y, también conectado vía el serial0 con el router de eje de conexión, nunca oirá hablar la red X.

Las Especificaciones de Novell no permiten que el horizonte partido sea inhabilitado para el RIP, tan allí son dos métodos alternativos principales disponibles con los routeres Cisco:

  • Substituya la interfaz punto a multipunto con varias interfaces Point-to-Point. Esto puede ser hecha creando varias interfaces secundarias en el serial0 del router de eje de conexión. El problema es que usted necesita asignar un diverso network number para cada link punto a punto establecido, que significa un cambio en el esquema de direccionamiento y un aumento de los tamaños de la tabla de ruteo.

  • RIP del reemplace con el EIGRP IPX. Este último Routing Protocol permite el retiro del horizonte partido (usando el no ipx split-horizon eigrp del comando) y se realiza mejor en los links WAN lentos (actualizaciones graduales, y así sucesivamente). La única desventaja es que todo el Routers debe ser Cisco en WAN.

¿Por qué el NetBios sobre el IPX no está pasando a través de mi router?

Esto ocurre porque el NetBios sobre el IPX confía en los paquetes IPX del tipo de broadcast 20, eso no debe ser remitida por un router. Para hacer que estos paquetes específicos sean remitidos por un router, configure el comando ipx type-20-propagation en cada interfaz que propague el tráfico de NetBios:

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

Configuración del router1 Configuración del router2
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 configuración incluye solamente la partición relevante IPX. En este ejemplo, el host A y el host B están ejecutando el NetBios sobre el IPX. El router1 y el router2 tienen mismo una configuración básica de IPX. Han agregado al comando ipx type-20-propagation en cada interfaz que se supone para retransmitir el NetBios sobre el tráfico IPX. En este los respetos, las interfaces Ethernet 1 del router1 no lo necesitan, pues no hay host de NetBIOS en el segmento Ethernet.

Observe que el comando type-20-propagation, aunque sea obligatorio, tendrá un impacto del rendimiento en su red.

Problemas de rendimiento

Uso de memoria para rutas RIP y SAP

IOS 10.0, 10.2 10.3 y arriba
Rutear 180 bytes para cada ruta, agregan 50 bytes para cada trayectoria adicional si maximum-path > 1 160 bytes para cada ruta, agregan 70 bytes para cada adición si maximum-path > 1
SAP 200 bytes para cada SAP, agregan 4030 bytes para cada tipo SAP 200 bytes para cada SAP, agregan 4030 bytes para cada tipo SAP, y agregan 50 bytes para cada trayectoria adicional

Balance de carga IPX en el router Cisco

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

Si configuran al router Z con el comando ipx maximum-paths 2 y el Routers A y B le llega a la misma red de destino en el mismo número de saltos, el router Z entonces enviará cada paquete al destino al router A y B en una forma de cargas balanceadas, con la lento-transferencia y el Fast-Switching.

Tenga cuidado que a este caso particular, si usted carga la balanza sobre las trayectorias del ancho de banda desigual y usted hace el pburst habilitar, los paquetes defectuosos pueden dar lugar. Más nuevas versiones de Netware deben manejar este mejor que más viejas versiones de Netware, pero vale el intentar quitar el balanceo de carga o el pburst cuando usted está localizando averías un problema de rendimiento en esta configuración. Desde IOS 11.1, usted puede también habilitar la distribución de carga por host usando el comando ipx per-host-load-share. La distribución de carga por host transmite el tráfico a través del múltiplo, los links de costo equivalentes mientras que garantiza que los paquetes para un host extremo dado toman siempre la misma trayectoria.

Rendimiento pobre cuando está habilitado type-20-propagation

El uso del comando IP helper en un router no se recomienda en una red, pero no recomiendan el comando ipx type-20-propagation también, por lo que la carga de tráfico. Con un comando IP helper, el router toma un paquete de broadcast y le da vuelta en un paquete de unidifusión (o el broadcast dirigido) para remitirlo en el segmento siguiente. Con el comando ipx type-20-propagation, el router toma un broadcast y adelante lo según lo transmitido. El paquete tipo 20 contiene una lista de todas las redes idas ya a través y el router nunca la remitirá detrás en una red que aparece en esta lista.

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

Asumamos el comando ipx type-20-propagation se habilita en cada interfaz, con tres segmentos entre el router1 y 2 (una configuración común con el Catalyst 5000 y RS conectados junto por los VLA N de un trunkof 20, por ejemplo).

  1. El PC1 publica un broadcast tipo 20.

  2. El router1 consigue lo y adelante una copia en cada segmento A B y el C (con la lista del segmento D).

  3. El router2 consigue tres copias y adelante cada uno de ellas (la lista del segmento es DA para el primer DB para segundo DC para el tercero) a los dos otros segmentos que hacen 6 más copias del paquete (el DA es envía a B y C, DB a A y al C, DC a A y B).

  4. El router1 consigue estas seis copias (LENGUADO, DAC, DBA, DBC, DCA, bcd) y delantero todos al segmento más reciente que no lo ha considerado.

  5. El router1 consigue los seis paquetes (DABC, DACB, DBAC, DBCA, DCAB, DCBA) y los cae todos pues tienen todo el cruzado todos los segmentos.

Con este ejemplo podemos ver que cada uno transmitir generará 15 más paquetes entre el dos Routers. Con cuatro links (VLA N) entre dos Routers usted tiene 64 paquetes. Con cinco links entre dos Routers usted tiene 325 paquetes, y así sucesivamente. Por lo tanto, usando este comando causará un mayor número de paquetes, que pueden reducir o apagar su red.

Para mejorar la situación, utilice los siguientes comandos:

Cuando se configuran éstos, aseeguramos el tipo 20 estamos viniendo adentro en una interfaz que sea un ruta principal de nuevo a la fuente. Si no es, caemos el paquete. Cuando vamos a enviar un paquete, marcamos si la red/la interfaz que la estamos enviando a no es una ruta de nuevo a la fuente de este paquete del tipo 20, o bien la caemos. Esto está además de los ocho saltos que marcan para saber si hay loopes que las llamadas de la Especificación del router IPX para que nosotros hagamos con el tipo 20s.

Configuración de lista de acceso

Filtrado de un rango de redes IPX

La lista de acceso ampliada IPX permite que usted filtre un rango de las redes. Por ejemplo, usted puede tener una red IPX grande. Todas las redes IPX comienzan con el y. Las redes no necesitan ir a un poco de Routers, así que filtré cada uno usando los siguientes comandos:

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 acceso continúa para 120 líneas. ¿Cómo puedo filtrar las redes IPX que comienzan con el A43?

Intento usando el siguiente comando:

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

Sea seguro incluyen una línea para permitir las rutas que usted quiere. La cualquier palabra clave representará “todos los protocolos” y es un argumento obligatorio. Los trabajos de máscara sobre el mismo principio que la máscara comodín IP. Los bits del host deben ser especificados, si no usted no tendrá la opción de la máscara. Usted puede utilizar la lista de acceso ampliada IPX en aun así las maneras que usted puede utilizar la versión estándar. Si usted está utilizando el protocolo netware link services (NLSP) como su Routing Protocol, usted necesitará utilizar las áreas múltiples así que usted puede las rutas de filtro en los límites de área.

Depuración

Al ver la salida de los paquetes IPX de un debug algunos paquetes se marcan como “mún Pkt.” ¿Por qué estos paquetes están marcados como "Bad Pkt?

Ejemplo:

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

Esto puede ocurrir porque el socket 455 es el número de socket del NetBios y transmiten a la dirección destino de la capa MAC del paquete. Este paquete será caído por el router por abandono a menos que se configure la propagación tipo 20 IPX o un ayudante-direccionamiento IPX. Vea la documentación en habilitar la propagación tipo 20 para más detalles en el envío de este NetBios sobre los broadcastes dirigidos IPX.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 10564