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

Introducción y resolución de problemas frecuentes de Novell IP e
IPX.
Contenido
Introducción
prerrequisitos
Requisitos
Componentes Utilizados
Convenciones
Antecedentes
Comprensión de los números de la red IPX
Información sobre números de redes internas y externas en servidores Novell
Encapsulación en Novell
Convenciones para la asignación de nombres de la encapsulación IPX
Protocolos de ruteo IPX
Estudios de casos de la red Novell IPX
Caso Práctico nº 1: Cisco a interfuncionamiento 3Com en Interfaces de WAN
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
Caso Práctico nº 3: Incoherencia de IPX SAP cuando se utiliza IPX EIGRP como protocolo de ruteo IPX
Caso Práctico nº 4: El comando show IPX traffic indica varios errores de formato
Caso Práctico nº 5: Los IPX SAP no aparecen en la tabla de servidor IPX en las nubes de WAN
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
Caso Práctico nº 7: No es posible obtener acceso a recursos de Citrix Winframe con IPX en routers Cisco
Caso Práctico nº 8: Inicio de sesión en IPX Novell lento
Caso práctico #9: Resolución de problemas de entradas de la tabla IPX SAP corruptas
Caso práctico #10: Es posible que el listado de servidores a partir del comando show ipx servers unsorted muestre servidores fuera
de servicio.
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
Caso Práctico nº 2: La habilitación de IP Multicast dentro de la red de producción desactiva las redes IPX existentes
Caso Práctico nº 3: Por qué Novell IP no trabaja a través de un router Cisco que ejecute NAT
Caso Práctico nº 4: Conexión IP lenta de Novell
Preguntas comunes de configuración
¿Por qué no puedo configurar más de 200 redes IPX en el router?
¿Por qué no puedo hacer ping a un host Novell desde mi router?
¿Por qué no puedo configurar el ruteo IPX?
¿Qué es el comando ipx pad-process-switched-packets?
¿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?
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?
¿Por qué al activar IPX EIGRP en una interfaz de VLAN, se desactiva IPX MLS en la interfaz correspondiente?
Problemas comunes de conectividad
Comprensión del proceso de registro del cliente IPX
Conexión de clientes a la red
Cómo ver servidores y servicios
Problemas de rendimiento
Uso de memoria para rutas RIP y SAP
Balance de carga IPX en el router Cisco
Rendimiento pobre cuando está habilitado type-20-propagation
Configuración de lista de acceso
Filtrado de un rango de redes IPX
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?
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
Nodo:
número de bit 32 representado en el hex.
Administrativo asignado
Rango: 0x00000001 - 0xFFFFFFFE
0xFFFFFFFF = transmitido
0xFFFFFFFE = ruta predeterminado
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.
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
Convención
Convención de
para nombres
para
denominación de
del Switch del
LSAP
nombres del
software del
Cisco Catalyst
Cisco IOS
Novell
*
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
Ethernet Novell-ether
FDDI
Token
Ring
Descripción
SNAP
SNAP
Ethernet_SNAP
Sobre +
BROCHE s
AAAA
802.2 de los
Ethernetes
SNAP
SNAP
FDDI_SNAP
FDDI usando
AAAA 802.2 +
BROCHE
SAP
SAP
FDDI_802.2
E0E0
FDDI usando
el sobre 802.2
SAP
n/a
Token Ring
E0E0
Token Ring
con 802.2
SNAP
n/a
Ring_SNAP
simbólico
Token Ring
AAAA 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 linkuprequest 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:
Inhabilite el registro de la consola y habilite el registro del buffer publicando el comando logging buffered.
Publique los comandos debug ipx eigrg events y debug ipx eigrp neighbor {neighbor ID}.
Transición el estado del link de la interfaz.
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.
1.
2.
3.
4.
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-routepath 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 gnsround-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.
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.
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.
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?
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:
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
ipx routing 0000.0000.0002
!
interface Ethernet0
ipx network B
ipx type-20-propagation
!
interface Serial0
!
interface Serial0
ipx network 1
ipx network 1
ipx type-20-propagation
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
180 bytes para cada ruta, agregan
Rutear 50 bytes para cada trayectoria
adicional si maximum-path > 1
SAP
10.3 y arriba
160 bytes para cada ruta, agregan 70
bytes para cada adición si maximumpath > 1
200 bytes para cada SAP, agregan 4030
200 bytes para cada SAP, agregan
bytes para cada tipo SAP, y agregan 50
4030 bytes para cada tipo SAP
bytes para cada trayectoria adicional
Balance de carga IPX en el router Cisco
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.
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:
IPX type-20-input-checks
Do additional input checks on type 20 propagation packets
IPX type-20-output-checks
Do additional output checks on type 20 propagation packets
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.
© 1992-2015 Cisco Systems Inc. Todos los Derechos Reservados.
Fecha de Generación del PDF: 25 Agosto 2015
http://www.cisco.com/cisco/web/support/LA/tech/legacy/102/1024/1024522_33.html