Маршрутизация Novell / IPX

Описание и устранение общих неполадок Novell IP и IPX

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание

Связанные обсуждения сообщества поддержки Cisco

Введение

Этот документ предоставляет некоторые прочие сведения, отнесенные протоколу IPX. Наша идея не состоит в том, чтобы полностью задокументировать Novell, а скорее создать минимальный список часто задаваемых вопросов, классифицированных темами.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Общие сведения

Общие сведения о сетевых номерах IPX

Как с другими сетевыми адресами, адреса Сети Novell с протоколом IPX должны быть уникальными. Эти адреса представлены в шестнадцатеричном формате и состоят из двух частей: номер сети и номер узла. Номер сети IPX, который назначен администратором сети, 32 бита длиной. Номер узла, который обычно является Адресом для управления доступом к среде (MAC) для одной из сетевых интерфейсных плат системы (NIC), 48 битов длиной.

  • Сеть

    • 32 битовых числа представлены в Hex

    • Административно назначенный

    • Диапазон: 0x00000001 - 0xFFFFFFFE

    • 0xFFFFFFFF = Широковещательное сообщение

    • 0xFFFFFFFE = Маршрут по умолчанию

  • Узел:

    • 48 битовых чисел представлены в Hex

    • MAC-адрес платы NIC (может быть административно назначен),

Использование IPX MAC-адреса для номера узла позволяет системе передать узлы для предсказания что MAC-адрес использовать на канале передачи данных. (Напротив, потому что часть, относящаяся к хосту сетевого IP - адреса не имеет никакой корреляции к MAC-адресу, узлы IP должны использовать Протокол ARP для определения MAC - адреса назначения.)

Схема адресации первоначально позволила 0xFFFFFFFE использоваться в качестве адреса. После введения NLSP сеть-2 используется для представления маршрута по умолчанию. Маршрутизаторы Cisco обработают 0xFFFFFFFE как маршрут по умолчанию, невзирая на то, что это является корректируемым.

Примеры сети. Адреса узла

C15C0.0000.0000.0001

Плохо 0000.123d.3423

О внутренних и внешних номерах сетей на серверах Novell

Начиная с введения NetWare 3.x, архитектура сервера была созданным modularly, и каждый процесс (шлюз, маршрутизация, файл, печать) связывается с многозадачным механизмом ядра ОС. Механизмам ядра ОС назначают сетевой адрес IPX, известный как внутренний сетевой номер, и тот идентификатор узла всегда 0000.0000.0001. Поэтому 3.x/4.x Сервер каждого Novell имеет внутренний сетевой номер с номером внешней сети, связанным с адаптером сети. Адаптер сети может быть связан с нескольками сетевых адресов каждый с уникальным типом фрейма. Кроме того, Серверы Novell могут содержать несколько сетей адаптеры и маршрут между отдельными сегментами сети. Сервер Microsoft NT рабочий IPX не появится с идентификатором узла 0000.0000.0001 и не использует понятие внутреннего и внешнего сетевого номера по умолчанию.

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

Инкапсуляция Novell

Существует много других Инкапсуляций Novell. Для Ethernet только, существуют целых четыре. Тип инкапсуляции очень важен, поскольку два устройства с помощью других методов инкапсуляции на той же среде не будут в состоянии связаться. Клиенты novell обычно в состоянии адаптироваться к инкапсуляции, доступной на их ссылках, но серверы IPX должны иметь непротиворечивый тип инкапсуляции hardcoded.

Названия инкапсуляции являются другими в Novell или Терминология Cisco. Следующая таблица предоставляет сводку Ipx encapsulation, доступного для различных типов сред.

Соглашения об именования для инкапсуляции IPX

Соглашение о записи имен Cisco IOS Соглашение о записи имен коммутатора Cisco Catalyst * Соглашение об именовании программного обеспечения Novell LSAP Описание
Ethernet Novell-Ether 8023RAW Ethernet_802.3 (сырые данные) FFFF Ethernet без LLC или SNAP
_______________ ARPA Ethernet II (EII) Ethernet_II 8137 Ethernet II s/вводит 8137
SAP 8023 Ethernet_802.2 E0E0 Ethernet с 802.2 конвертами
SNAP SNAP Ethernet_SNAP AAAA Конверт Ethernet s/802.2 + SNAP
FDDI SNAP SNAP FDDI_SNAP AAAA FDDI с помощью 802.2 + SNAP
SAP SAP FDDI_802.2 E0E0 FDDI с помощью 802.2 конвертов
Token Ring SAP н/д Token Ring E0E0 Token Ring w/802.2
SNAP н/д Маркерный Ring_SNAP AAAA Token Ring w/802.2 + SNAP

  • ETHERNET_802.3 Типа фрейма является собственным методом инкапсуляции Novell. Они помещают пакеты SPX/IPX непосредственно в 802.3 кадрах и не используют 802.2 LLC или SNAP. Это - NOVELL-ETHER Инкапсуляции Novell в терминологии Cisco.

  • ETHERNET_II Типа фрейма является "стандартным" формированием кадров Ethernet II. Пакеты SPX/IPX наполнены в кадры Ethernet II, с помощью кода 8137 типа. Эти кадры отличаются от Кадров Novell только в поле кода/длины кадра двухоктетного типа; в противном случае они идентичны. Это - ARPA Инкапсуляции Novell в терминологии Cisco.

  • ETHERNET_802.2 Типа фрейма является предпочтительной инкапсуляцией Novell для сетевого обеспечения 3.12, сетевое обеспечение 4. X-серверы: это - Ethernet с 802.2 конвертами. Это - Инкапсуляция Novell SAP для 9.21 в терминологии Cisco.

  • ETHERNET_SNAP Типа фрейма является Ethernet с 802.2 конвертами + SNAP. Это обычно не используется. Это - Novell Encapsulation SNAP в терминологии Cisco.

* Конфигурации IPX на коммутаторах серии Catalyst применяются только для Ethernet к конфигурациям мостов FDDI.

Протоколы IPX-маршрутизации

Использование упомянутых ниже протоколов, маршруты и сервисы, о которых знает Маршрутизатор IPX, может определяться и управляться динамично:

  • SAP (Сервисный Протокол объявления): протокол IPX, который позволяет сетевым ресурсам, таким как серверы и маршрутизаторы становиться известными клиентам сети. SAP требуется для определения, где сервисы отдельной сети находятся на объединении нескольких локальных сетей.

  • RIP (протокол маршрутной информации): Протокол IGP, который использует счетчик переходов и отсчитывает как метрики маршрутизации. Счетчик переходов измеряет расстояние между источником и назначением. Задержка в сети (время распространения пакета до адресата и обратно) между источником и назначением измерена в галочках или 1/18 вторых интервалах. RIP изучает, выбирает и поддерживает таблицу маршрутизации. RIP является протоколом маршрутизации по методу вектора расстояния, используемым для обмена сведениями о маршрутизации в независимой системе.

    • RIP и SAP сотрудничают как команда для помощи клиентам, серверам, и маршрутизаторы находят сетевые сервисы и маршруты к каждому сервису. Они также используются для соединений клиент-сервер, а также маршрутизатор-маршрутизатор связи.

  • IPX EIGRP: IGRP является Протокол маршрутизации внутреннего шлюза Cisco, используемый в TCP/IP и интерсетях OSI. IGRP использует дистанционно-векторную технологию маршрутизации так, чтобы каждый маршрутизатор не знал всех отношений маршрутизатора/ссылки для всей сети. Каждый маршрутизатор объявляет пункты назначения с указанием соответствующего расстояния. Каждый маршрутизатор, получающий информацию, корректирует расстояние и передает ее соседним маршрутизаторам.

    • Сведения о расстоянии представлены в IGRP в виде комбинации таких показателей, как доступная полоса пропускания, задержка, использование нагрузки и надежность канала. Это позволяет точно настраивать характеристик канала для достижения EIGRP оптимальных путей, усовершенствованная версия IGRP. В EIGPR используется такая технология вектора расстояния, что и в IGPR, и основные данные о расстоянии остаются неизменными. Свойства сходимости и операционная эффективность этого протокола существенно улучшены. Это позволяет усовершенствовать архитектуру, сохранив текущие вложения в IGRP. Для получения дополнительной информации на EIGRP, посмотрите следующий документ:

      Введение к расширенному IGRP (EIGRP)

      Протоколозависимые модули ответственны за специальные требования к протоколу слоя сети. Например, модуль IPX-EIGRP отвечает за отправку и прием пакетов EIGRP, которые инкапсулируются в IPX. IPX-EIGRP ответственен за парсинг пакетов EIGRP и Алгоритма обновления Diffusing-Update Algorithm (DUAL) информирования (DUAL) новой полученной информации. IPX-EIGRP отправляет DUAL запросы на принятие решений о маршрутизации, результаты которых сохраняются в таблице маршрутизации IPX. IPX-EIGRP (межсетевой пакетный обмен усовершенствованного протокола внутреннего шлюза) обеспечивает следующие свойства.

    • Автоматическое перераспределение - Маршруты RIP IPX автоматически перераспределены в EIGRP, и Маршруты IPX-EIGRP автоматически перераспределены в RIP без любых команд, вводимых пользователем. Перераспределение может быть выключено с использованием, не перераспределяют подкоманду маршрутизатора протокола. И IPX-RIP и IPX-EIGRP можно полностью выключить на маршрутизаторе.

    • Повышенная пропускная способность сети – при использовании IPX-RIP максимально возможная пропускная способность сети – 15 переходов. Когда IPX-EIGRP включают, самая большая возможная ширина является 224 переходами. Поскольку метрика EIGRP достаточно большая и может поддерживать тысячи переходов, единственной преградой для расширения сети является счетчик переходов транспортного уровня. Cisco обходит эту проблему приращением области управления транспортом, когда пакет IPX проходит 15 маршрутизаторов и следующий транзит к пункту назначения через EIGRP. Если маршрут RIP используется как следующий переход к месту назначения, то поле управления переносом увеличивается как обычно.

    • Пошаговые обновления SAP – полные обновления SAP отправляются периодически до тех пор, пока не будет обнаружен сосед EIGRP, а после этого отправка выполняется только при изменениях в таблице SAP. Это работает благодаря надежному механизму передачи EIGRP, поэтому для возможности отправки последовательных пакетов SAP должен присутствовать одноранговый узел IPX-EIGRP. Если на определенном интерфейсе нет одноранговых узлов, на этот интерфейс будут регулярно отправляться SAP до обнаружения однорангового узла. Эта функциональность является автоматической на последовательных интерфейсах и может быть настроена на Средах LAN при желании.

  • NLSP (Протокол NetWare Link Services): Этот протокол маршрутизации может использоваться в сочетании с, или вместо SAP и RIP. Это обращается к ограничениям RIP и SAP, когда они внедрены в большом, сложных межсетевых взаимодействиях. Как правило, NLSP использует меньше пропускной способности, является более быстрым при обновлении ее таблицы маршрутизации и является более масштабируемым к большим объединениям нескольких локальных сетей, чем RIP и SAP. NLSP не является обычно используемым протоколом маршрутизации IPX.

Наглядные примеры сети с Novell IPX

Примеры практического применения 1: Совместимость Cisco и 3Com на интерфейсах WAN

По умолчанию маршрутизаторы Cisco настроены для Периодических обновлений SAP, которые происходят каждые 60 секунд на всех интерфейсах. Однако на маршрутизаторах Предприятия 3Com, Интерфейс WAN настроен для непериодических Обновлений SAP по умолчанию. Непериодическими Обновлениями являются Обновления SAP, которые происходят только, когда ссылка подходит, когда ссылка побеждена административно, или когда служебная информация изменяется вместо периодического интервала. Этот параметр поддерживается для обновлений SAP только. При соединении маршрутизатора Cisco с маршрутизатором 3Com рабочий IPX по Интерфейсу WAN с конфигурацией IPX по умолчанию записи сервера IPX в маршрутизаторе Cisco только появятся в течение 240 секунд после установления соединения или изменения топологии из-за конфигурации по умолчанию маршрутизатора 3Com, устанавливаемого для непериодических Обновлений SAP. Для исправления этой проблемы изменение конфигурации требуется или на маршрутизаторе Cisco или на 3Com.

Для изменения маршрутизатора 3Com на Периодические обновления SAP на Интерфейсе WAN выполните следующие шаги:

  1. Проверьте конфигурацию IPX на Интерфейсе WAN на маршрутизаторе 3Com путем выдачи команды: покажите [! <порт] |! *] - sap контроль

    Пример: SH - SAP ПРОДОЛЖЕНИЕ СЛЕДУЕТ

  2. Если маршрутизатор 3Com будет настроен для "noperiodic" на Интерфейсе WAN, то конфигурация должна будет быть изменена на "периодическое" использование команды: setdefault! <port> - sap control=periodic

    Для изменения маршрутизатора Cisco на непериодические Обновления IPX SAP на интерфейсе выполните придерживающуюся интерфейсную команду:

    сок ipx update interval, только для изменений

Примеры практического применения 2: Очередь широковещания Frame Relay и разрыв подключения по протоколу IPX в сетях Frame Relay

Маршрутизатор Cisco, который настроен для IPX и размещен как концентратор Облака Frame Relay, возможно, должен привязать изменения конфигурации к Очереди широковещательной рассылки Frame Relay. В то время как фактически интерфейс может служить множественным сайтам, это - результат Очереди широковещательной рассылки Frame Relay, не выполняющей своих обязательств к размеру только одного интерфейса. Размер очереди по умолчанию Широковещания Frame Relay (с ретрансляцией фреймов) равняется 64 и должен быть настроен как 64 раза количество подчиненных интерфейсов. Размер очереди, настраиваемый слишком маленький, может привести к обновлениям RIP/SAP потери IPX по глобальной сети (WAN). Обновления RIP/SAP потери IPX вызовут потерю подключения между концентратором и удаленными сайтами.

Пример: Очередь широковещательной рассылки 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)

Рекомендации по конфигурации для очереди широковещательной рассылки Frame Relay Настройки

Широковещательная очередь Frame Relay

  • Для создания специальной очереди для заданного интерфейса для удержания широковещательного трафика, который был реплицирован для передачи на множественных Идентификаторах подключения соединения данных (DLCI) (DLCI) используйте команду настройки интерфейса Очереди широковещательной рассылки Frame Relay:

  • скорость передачи пакетов byte-rate размера frame-relay broadcast-queue

Описание синтаксиса

  • размер - Количество пакетов для удержания в очереди широковещательных пакетов. Рекомендация для Сети RIP/SAP IPX состоит в том, чтобы иметь 64 пакетных раза количество удаленных сайтов. Например, если существует 7 удаленных сайтов, настраивают глубину очереди как 448.

  • byte-rate - Максимальное число байтов, которые будут передаваться в секунду. Рекомендация является использованием конфигурация по умолчанию 256000 байт в секунду

  • скорость передачи пакетов - Максимальное число пакетов, которые будут передаваться в секунду. Рекомендация является использованием по умолчанию 36 пакетов в секунду.

Примеры практического применения #3: Несогласованность IPX SAP при использовании IPX EIGRP в качестве протокола маршрутизации IPX

Ocassionally, может быть внезапная потеря подключения к определенному Серверу Novell или Сервису IPX. Серверы Novell или IPX Services могут исчезнуть случайным образом из Таблиц SAP IPX. Это может также заставить размеры таблицы SAP варьироваться некоторыми, SAP по сети.

Если вы испытываете эти проблемы, просматриваете эти ошибки в программном обеспечении и обновление к версии программного обеспечения, которая не испытывает эти проблемы.

Рассмотрите эти Комментарии к выпуску:

CSCdp13795 - Несогласованность IPX SAP с EIGRP IPX

Если последовательный интерфейс переведен в нерабочее состояние для недолгого времени и затем переведен в рабочее состояние снова, при использовании Протокола EIGRP IPX вы могли бы испытать несоответствие в обслуживании Рекламный Протокол (SAP) обновления на удаленном маршрутизаторе. Для подтверждения проблемы введите EXEC команды clear ip eigrp neighbors, или введите команду no ipx linkup-request sap для последовательных интерфейсов и проверьте, что не повторно происходит проблема.

CSCdk13645 - ТАБЛИЦА SAP IPX Может Стать Противоречивой После того, как Несколька адресов серверов будут Удалены из Таблицы

При использовании обновлений SAP с приращением EIGRP IPX (RSUP) таблицы сервера между двумя или больше Соседними eigrp могут стать противоречивыми. В частности проблема может произойти, когда только три дюжины серверов уходят в то же время, в то время как маршруты к тем сервисам остаются в таблице маршрутизации, если существуют несколько EIGRP соседние узлы или пути к соседнему узлу. Вниз Флэш - обновление для некоторых недавно неработающих серверов не отсылается во все интерфейсы, таким образом, некоторым устройствам демонтировали серверы, и другие не делают. Обходной путь должен очистить соседние узлы IPX EIGRP на модуле, который показывает эти серверы, остающиеся в таблице.

Флэш - обновление является срочным объявлением любых изменений в сети, и появлением новых сервисов или исчезновением существующих сервисов. Поскольку придерживающийся sample lab debug output показывает, Флэш - обновление отослан во все интерфейсы, которые выполняют 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 - Отсутствие SAP после установления соединения/вниз

В конфигурациях сети с интерфейсом (ами) IPX, соединяющим локальный маршрутизатор и удаленный маршрутизатор (ы), настроенный с инкрементным SAP EIGRP IPX (режим по умолчанию на неинтерфейсах LAN (локальной сети), когда EIGRP IPX используется), может проиграть удаленный маршрутизатор (ы), некоторые SAP, если интерфейс локального маршрутизатора (интерфейс, где от сервисов IPX услышали, но не связывают с удаленным маршрутизатором) подвергается быстрому вниз / переход. Работа вокруг должна восстановить смежность IPX-EIGRP путем выдачи команды clear ipx eigrp neighbors в удаленном маршрутизаторе (ах).

Основная причина CSCdm23488 является проблемой синхронизации с программными процессами, которые вызывают следующая ссылка IPX вниз и последовательности соединения. Когда большое число сервисов IPX включено, интерфейс подходит, в то время как яд SAP, передаются. В результате яд SAP, отвергают новые объявления и эффективно препятствуют тому, чтобы были объявлены некоторые сервисы.

CSCdx73624 - Без вести пропавшие IPX SAP

В концентраторе и лучевой Топологии Frame Relay, два луча могут не получить друг друга, SAP, если облако глобальной сети (WAN) выполняет и RIP IPX и EIGRP IPX. Результатом является противоречивая таблица SAP. Как обходной путь, отключите RIP IPX.

Шаги по устранению неполадок

Если вы замечаете, что проблема с без вести пропавшими SAP, используйте придерживающиеся действия по устранению проблем:

  • Если SAP изучено через другой луч Frame Relay, маршрутизатор концентратора также пропускает SAP или только локальный маршрутизатор на конце луча?

  • Вы используете инкрементный или периодические обновления SAP?

  • При включении периодических обновлений определите, получает ли маршрутизатор обновленные обновления SAP. Просмотрите счетчики SAP путем запуска команды 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
  • Вы проигрываете, все SAP от индивидуального сервера?

  • Существует ли отношение между отказом соединения, и отсутствие SAP? Если SAP потеряно после изменения соединения, используйте следующие шаги:

    1. Отключите вход через консоль и включите буферную регистрацию путем запуска команды logging buffered.

    2. Выполните debug ipx eigrg events и отладьте соседний eigrp ipx {идентификатор соседнего узла} команды.

    3. Перейдите состояние канала интерфейса.

    4. Если вы обнаруживаете без вести пропавших, SAP, ждите по крайней мере пять минут, чтобы проверить, что действительно отсутствует SAP. Перехватите выходные данные show ipx server и покажите ipx routecommands и в концентраторе и в маршрутизаторах на конце луча.

    5. Выполните команду clear ipx route в лучевом конце.

    6. Выполните show ipx server и команды show ipx route, чтобы проверить, было ли изучено все SAP.

Если вы не можете решить проблему с вышеупомянутыми шагами, вы, возможно, должны выполнить команду debug ipx sap activity. Сообщения отладки в качестве примера предоставлены ниже.

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

Примечание: Гарантируйте понимание влияния этой команды отладки прежде, чем включить его так как это может генерировать большое количество выходных данных. Для уменьшения влияния отладок к маршрутизатору мы рекомендуем отключить вход через консоль и включить буферную регистрацию с размером достаточного размера буфера.

Примеры практического применения 4: Команда show IPX traffic указывает на ошибки форматирования

Например: : Команда настроена как lt-4500-3a#show трафик IPX. Выходные данные выглядят следующим образом:

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

Ошибки форматирования в команде show ipx traffic являются количеством недопустимых пакетов, от которых сбрасывают (например, пакеты с поврежденным заголовком). Этот счетчик включает пакеты IPX, полученные для инкапсуляции, что не настроен маршрутизатор.

Большинство PC в сети автоматически обнаруживает тип фрейма IPX или на Token Ring или на Сети Ethernet путем отправления запросов GNS всех четырех возможных типов фрейма. Интерфейс на маршрутизаторе трудно кодирован к определенному типу фрейма. Если интерфейс на маршрутизаторе получает пакет IPX с другим типом фрейма, чем, что настроено, пакет отброшен, и "поле формата" инкрементно увеличено. Поэтому PC, настроенные для типа фрейма по умолчанию, будут всегда делать запись по крайней мере трех ошибок форматирования на смежном маршрутизаторе Cisco после запуска.

Обратитесь к Командам IPX Novell для получения дополнительной информации о команде show ipx traffic.

Примеры практического применения №5: IPX SAP не попадают в таблицу сервера IPX через облака WAN

Маршрутизаторы Cisco по облаку глобальной сети (WAN) покажут всего Ipx route в таблице маршрутизации IPX. Однако ни один из IPX SAP не появляется в Таблице сервера IPX. Кодирование линии AMI не поддерживает пакеты с плотностью высоких предварительных нагрузок. Шифрование линии должно быть кодированием B8ZS, которое, при считывании плотности высоких предварительных нагрузок, инвертирует поток данных для разбивания нолей. Пакеты IPX SAP могут включать шаблон данных 11 последовательных, обнуляет. Например, тип, 4 файловых сервера имеют адрес IPX ABCDEF.0000.0000.0001, который будет поврежден, если Облако глобальной сети (WAN) не поддержит высокую плотность нулей. Если пакет достигнет поврежденного удаленного маршрутизатора, то он будет отброшен. В результате Обновления RIP IPX достигнут удаленных маршрутизаторов, но Пакеты IPX SAP не будут, из-за высокой плотности нулей.

Решение состоит в том, чтобы иметь поставщика услуг глобальной сети (WAN), правильно устанавливает шифрование линии в B8zs по глобальной сети (WAN).

Для подтверждения конфигурации инициируйте функцию проверки связности IP ping с образцом всех нолей по облаку глобальной сети (WAN) в 500, 1000 и 1500 байтов. Если Функция проверки связности IP ping успешна, шифрование линии не является проблемой, так как эхо-запросы образца ноля высокой плотности успешны.

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#

Примеры практического применения #6: Рабочие станции не в состоянии подключиться к одному из серверов через сетевое окружение

В некоторых случаях рабочие станции в состоянии видеть все Серверы Novell в Сетевом окружении, но неспособный соединиться с любым из серверов через сетевое окружение. Для приложения к серверам в Сетевом окружении по VLAN или по множественным сетям, клиентские рабочие станции должны иметь Клиента novell 32 установленных или включить type-20-propogation IPX на соответствующих маршрутизаторах. Кроме того, каждый номер сети в кампусе должен быть уникальным по всей сети. Используйте программное средство PING IPX на Серверах Novell и программное средство IPX PING на маршрутизаторах Cisco для подтверждения подключения по глобальной сети (WAN).

Примеры практического применения №7: Невозможно получить доступ к ресурсам Citrix Winframe с помощью протокола IPX на маршрутизаторах Cisco

Если выходные данные command show ipx servers покажут, что существует несколько серверов Winframe с тем же количеством перехода/галочки далеко, то, по умолчанию только SAP первой записи будет передаваться клиенту.

Это не проблема для Сервера Novell, так как клиент примет первый SAP, перейдет к первому серверу, и затем перенаправляться к серверу выбора клиента, если будет предпочитаемый сервер. Winframe не имеет той функциональности. Если клиент будет установлен для имени сервера "x", но получит SAP для имени сервера "y", так как "y" является первым в таблице SAP, то клиент никогда не будет соединяться.

Решение состоит в том, чтобы добавить команду ipx gns-round-robin как команду global на маршрутизаторе со множественным winframe SAP того же расстояния. Маршрутизатор будет, циклический выбор посредством ответов SAP и клиента получит SAP для корректного сервера, даже если это не будет первый SAP в таблице SAP маршрутизатора.

Примеры практического применения №8: Медленный вход в сеть Novell с протоколом IPX

Наиболее распространенной причиной для медленного Novell входа в систему является проблема, известная как обход дерева. Когда агент клиента отправляет запрос к NDS, запрос не всегда получается сервером имен, который квалифицирован для выполнения запроса. Сервер имен, получающий запрос, должен найти сервер имен, который может выполнить запрос. Несколько серверов имен, возможно, должны связаться, прежде чем квалифицированный сервер расположен. Для обнаружения информации сервер имен инициирует поиск, пока копия не найдена, что это содержит необходимые сведения. Этот процесс называют обходом дерева. Пока к данным реплики можно обратиться быстро, обход дерева не является проблемой. Однако, если данные реплики только доступны по медленному соединению, таковы как канал WAN, задержки могут произойти. Любое приложение, которое использует NDS, может вызвать обход дерева, но обход дерева может быть минимизирован с хорошим дизайном дерева NDS.

Общие медленные проблемы входа в систему и разрешения через веб-узел 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

Основные принципы устранения неполадок

Для определения, что потенциально вызывает медленную проблему входа в систему получите трассировку пакетов появления задач, перехватывая все пакеты, переданные к и от рабочей станции. Две трассировки пакетов будут необходимы для определения проблемы точно: одна трассировка пакетов порта сервера и другая трассировка пакетов рабочей станции. Путем получения двух трассировок пакетов будет очень просто определить, отнесена ли проблема к пакетам сброшенный из сети.

Пример практического применения #9: Восстановление поврежденных записей таблицы IPX SAP

Записи SAR IPX, которые отображают недопустимые символы, фантомные сети или bit-shifted/bit-swapped символы, наиболее вероятно повреждены записи SAP. Типовые недопустимые символы включают (! ~ ^)). С тех пор нет никакого Уровня 3 (L3) Контрольная сумма в кадре IPX SAP, нарушение целостности данных может произойти с обновлениями IPX SAP. Это повреждение не может быть вызвано Уровнем 2 (L2) повреждение, потому что CRC на кадре L2 был бы недопустим, и маршрутизатор отбросит кадр. Поврежденный IPX SAP всегда вызывается неисправным оборудованием. Обнаружение источника Поврежденных SAP для IPX довольно просто при использовании монопольного RIP IPX; Просто используйте Счетчик переходов для обнаружения источника. С EIGRP IPX устранение проблем является более трудным, как бы то ни было.

С путями с избыточным резервом и циклично выполненной топологией с помощью EIGRP IPX, запись поврежденного SAP может остаться навсегда, не испытывая таймаут, даже когда было выключено исходное устройство. Причина, которая SAP, не исчезнет из смешанного EIGRP, и среда RIP - то, вследствие того, что, когда у вас есть параллельные пути через сеть, RIP и EIGRP передадут записи SAP назад и вперед. Это поведение предотвратит SAP от когда-либо таймаута. Когда EIGRP получит обновления от двух или больше других маршрутизаторов от обновлений SAP, EIGRP будет пасовать назад обновления в RIP от EIGRP, если уйдет запись RIP. EIGRP также сохранит счетчик переходов RIP, который делает определение местоположения источника более трудным.

Условие цикличного выполнения, описанное выше только эффектов SAP, не маршруты. Это вызвано тем, что SAP будет всегда указывать к краткому маршруту и не замечает циклы маршрутизации. SAP не является протоколом маршрутизации. Удаление EIGRP во всем пути позволит поврежденным SAP стареть.

Должный поведение EIGRP IPX и поврежденного IPX устранения проблем элементы таблицы SAP, используйте придерживающиеся процедуры устранения проблем в изоляции Поврежденных SAP для IPX при использовании EIGRP IPX:

  1. Во время окна выхода сети из строя отключите EIGRP IPX и используйте RIP для точного определения местоположения источника записей поврежденного SAP. Так как RIP использует счетчик переходов в сетевом пути, определяя источник, или происхождение должно быть довольно простым. Устранение проблем этим способом предполагает, что поврежденная известность должна генерироваться во время временного окна бездействия. Так как Повреждение IPX SAP происходит из-за аппаратных средств, проблема может не происходить часто и только происходить наугад периоды времени. Без поврежденных SAP, в настоящее время генерируемых в сеть, не будет никакого способа определить источник. Все поврежденные SAP всунули таблицу EIGRP, уйдет, как только удален EIGRP.

  2. Найдите общий источник или происхождение поврежденных SAP. Если там общий источник к SAP, может быть просто изолировать проблему и не иметь для выполнения как трудоемкое устранение проблем как в шаге 1.

    Все поврежденные SAP вызываются неисправным оборудованием где-нибудь в сети. Это включает любой маршрутизатор, коммутаторы L3, серверы рабочий IPX (не только Серверы Novell), и рабочие станции рабочий IPX. До настоящего времени Cisco никогда не имел проблемы программного обеспечения IOS, способствуют поврежденному IPX, SAP.

  3. Обойти поврежденный IPX SAP сетевое подключение воздействия, настройте фильтры IPX включая фильтры GNS, фильтры GGS, и SAP фильтры для прохождения только допустимых серверов в сети. Кроме того, добавление команды ipx sap follow-route-path минимизирует количество поврежденных SAP. Это вызвано тем, что то, когда команда ipx sap follow-route-path используется, маршрутизатор экранирует отдельные сервисы (SAP) в обновлениях SAP. Маршрутизатор посмотрел на номер сети назначения каждой записи SAP. Если интерфейс получения является одним из лучших интерфейсов для достижения сети назначения SAP, та запись SAP принята. В противном случае от записи SAP сбрасывают. Если маршрутизатор получает поврежденные SAP, вероятно, что маршрут может быть поврежден также.

Пример практического применения #10: Команда show IPX servers unsorted может показывать неупорядоченный список серверов

В определенных случаях, когда IPX Циклический выбор GNS настроен, маршрутизатор может испытать проблему, которая может заставить сервис низкого значения метрики быть перемещенным в таблицу вне группы наименьшей метрики сервисов. Это заставит таблицу SAP казаться неисправной. Это - известное поведение, и любой побочный эффект этого поведения может быть решен при помощи фильтров исходящих данные GNS, чтобы только позволить определенным серверам отвечать на GNS.

Если вы испытываете эти проблемы, просматриваете придерживающуюся ошибку в программном обеспечении и обновление к версии программного обеспечения, которая не испытывает эти проблемы.

CSCds54733 - show ipx servers несортированный Выход Не в порядке

Выходные данные команды show ipx server unsorted отображают таблицу SAP, которая не является в порядке. В то время как таблица находится в этом состоянии, GNS, ответы SAP могут не предоставить самый близкий сервис, как они должны. misordered результаты таблицы включения циклического выбора GNS. Как обходной путь, отключите циклический выбор GNS путем выдачи команды no ipx gns-round-robin.

Примеры внедрения Novell 5.X IP

Примеры практического применения 1: Конфигурация основного маршрутизатора Cisco, необходимая клиентам для входа в IP-сеть Novell за пределами сети

По умолчанию IP - клиенты Novell обнаруживают IP-сервисы через групповую адресацию. Пока другой метод не будет настроен, IP - клиенты попытаются обнаружить сервер Протоколом обнаружения сервисов (SLP), который использует IGMP (групповая адресация). По умолчанию Маршрутизаторы IOS не передадут пакеты групповой адресации.

Основное решение для маршрутизатора должно включить команду ip multicast-routing глобально и включить команду ip pim dense-mode под каждой соответствующей виртуальной локальной сетью (VLAN) или физическим интерфейсом.

Пример конфигурации:

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#

Существует два других метода, которыми клиентские рабочие станции могут обратиться к ресурсам Novell 5.0 по границам сети без потребности позволить mutlicast-направить.

Конфигурация Novell #1 (Documenet Novell: 2944038)

Добавьте имя сервера и Записи IP-адреса в Файле NWHost на рабочей станции. ФАЙЛ NWHOST расположен на рабочей станции в каталоге Novell\Client32 на Win95 и рабочих станциях Win98. Это имеет выборки, которых просто придерживаться.

На Рабочей станции NT, вместо NWHost, клиент использует файл HOST TCP/IP стандартного файла узла TCP/IP MicroSoft. Отредактируйте файл HOST для добавления имени сервера и адреса. Путем к этому файлу является Winnt/System32/Драйверы/И т.д./Хосты.

Конфигурация Novell #2 (из документа 2944038 Novell)

SLPDA.NLM загрузки на сервере NetWare 5. Это определяет сервер как Агента каталога. Добавьте IP-адрес сервера, выполняющего SLPDA.NLM под свойствами клиента, Вкладки Места предоставления услуг, списка Агента каталога. Щелкните по коробке рядом с коробкой Агента каталога, маркированной "Статичный". С определенным статическим агентом каталога клиент не передаст в многоадресном режиме для агента каталога, но передаст индивидуальную рассылку агенту указанного каталога.

Для обзора SLP (Протокол обнаружения сервисов) и обсуждение Агентов каталога, посмотрите tid 2943614 в support.novell.com

Примеры практического применения 2: Включение групповой адресации по IP в рабочей сети приводит к отказу существующих сетей IPX

Сети могут experiennce внезапная и полная потеря подключения IPX для клиентского компьютера.

Это может произойти, потому что программное обеспечение Novell Netware Client 3.x предпочтет IP для Протокола сетевого уровня по IPX по умолчанию. Поэтому, если Novell 5. X только IP сервер, не настроенный правильно для входа в систему Операционной системы Novell NetWare и групповой IP-адресации в сети, включен, все клиентские компьютеры предпочтут соединение с Novell 5. X-сервер. Если Novell 5. X-сервер правильно не знает о ресурсах существующей сети, клиенты не будут в состоянии получить доступ к существующим ресурсам.

Для решения этого вопроса настройте Маршрутизацию групповой IP-адресации, чтобы исключить SLP или настроить Операционную систему Novell NetWare 5. X-серверы правильно.

Примеры практического применения #3: Почему Novell IP не работает через маршрутизатор Cisco с запущенным NAT?

Реализации NAT преобразовывают IP-адреса в заголовках пакета, и специальные условия ищут блок данных пакета и преобразовывают ссылки встроенных IP - адресов. Однако текущее программное обеспечение Cisco NAT не преобразовывает, встроил ссылки IP Novell для NDS или SLP в блоках данных пакета IP. В результате устройства в открытой сети попытаются связаться с ресурсами через непреобразованные частные адреса. Так как открытые сети не будут в состоянии к частным сетям, связи прервутся. Альтернативное решение для создания IP - подключений Novell через NAT должно использовать решение для VPN.

Для получения дополнительной информации посмотрите TID 2948010 в support.novell.com

Примеры практического применения 4: IP-регистрация Slow Novell

Медленное Novell устранение проблем входа в систему IP совпадает с Медленным входом в сеть IPX. Посмотрите Пример практического применения #8 под Примерами практического применения IPX Novell.

Общие вопросы конфигурации

Почему не удается настроить более 200 сетей IPX на маршрутизаторе?

Маршрутизатор Cisco может обработать больше чем 200 Ipx network в своей таблице маршрутизации, например, но вы не можете настроить больше чем 200 интерфейсов IPX на маршрутизаторе (использующий команду ipx network). Предел был только недавно достигнут теперь, когда у нас есть Коммутаторы 3 уровня, которые могут предоставить это количество интерфейсов. Это количество является hardcoded в IOS и не будет, вероятно, изменено. Коммутаторы 3 уровня могут внедрить больше чем 200 интерфейсов, потому что большинство функций коммутации обрабатывается некоторыми специализированными ASIC, которые разгружают главный процессор, насколько затронут IP - трафик. Интерфейсы IPX требуют намного большего количества Питания ЦПУ для обработки процесса RIP/SAP, и даже бывший рядом с ограничением по току может быть важным.

Почему я не могу проверить доступность Novell Host с моего маршрутизатора?

Маршрутизатор Cisco внедряет два типа эхо-запроса IPX:

  • Cisco IPX ping: это - частный протокол Cisco по умолчанию, который будет использовать маршрутизатор, когда вы попытаетесь пропинговать адрес IPX.

  • Эхо - запрос по протоколу IPX Novell: это - единственное, которое могут выполнить Серверы Novell, и это не совместимо с реализацией Cisco.

Можно использовать Cisco IPX ping для тестирования подключения между устройствами Сisco, настроенными для IPX. Если вы хотите пропинговать Сервер Novell, необходимо настроить маршрутизатор для передачи Эхо - запрос по протоколу IPX Novell, с помощью ipx ping-default novell команды глобальной кофигурации

Можно также выполнить команду extended ipx ping и выбрать стандартный параметр эха Novell.

Серверу Novell нужно было загрузить респондента для ответа на эхо Novell (эхо-запрос). Для прозванивания от Сервера Novell нужно также загрузить IPXPING.NLM на сервере. Мы заметили, в рабочем тестировании, что:

  • Сетевое обеспечение 3.x серверы, сетевое обеспечение 4.0x серверы, клиенты NETX, VLM - клиенты (v.1.20a), и Клиент MS для сетевого обеспечения НЕ отвечает на эхо-запросы Novell.

  • Сетевое обеспечение 4.10 сервера, v3 x MPR сетевого обеспечения, Клиент 32, и DOS/Win95 Клиента MS действительно отвечает на эхо-запросы Novell.

Конечно, эхо-запрос может также отказать по другим причинам, чем несоответствие в типе протокола эхо-запроса. Успех эхо-запроса также зависит от таблицы маршрутизации IPX (должен быть маршрут к адресу назначения (DA)), целостность соединения (потери пакета), фильтрование, и т.д. Рекомендации для запоминания при использовании эхо-запроса:

  • Когда прозванивание сервера возможно, гарантируйте, что были решены все проблемы подключения IPX.

  • Когда эхо-запрос отказывает на вершине всех проблем возможного подключения (от сложной проблемы Ipx - маршрутизации до проблемы функциональности ссылки), помните, что может быть простая неполадка с сервером, не внедряющим функциональность IPX ping. Это означает, что к сожалению часто нет ничего особенного для заключения, когда отказывает эхо-запрос IPX к серверу.

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

В данном примере у нас есть два маршрутизатора, непосредственно связанные через их Интерфейс Ethernet на IPX network BABA. От router1, если мы пропинговываем интерфейс router2, маршрутизатор сначала использует по умолчанию, частный протокол 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

Мы можем вызвать протокол Запроса ping сервера Novell с помощью расширенной команды 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

Другая возможность состоит в том, чтобы заставить протокол эхо-запроса по умолчанию быть одной Novell:

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#

Когда вы пытаетесь пропинговать хост протокол рабочего Novell, изменение типа эхо-запроса к Novell только важно. Быть сбоем для прозванивания хоста Novell не обязательно означает, что подключение к этому хосту сломано (не, хосты всего Novell отвечают на Запрос ping сервера Novell). Прозванивание маршрутизатора является хорошим способом протестировать подключение IPX к нему.

Почему я не могу настроить маршрутизацию IPX?

У вас должно быть корректное программное обеспечение IOS для настройки Ipx - маршрутизации.

Очень часто маршрутизатор отправлен с программным обеспечением по умолчанию во Флэше, и это программное обеспечение по умолчанию может не поддержать IPX (даже при оплате лицензии за поддержку IPX). Тогда необходимо обновить маршрутизатор к программному обеспечению, для которого вам лицензируют. Поддержка IPX является обычно частью настольного набора функций, который часто определяется с "d" в имени образа:

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

Посмотрите этот настольный набор функций как минимальный набор функций включая поддержку IPX. Набор функций "предприятия" (определенный с "j" вместо "d" выше), который включает настольный набор функций, конечно, также поддержит IPX. Проверьте Комментарии к выпуску IOS для точных функций, доступных в IOS, который вы выполняете.

Что представляет собой команда ipx pad-process-switched-packets?

Эта команда используется для управления, дополнены ли пакеты с нечетным значением длины, так чтобы быть переданными как пакеты равной длины на интерфейсе. Команда ipx pad-process-switched-packets влияет на пакеты с механизмом обработки process-switched только, таким образом, необходимо отключить быструю коммутацию, прежде чем команда ipx pad-process-switched-packets будет иметь любой эффект. Команда была необходима в связи с к некоторым хостам IPX, которые отклонили Пакеты Ethernet, которые не дополнены. Определенная, некоторый топология может привести к таким пакетам, передаваемым на удаленную Сеть Ethernet. При особых условиях, дополняющих на промежуточных средствах, может использоваться в качестве временного обходной пути для этой проблемы.

Эта команда включена по умолчанию. Однако пакеты IPX SAID спецификации Драйвера Ethernet Novell должны быть "evenized" передающим устройством. Это происходит из-за обычных устройств, которые имели проблемы с пакетами с нечетным значением длины и не должны быть проблемой в эти дни, но требование сохраняется.

Устройство не после стандартного требования Novell могло бы произвести пакеты с нечетным значением длины. Избыточные пакеты могли бы также закончиться при маршрутизации от одного IPX encapsulation до другого другого IPX encapsulation. Некоторые инкапсуляции имеют другую длину, и изменение в инкапсуляции может произвести пакет с нечетным значением длины.

Поддерживают ли маршрутизаторы Cisco возможность расширения пакета IPX, чтобы изменить загрузку сети с помощью передачи пакетов обновления RIP/SAP большего размера?

Это - поддерживаемая характеристика. По умолчанию Пакет RIP IPX содержит 25 маршрутов, и Пакет IPX SAP содержит 7, SAP. Количество маршрутов и SAP на RIP, и пакет SAP может быть изменен путем изменения соответствующего размера обновленного пакета. См. документацию относительно ipx sap-max-packetsize и ipx rip-max-packetsize в Справочнике по командам IOS для получения дополнительной информации.

Несмотря на Настройку все Серверы Novell и Маршрутизаторы для IP Только, я Все еще Вижу Кадры IPX на Отслеживании средств прослушивания. В чем причина?

Клиентское программное обеспечение Novell 3.x по умолчанию передаст кадры для IP и IPX на загрузку в попытке войти к Сети Novell независимо от конфигурации сети. Решение состоит в том, чтобы вручную отключить все протоколы IPX на клиентских компьютерах.

Почему включение IPX EIGRP на интерфейсе VLAN отключает IPX MLS для этого соответствующего интерфейса?

MLS IPX отключен с IPX EIGRP начиная с передачи между RIP, и Домены eigrp требует трансляций определенных полей в блоке данных (Transmit Control) маршрутизированных пакетов. Интерфейс Маршрутизатора IPX, когда включено для RIP/NLSP, будет иметь максимальное количество транзитных участков 16. Когда маршрутизатор находится на границе NLSP/RIP и домена Маршрутизации EIGRP, интерфейс настроен и с EIGRP и с NLSP/RIP. Необходимо удалить поддержку MLS того интерфейса, если максимальный переход настроен, чтобы быть 16 или меньше, потому что в этом случае, Контроль за Transmit Control (TC) значение будет преобразовано вместо того, чтобы быть инкрементно увеличенным 1, когда пакет пересечет от одного домена маршрутизации до другого. MLS-SE не ознакамливается об используемом протоколе маршрутизации, и программное обеспечение MLS не будет в состоянии переписать поле Control (TC) Transmit Control должным образом.

"Mls IPX будет отключен на vlan <vlan_id> из-за сообщения" использования eigrp, появляется, только если maximum hops IPX установлен в 16, когда настроен EIGRP IPX. Для всех других значений (17-254) не отображено никакое такое предупреждающее сообщение. MLS IPX хорошо работает для значения перехода 16, хотя существует предупреждение.

Командой для увеличения Контроля за Transmit Control (TC) значение выше 16 является MAXIMUM HOPS IPX <max_hops значение>

Нет никакого определенного недостатка/преимущества в увеличении счетчика переходов.

Стандартные неполадки соединения

Понятие процесса входа для клиента IPX

Как клиент соединяется с сетью Novell?

Если клиент должен определить местоположение сервера в определенном дереве самого близкого сервера каталогов (NDS), клиент передаст Тип SAP 3 для типа сервиса 0278 запросов Get Nearest Directory Service (GNDS). Любой сервер NDS (настроенный для ответа на GNS и запросы GNDS) расположенный на том же маршрутизированном сегменте как клиент ответит названием дерева NDS, что это принадлежит и его внутренний номер IPX. Клиент проверит имя дерева в ответе против имени дерева, которого это требует (согласно тому, что клиент установил как его Предпочтительное Дерево). Если это будет корректное дерево, то клиент передаст запрос RIP о маршруте к внутреннему номеру IPX, предоставленному в ответе. Сервер ответит, говоря, что это - маршрут к тому внутреннему номеру IPX. Клиент одноадресно передаст запрос установить соединение с тем сервером и начать процесс проверки подлинности. Если сервер на локальном сегменте не будет сервером NDS, то это не ответит на начальный запрос GNDS, потому что это может только предоставить Тип сервиса 0004, не 0278. Любые серверы NDS, которые не держат копии NDS, не ответят на запрос. Если ни один из ответов не будет содержать корректное название дерева NDS, то клиент выполнит Тип SAP 1 для типа сервиса 0278 (GGDS) запрос. Все Серверы NDS, расположенные на том же маршрутизированном сегменте, ответят списком сервисов, независимо от ОТВЕТА на GET Настройка сервера NEAREST. Клиент считает все ответы на поиск GGDS корректного названия Дерева NDS. Как только это находит запись для корректного дерева, это попытается установить соединение с тем сервером. Клиент попытается установить соединение с первой записью, которая содержит корректное Имя дерева, не самое близкое начиная с этого общий запрос службы, не самый близкий сервисный запрос. Если клиент запросит Сервер Bindery (или у клиента есть только набор Предпочитаемого сервера в его Конфигурации клиента), то тот же процесс будет иметь место, только тип сервиса запроса будет 0004 вместо 0278. Кроме того, Если сервер будет иметь ОТВЕТ на GET НАСТРОЙКА СЕРВЕРА NEAREST к ВЫКЛЮЧЕНО тогда, то сервер не ответит на GNS (тип сервиса 0004) или GNDS (тип сервиса 0278) запросы

FlowChart для входа в систему клиента novell

NDS (Novell 4.11)

  1. На загрузку клиент отправит запрос GNDS. Если клиент будет настроен к автоматическому опознаванию тип фрейма, то клиент передаст четыре GNDSs, один для каждого типа фрейма.

  2. Все локальные серверы (или маршрутизаторы Cisco, если бессерверный сегмент) ответят с Ответом GNDS.

    Если несколька адресов серверов или маршрутизаторы ответят на запрос GNDS, клиент будет использовать первый Ответ GNDS. Ответ GNDS будет содержать внутренний сетевой номер соответствующего сервера и имя дерева.

  3. Если Ответ GNDS будет иметь корректное дерево, то клиент выполнит запрос RIP о внутреннем номере IPX, предоставленном в Ответе GNDS.

Как маршрутизатор Cisco выбирает сервер для включения в GetNearestServer (GNS) ответа?

Команда show ipx server unsorted покажет в первой позиции название сервера, который будет использоваться для ответа на следующий запрос GNS. В выпуске ПО 9.21 или позже, используйте команду ipx gns-round-robin , чтобы позволить балансировать нагрузку ответов на запросы GNS среди Сервисов равной метрики. Путем серверы упорядочены, описан в следующем документе: Как классифицируются серверы?

Какова Последовательность подключений клиента С и/или Без Предпочитаемого сервера?

Для последовательности подключений без предпочитаемого сервера выполните следующие шаги:

  1. Найдите сервис (запрос GNS и ответ)

  2. Найдите маршрут к сервису (запрос RIP и ответ)

  3. Сделайте соединение с Самым близким сервером

  4. Получите сведения о файловом сервере

  5. Выполните согласование о размере буфера

  6. Очистите предыдущее подключение

  7. Получите дату и времю файлового сервера

Для последовательности подключений с предпочитаемым сервером выполните следующие шаги:

  1. Найдите сервис (запрос GNS и ответ)

  2. Найдите маршрут к сервису (запрос RIP и ответ)

  3. Сделайте соединение с Самым близким сервером

  4. Получите сведения о файловом сервере

  5. Выполните согласование о размере буфера

  6. Считайте значение характеристики "предпочитаемого сервера", сохраненного в Самом близком сервере

  7. Найдите маршрут к предпочитаемому серверу

  8. Создайте соединение с предпочитаемым сервером

  9. Получите информацию файлового сервера предпочитаемого сервера

  10. Выполните согласование о размере буфера

  11. Очистите соединение услуг с Самым близким сервером

  12. Очистите предыдущее подключение с предпочитаемым сервером

  13. Получите дату и времю сервера навигации по файлам

Это все еще требует запроса/ответа GNS от самого близкого сервера, но это не завершает последовательность подключений с самым близким сервером. Это использует самый близкий сервер, чтобы изучить, как добраться до предпочитаемого сервера. Как только маршрут к предпочитаемому серверу изучен, это уничтожает соединение с самым близким сервером и повторяет последовательность подключений с предпочитаемым сервером.

Как вы фильтруете ответы на запросы GGS или GNS?

Полезно управлять механизмом, который маршрутизатор использует для ответа на клиентский запрос GNS. Для ответа на клиент IOS выбирает один из серверов, известных маршрутизатором. IOS предоставляет способ предотвратить некоторые серверы в этом списке от того, чтобы быть используемым, с помощью команды IOS:

ipx output-gns-filter {access-list-number|name}

Эта команда, когда-то применился к интерфейсу, гарантирует, что маршрутизатор только предоставляет клиентам самый близкий сервер, совпадающий с указанным access-list.

Подключение клиентов к сети

Почему я не могу подключить свой клиент, когда непосредственно подключено с коммутатором?

Проблемы, которые могут следовать из этой конфигурации, полностью описаны в следующем документе Использование portfast и Других Команд для Решения проблемы Задержек Подключения при запуске рабочей станции.

В основном, если вам подключили ПК непосредственно к порту на Коммутаторе Catalyst, удостоверьтесь, что вам включили характеристику PortFast. Для установки его с CatOS используйте команду:

set spantree portfast enable <module/port>

Кроме того, если у вас есть транкинг и канализирование работоспособных модулей (например, WS-X5225R на Catalyst 5000 и всем Catalyst, 6000 модулей соединяют магистралью/направляют способный), необходимо удостовериться, что выключили их вручную, с помощью следующих команд:

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

От программного обеспечения 5.2 на семействе Catalyst 4000/5000 и от 5.4 на Семействе Catalyst 6000, эти три команды могут быть связаны в одиночной макрокоманде:


<module/port> set port host

Есть ли какие-либо проблемы с сервером или лицензией, которые будут влиять на соединение?

Первая вещь, которую делает соединяющийся Клиент novell, состоит в том, чтобы передать GNS (получите самый близкий сервер), запрос. Этому запросу отвечают сервер или маршрутизатор. Клиент тогда пытается подключить использование сервера, заданного в ответе. Существует две общих проблемы, которые могут привести к сбою соединения:

  • Сервер, с которым связываются, не отвечает на GNS. Если внутренний сетевой номер самого близкого сервера не 0000.0000.0001, то это - вероятно, NT - сервер, который проигнорирует GNS.

  • Сервер, с которым связываются, испытывает нехватку лицензий. Только ограниченное число клиентов могло соединиться, дополнительные попытки отказывают.

В обоих случаях, если маршрутизатор Cisco включен, проверьте то, какой сервер дан клиенту, использующему команду show ipx server unsort . Можно тогда использовать команду ipx output-gns-filter для фильтрования серверов, которые не должны быть даны как ответ.

Будут проблемы соединения для дублирования IPX или MAC-адресов?

Обычно, все адреса IPX в сети должны быть другими, поскольку MAC-адрес является частью их. Однако существует много случаев, где пользователь может жесткий код, MAC-адрес, В этом случае, обращает пристальное внимание на уникальность этого адреса. Кроме того, бояться очень двойной адрес IPX при вырезании и вставлении конфигурации от одного маршрутизатора до другого, например. Это чрезвычайно важно для Интерфейсов WAN, которые используют MAC-адрес, определенный в команде маршрутизации IPX. В следующем примере были дублированы маршрутизатор A и конфигурации B. Администратор сети изменил IPX network на каждом интерфейсы, но забыл обновлять линию ipx - маршрутизации, которая является тем же в обеих конфигурациях.

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

Последовательный интерфейс не имеет своего собственного MAC-адреса. Маршрутизатор будет использовать MAC-адрес, заданный в команде маршрутизации IPX для построения адреса IPX его последовательных интерфейсов. В этом случае маршрутизатор A и маршрутизатор B будут иметь тот же самый AAA.0000.0C14.11E1 адреса IPX. Конечно, существует много других способов попасть в проблему дублирования адресов. TAC видит, что много проблем с подключением, вызванных адресацией с дублированием, так очень осторожно при присвоении IPX network или MAC-адреса.

На данном соединении:

  • Все серверы и маршрутизаторы должны быть настроены с уникальными номерами сети IPX для данной инкапсуляции.

  • Все MAC-адреса должны быть уникальными.

Просмотр серверов и сервисов

Почему я не могу обратиться к определенному серверу/Сервису?

Если клиент пытается обратиться к серверу через маршрутизатор Cisco, используйте команду show ipx server на маршрутизаторе:

Если сервер/сервис, который вы ищете, среди перечисленных, когда вы выполняете команду show ipx server, и нет никакого access-list в конфигурации, которая сломала бы подключение, то маршрутизатор наиболее вероятно не причина проблемы. Если вы не видите сервис на маршрутизаторе, удостоверьтесь, что IPX network сервера появляется в таблице маршрутизации. Выполните команду show ipx route для показа таблицы маршрутизации IPX. Если маршрутизатор не будет иметь маршрута к соответствующей сети, сервис не будет объявлен.

Если сервер непосредственно присоединен к маршрутизатору, но все еще не появляется, когда show ipx server выполнен, уверены, что вы настроили того же IPX network с тем же IPX encapsulation на сервере и на маршрутизаторе.

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

В данном примере, быть уверенным, что Сервер Novell настроен с инкапсуляцией SNAP и что адресом IPX является BABE. Если инкапсуляция будет неправильной, то от пакетов, переданных сервером, сбросит маршрутизатор. Если Ipx network не совпадет, то сервер отобразит сообщение об ошибках, указывающее на то несоответствие.

На маршрутизаторе команда show ipx traffic даст некоторые полезные сведения, к сожалению для целого устройства, не для определенного интерфейса. Обратите внимание на поле "ошибки форматирования". Это будет инкрементно увеличено каждый раз, когда маршрутизатор получает пакет с неправильной инкапсуляцией. Если этот счетчик увеличится, то у вас, очень вероятно, будет ошибка инкапсуляции.

Команда show ipx interface [<interface>] дает отнесенные подробные данные IPX для определенного интерфейса. Это суммирует тип инкапсуляции, адрес IPX и access-list, настроенный для интерфейса. При устранении проблем видимости сервера/сервиса полезно проверить, что определенный интерфейс получает RIP и обновления SAP от соседнего узла. Это - возможное использование этой команды.

Почему я не могу обратиться к серверу IPX через RConsole?

В то время как RIP и EIGRP переносят информацию о сети, служебную информацию переносов SAP. Каждый Пакет IPX SAP, генерируемый маршрутизатором Cisco, может перенести до семи 64 байтов записи SAP плюс 32 байта служебной информации IPX (для в общей сложности 480 байтов), в дополнение к служебной информации средств инкапсуляции. Когда их переносят в пакетах EIGRP, Пакеты IPX SAP состоят из стандартного Заголовка EIGRP со значением Opcode 6, придерживавшийся стандартными полезными данными стандартного пакета IPX SAP без исходного заголовка IPX.

В типичном обмене пакетами SAP клиент Netware передаст запрос SAP для определения местоположения сервера каталогов, как обозначено полем типа сервера SAP (см. Список Сервиса SAP Novell). Пакеты ответа SAP содержат адрес внутреннего IPX серверов то предложение сервисы каталогов. Клиент тогда передает широковещание RIP для определения местоположения пути к адресу внутреннего IPX сервера.

Следующие шаги устанавливают Подключение через RConsole:

  1. Клиент RConsole передает запрос SAP, ища сервер. В частности RConsole отсылает Запрос служб общего назначения для типа 0x107 серверы. Маршрутизатору Cisco нужно разрешить объявить о типе 0x107 серверы для RConsole для работы на ПК. Клиент отправляет поиску сервера запрос SAP даже при том, что он в настоящее время зарегистрирован в сервер.

    • Если существует сервер на сегменте, он отвечает на клиент.

    • Если клиенты IPX находятся на бессерверном сегменте, маршрутизатор выбирает первую запись SAP в своем несортированном списке для ответа на запрос GNS от клиентов IPX. В некоторых случаях первая запись SAP в маршрутизаторе является неправильным сервером. Выполните команду show ipx server unsorted для получения этого. Как обходной путь, создайте список доступа SAP, чтобы заблокировать тот сервер и применить его как фильтр GNS.

  2. Клиент отправляет запрос RIP для адреса внутреннего IPX первого сервера, который ответил.

  3. Как только клиент изучает самый быстрый способ добраться до сервера, он передает пакет запроса SPX - подключения к нему.

Если вы неспособны сделать Подключение через RConsole к определенному Серверу Netware, используйте следующие шаги, чтобы определить, является ли причина сетевой проблемой или неполадкой сервера:

  • Можно ли видеть какие-либо серверы? Некоторые серверы? Серверы, которые локальны? Серверы, которые являются по глобальной сети (WAN)?

  • На другой трафик IPX влияют?

  • На что таблица сервера IPX похожа в самом близком маршрутизаторе?

  • Вы видите ID внутренней сети сервера в таблице маршрутизации IPX маршрутизатора?

  • Укажите на IPX network, что вы происходите из и сервер, в который вы пробуете к RConsole:

    • show version

    • show run

    • show ipx server

    • show ipx route

  • Вы используете сетевое обеспечение 4.11 или сетевое обеспечение 5? Это - IP Novell? Можно ли пропинговать сетевое обеспечение 5 серверов? Другими словами, попытайтесь соединиться IP по сравнению с по имени. Если так, DNS не решен.

В некоторых случаях поврежденная база данных на одном сервере вызывает проблемы SPX - подключения, особенно поскольку поврежденная база данных передана другим серверам. Часто, можно решить эту проблему путем выполнения служебной программы восстановления ДВУХСТОРОННЕЙ ДИСКЕТЫ. Однако, если восстановление ДВУХСТОРОННЕЙ ДИСКЕТЫ не в состоянии восстанавливать базу данных, перезагрузка сервера может требоваться. Если вы не можете сделать Подключение через RConsole с помощью внутреннего сетевого номера, проблема с Сервером Netware.

Novell также публикует практические советы онлайн в базе знаний. Следующий совет может быть полезен решению проблем RConsole с точки зрения серверов IPX. Этот совет предоставлен как ресурс для Клиентов Cisco.

"RCONSOLE,-4.10-112 SPX Устанавливают Соединение, был не в состоянии устанавливать соединение с необходимым сервером".

  1. REMOTE.NLM загружен на сервере? RSPX.NLM загружен?

  2. Вы проверили ДВУХСТОРОННЮЮ ДИСКЕТУ и удостоверились, что это здорово и что все синхронизируется?

  3. Ошибки могут быть вызваны маршрутизатором, который отфильтровывает RConsole SAP. Если RConsole должен работать должным образом, тип SAP 0107 является RConsole SAP и не должен быть отфильтрован.

  4. Неисправная плата NIC может мешать клиенту устанавливать SPX - подключение.

  5. Сделайте абсолютными определенный, некоторый, что все Номера сети IPX уникальны. Это - причина количества один, почему RConsole отказывает, но иногда самое твердое для устранения проблем.

  6. Вызовите тип фрейма у клиента вместо того, чтобы Автоматически обнаружить тип фрейма.

Обходной путь

В экране RConsole нажмите INS и введите внутренний сетевой номер IPX конечного сервера. Внутренний сетевой номер IPX сервера может быть найден путем ввода CONFIG в консоли сервера. Вручную введение внутреннего сетевого номера IPX позволяет RConsole работать, это могло бы означать, что была превышена таблица сокета IPX на том сервере. Увеличьте максимальный размер таблицы сокета IPX: INETCFG-> Протоколы-> IPX - Параметры> IPX/SPX-> Максимальный размер таблицы сокета IPX. По умолчанию является 1200. Увеличьте эту стоимость к 2400 первоначально. Сервер должен быть перезагружен для сброса этого размера таблицы.

Почему я не Вижу Все свои Серверы В Топологии звезды?

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

В вышеупомянутой схеме нам подключили маршрутизатор концентратора через многоадресный интерфейс (точка-многие точки) нескольким другим. Это - типичный концентратор Frame Relay и лучевые сети. Все маршрутизаторы связаны в том же IPX Network A. Маршрутизаторы на конце луча объявляют свой X и y локальной сети к концентратору, но вы не видите сеть Y в таблице маршрутизации Маршрутизатора X (и так же вы не видите X в таблице маршрутизатора Y). Эта проблема непосредственно отнесена к разделению горизонта. RIP не объявляет маршрут на интерфейсе, где это училось о нем. В основном маршрутизатор концентратора учился о Сети X на ее serial0 Интерфейса WAN, связанном с сетью A, и это никогда не будет давать объявление X назад на serial0. Маршрутизатор Y, также связанный через serial0 с маршрутизатором концентратора, никогда не будет слышать о сети X.

Спецификации Novell не позволяют разделению горизонта быть отключенным для RIP, таким образом, существует два основных обходных решения, доступные с маршрутизаторами Cisco:

  • Замените многоадресный интерфейс (точка-многие точки) несколькими интерфейсами точка-точка. Это может быть сделано путем создания нескольких подчиненных интерфейсов на serial0 маршрутизатора концентратора. Проблема состоит в том, что необходимо назначить другой номер сети для каждого созданного канала типа точка-точка, что означает изменение в схеме адресации и увеличении размера таблицы маршрутизации.

  • RIP замены с EIGRP IPX. Этот последний протокол маршрутизации позволяет удаление разделения горизонта (использующий no ipx split-horizon eigrp команды ) и выполняет лучше на соединениях медленной глобальной сети (WAN) (инкрементные обновления, и т.д.). Единственный недостаток - то, что всеми маршрутизаторами должен быть Cisco на глобальной сети (WAN).

Почему NetBios По IPX Не Проходящий через Мой Маршрутизатор?

Это происходит, потому что NetBios по IPX полагается на тип широковещания 20 пакетов IPX, которые не должны быть переданы маршрутизатором. Для передавания этих определенных пакетов маршрутизатором, настройте команду ipx type-20-propagation на каждом интерфейсе, который распространится Трафик NetBIOS:

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

Конфигурация маршрутизатора 1 Конфигурация второго маршрутизатора
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

 

Эта конфигурация только включает соответствующую часть IPX. В данном примере хост A и хост B выполняют NetBios по IPX. Маршрутизатор 1 и Маршрутизатор 2 имеют очень базовая конфигурация IPX. Команда ipx type-20-propagation была добавлена на каждом интерфейсе, который, как предполагается, передает NetBios по трафику IPX. В этом расценивает, интерфейс "Ethernet" 1 от Маршрутизатора 1 не требует его, поскольку нет никакого хоста Netbios на Сегменте Ethernet.

Обратите внимание на то, что команда распространения type-20, невзирая на то, что обязательный, будет иметь влияние на производительность в сети.

Проблемы с производительностью

Использование памяти для маршрутов RIP и для протоколов SAP

IOS 10.0, 10.2 10.3 и выше
Маршрут 180 байтов для каждого маршрута, добавляют 50 байтов для каждого дополнительного пути если максимальный путь> 1 160 байтов для каждого маршрута, добавляют 70 байтов для каждого добавления если максимальный путь> 1
SAP 200 байтов для каждого SAP, добавляют 4030 байтов для каждого Типа SAP 200 байтов для каждого SAP, добавляют 4030 байтов для каждого Типа SAP и добавляют 50 байтов для каждого дополнительного пути

Балансировка нагрузки IPX в маршрутизаторах Cisco

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

Если Маршрутизатор Z будет настроен с командой ipx maximum-paths 2 и Маршрутизаторами A, и B получают вас к той же сети назначения в том же количестве переходов, то Маршрутизатор Z тогда передаст каждый пакет назначению к Маршрутизатору A и B в порядке круговой очереди, и с медленной коммутацией и с быстрой коммутацией.

Будьте осторожны, что в данном случае, если вы балансируете нагрузку по путям неравной пропускной способности и у вас есть включенный pburst, неисправные пакеты могут закончиться. Более новые Версии NetWare должны обработать это лучше, чем более старые Версии NetWare, но стоит попытаться удалить распределение нагрузки или pburst при устранении проблем проблемы производительности в этой конфигурации. Начиная с IOS 11.1 можно также включить распределение нагрузки по каждому хосту с помощью команды ipx per-host-load-share . Распределение нагрузки по каждому хосту передает трафик по множественному, равноценным путям при гарантии, что пакеты для данного конечного хоста всегда берут тот же путь.

Низкая производительность, если включена передача type-20

Вспомогательные функции IP на маршрутизаторе не рекомендуются в сети, но команда ipx type-20-propagation также не рекомендуется, насколько трафик затронут. С командой IP - помощника маршрутизатор берет транслируемый пакет и превращает его в одноадресный пакет (или адресная трансляция) для передачи его на следующем сегменте. С командой ipx type-20-propagation маршрутизатор берет широковещание и вперед это, как передано. Пакет type-20 содержит список всех сетей, уже прошедших через, и маршрутизатор никогда не будет передавать его назад в сети, появляющейся в этом списке.

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

Давайте предполагать, что команда ipx type-20-propagation включена на каждом интерфейсе, с тремя сегментами между маршрутизатором 1 и 2 (обычная конфигурация с Catalyst 5000 и RSM, связанным вместе trunkof 20 VLAN, например).

  1. PC1 выполняет широковещание type-20.

  2. Маршрутизатор 1 получает его, и вперед одна копия на каждом сегменте A B и C (с сегментом перечисляют D).

  3. Маршрутизатор 2 получает три копии, и вперед каждый из них (список сегмента является DA для первого DB для второго DC для третьего) к двум другим сегментам, делающим еще 6 копий пакета (DA является передачей к B и C, DB к A и C, DC к A и B).

  4. Маршрутизатор 1 получает эти шесть копий (DAB, DAC, DBA, DBC, DCA, DCB), и передайте всем им последнему сегменту, который не видел его.

  5. Маршрутизатор 1 получает эти шесть пакетов (DABC, DACB, DBAC, DBCA, DCAB, DCBA) и отбрасывает их всех, поскольку они все пересекли все сегменты.

С данным примером мы видим, что каждое широковещание будет генерировать еще 15 пакетов между этими двумя маршрутизаторами. С четырьмя ссылками (VLAN) между двумя маршрутизаторами у вас есть 64 пакета. С пятью ссылками между двумя маршрутизаторами у вас есть 325 пакетов и т.д. Поэтому использование этой команды вызовет увеличенное количество пакетов, которые могут замедлиться или завершить сеть.

Для улучшения ситуации используйте следующие команды:

Когда они настроены, мы удостоверяемся, что тип 20 входит на интерфейсе, который является основным маршрутом назад источнику. Если это не, мы отбрасываем пакет. Когда мы переходим, передают пакет, мы проверяем, не является ли сеть/интерфейс, к которой мы передаем его, маршрутом назад источнику этого типа 20 пакетов, или иначе мы отбрасываем его. Это в дополнение к восьми проверкам переходов петли, что спецификация маршрутизатора IPX призывает, чтобы мы сделали с 20-ми типа.

Настройка списка доступа

Фильтрация диапазона IPX-номеров сетей

Расширенный список доступа IPX позволяет вам фильтровать диапазон сетей. Например, у вас может быть большой IPX network. Весь Ipx network начинается с A43XXXXX и CBDXXXXX. Сети A43XXXXXX не должны переходить к некоторым маршрутизаторам, таким образом, я фильтровал каждое использование следующих команд:

interface Serial0



     ipx output-network-filter 805



     !



     access-list 805 deny  A43C0100



     access-list 805 deny  A43C0101



     access-list 805 deny  A43C0102



     .

     .

     .

Этот access-list продолжается для 120 линий. Как я могу фильтровать Ipx network, который начинается с A43?

Попытка с помощью следующей команды:

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

Убедитесь, включают линию для разрешения маршрутов, которые вы хотите. Любое ключевое слово будет представлять "все протоколы" и является обязательным аргументом. Фотошаблоны на том же принципе как маска подстановочного знака IP. Биты узла должны быть заданы, в противном случае у вас не будет опции маски. Можно использовать расширенный список доступа IPX во всем одинаковом способы, которыми можно использовать стандартную версию. Если вы будете использовать Протокол NetWare Link Services (NLSP) в качестве протокола маршрутизации, то необходимо будет использовать множественные области, таким образом, вы будете мочь фильтрации маршрута на границах области.

Отладка

При просмотре выходных данных debug ipx packet некоторые пакеты маркированы как "плохой Pkt. Почему эти пакеты помечены как "Bad Pkt"?"

Пример:

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

Это может произойти, потому что Сокет 455 является номером сокета NetBIOS, и адрес назначения (DA) MAC - уровня пакета передан. Этот пакет будет отброшен маршрутизатором по умолчанию, пока не будут настроены type-20-propogation ipx или ipx helper-address. См. документацию относительно включения type-20-propogation для получения дополнительной информации при передаче их NetBIOS по адресным трансляциям IPX.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 10564