Когда соединяются различные сетевые сегменты IPX, инструкции для маршрутизации пакетов между этими сегментами приходят из протокола IPX. IPX выполняет эти функции уровня 3 с помощью RIP, SAP и NLSP.
Если две рабочие станции находятся в одном сетевом сегменте, посылающая рабочая станция посылает пакеты прямо по физическому адресу рабочей станции назначения (т.е. по адресу MAC). Если две рабочие станции находятся в двух различных сетевых сегментах, то первая рабочая станция должна найти маршрутизатор в своем собственном сегменте, который знает, как переслать пакеты внешнему сегменту.
Чтобы найти этот крайне важный маршрутизатор, рабочая станция будет посылать широковещательный пакет RIP, запрашивающий самый быстрый маршрут к сегменту назначения. Маршрутизатор того же сегмента с самым коротким путем к сегменту назначения ответит на запрос. В пакете ответа маршрутизатор включит в заголовок IPX свой собственный сетевой и узловой адрес.
Очевидно, что если посылающим узлом является маршрутизатор, а не рабочая станция, то ему не нужно будет посылать широковещательное сообщение RIP, чтобы получить эту информацию. Вместо этого маршрутизатор берет информацию из внутренней таблицы маршрутизации.
Когда посылающая рабочая станция получит адрес маршрутизатора, она посылает пакеты рабочей станции назначения, помещая полный адрес IPX места назначения (т.е. сеть, узел и номер сокета) в поле места назначения заголовка IPX, как это было показано ранее в этой главе.
Затем посылающая рабочая станция помещает свой собственный полный адрес IPX в соответствующее поле источника заголовка IPX. Посылающая рабочая станция заполнит также все другие поля в заголовке. Например, она поместит адрес узла маршрутизатора, который ответил на запрос RIP в поле адреса места назначения заголовка MAC. Она поместит свой собственный адрес в поле адреса источника заголовка MAC.
Посылающая рабочая станция отправляет, наконец, пакет маршрутизатору, который должен теперь выполнить несколько задач. В первую очередь маршрутизатор просматривает поле контроля транспорта заголовка пакета IPX. Маршрутизатор RIP будет отбрасывать пакет, если это поле больше 16. Маршрутизатор NLSP будет отбрасывать полученный пакет, если это число больше, чем ограничение числа переходов.
После этого маршрутизатор проверяет поле типа пакета заголовка IPX. Если он видит в этом поле 20 (0x14), это указывает на пакет NetBIOS. Он должен также посмотреть поле контроля транспорта. Если это значение равно восьми или больше, маршрутизатор отбрасывает пакет, так как пакет NetBIOS ограничен восьмью переходами (или сетями).
Затем маршрутизатор сравнивает сетевой номер в пакете с сетевым номером сегмента, в который прибыл пакет. Если маршрутизатор обнаружит совпадение, то он отбрасывает пакет, чтобы избежать зацикливания. Если сетевой номер не совпадает, то он помещает сетевой адрес в следующее доступное поле сетевого номера. Он увеличивает поле контроля транспорта и посылает пакет всем напрямую соединенным сетевым сегментам, которые не присутствуют в полях сетевых номеров.
Теперь маршрутизатор проверяет поля адреса назначения, чтобы определить, как направить пакет. Если пакет адресован маршрутизатору, соответствующий процесс сокета обработает его внутренне; иначе маршрутизатор пересылает пакет. В дополнение к пакетам, непосредственно адресованным маршрутизатору, он должен также иметь дело с OxFFFFFFFFFFFF, которые обычно являются пакетами RIP, SAP или диагностики.
Если пакет необходимо переслать, маршрутизатор помещает адрес места назначения из заголовка IPX в поле адреса места назначения заголовка MAC. Затем маршрутизатор помещает свой собственный адрес в поле адреса источника заголовка MAC, увеличивает поле контроля транспорта заголовка IPX и пересылает пакет в сегмент назначения. Если, однако, поле контроля транспорта равно максимально допустимому числу переходов до того, как поле будет увеличено, маршрутизатор отбрасывает пакет. Для маршрутизаторов RIP это число равно 16, для маршрутизаторов NLSP это ограничение задается в диапазоне от 8 до 127.
Широковещательные пакеты никогда повторно не посылаются в сетевые Сегменты, из которых они были получены. Если маршрутизатор не связан напрямую с сегментом, в котором находится узел конечного места назначения, он посылает пакет следующему маршрутизатору на пути к узлу назначения, помещая адрес узла следующего маршрутизатора в поле адреса места назначения заголовка MAC. Маршрутизатор берет эту информацию в своей информационной таблице маршрутизации и затем помещает адрес своего собственного узла в поле адреса источника заголовка MAC, увеличивает поле контроля транспорта в заголовке IPX и пересылает пакет следующему маршрутизатору.
NCP Каждый NCP известен прежде всего по своему номеру, который состоит из трех полей. Например, номер для изменения пароля объекта связывания равен 0x2222 23 64.
• Первое двухбайтовое поле "0x2222" является полем категории службы.
• Второе число "23" является номером функции, который идентифицирует, где в таблице коммутации существует базовая функция.
• Третье поле "64" идентифицирует специальную функцию NCP, которая выполняется.
Номера NCP делятся на широкие функциональные категории. Например, большинство функций номера 23 являются NCP учета, связывания, соединения или файлового сервера. В таблице 3.6 перечислены некоторые из категорий служб NCP.
Категория NCP запроса службы (0x2222) и категория NCP ответа службы (0x3333) используются наиболее часто. Существуют две категории служб, которые не требуют создания пакетов ответа службы (0x3333). Это разрушение служебного соединения (0x5555) и запрос разбиения пакета (0x7777).
Если клиенту посылается сообщение, что предыдущий запрос все еще обрабатывается (0x9999), это означает, что клиент сделал другой запрос или снова послал тот же запрос, в то время как сервер все еще обрабатывает последний, сделанный тем же клиентом, запрос.
Клиент посылает через соединение с сервером сообщение, которое содержит все параметры NCP, используя сетевой протокол, например IPX. Сервер выполняет процедуру и возвращает результаты клиенту. Каждое дополнительное сообщение увеличивает идентификационные номера в пакете. Когда от клиента получен запрос NCP, создается ответ NCP. Это протокол, действующий по принципу один запрос — один ответ.
Выделенный IP-адрес должен обновляться до истечения срока своей службы. Как можно видеть в распечатке выше, когда выделенный адрес подтверждается, одновременно задается время обновления. Процесс обновления требует только двух кадров: запроса DHCP и последующего АСК.
Клиент DHCP будет запрашивать обновление дважды — при запуске и при истечение половины выделенного времени. В каждом из этих случаев, если запрос успешен, он будет использовать только два кадра. Эти два кадра выглядят точно так же, как кадры запроса и подтверждения, показанные в предыдущем разделе. Единственное различие состоит в том, что при запросе во время истечения половины выделенного времени это будет направленная дейтаграмма, а не широковещательное сообщение, как в случае обновления при запуске.
Эти два кадра имеют размер всего 684 байта и требуют только 100 миллисекунд для завершения. Если клиентской машине DHCP не удалось получить обновление после двух попыток, она будет ждать до следующего периода обновления. Если срок выделенного адреса истекает, то машина возвращается к описанному ранее процессу из четырех кадров, как если бы она пыталась получить адрес в первый раз.
Оптимизация трафика DHCP В действительности трафик DHCP имеет минимальное влияние на объем создаваемого сетевого трафика. Существуют только шесть случаев, когда трафик будет присутствовать вообще. Они перечислены ниже:
• Клиенту DHCP требуется адрес в первый раз — четыре кадра.
• Автоматическое обновление при истечении половины выделенного времени — два кадра.
• Перезапуск клиентской машины DHCP — два кадра.
• Машина перемещается в новую подсеть. Это будет создавать два кадра обновления, которые получат отрицательное подтверждение, затем четыре кадра для получения адреса — всего шесть кадров.
• Замена NIC на машине — четыре кадра.
• Адрес IP освобождается или обновляется вручную, с помощью либо ipconfig, либо winipcfg.
Одним из основных способов сокращения объема трафика DHCP является настройка длительности времени выделения. Это делается менеджером DHCP, как показано на рис. Если длительность выделения адреса изменяется с используемых по умолчанию трех дней до тридцати дней, то сокращение трафика может быть существенным — 13684 байта на каждую машину. Такое изменение имеет смысл, когда область адресов значительно больше, чем число хостов, которые необходимо адресовать. Если это не так, то придется либо использовать длительность выделения по умолчанию, либо сделать длительность еще короче. Другой сценарий при настройке длительности выделения номера может возникать в ситуации, когда существует большое количество переносных компьютеров, которые соединяются с сетью на регулярной основе. Если пользователи не обучены освобождать свои IP-адреса при выходе из сети, они могут получать несколько адресов, требуя тем самым большего пространства адресов, чем необходимо.
Использование LMHOSTS Начнем этот раздел с обсуждения двух способов, с помощью которых рабочая станция находит машину регистрации — с помощью широковещания и с помощью WINS. Существует и третий способ: использование файла lmhosts. Обратимся к этому файлу.
Используя запись #PRE, мы приказываем машине сделать предварительную загрузку записи в кэш имен NetBIOS. Она будет найдена, когда мы введем nbtstat -с, как показано на рис. Задав #DOM с именем домена, мы сообщаем машине, что это контроллер домена, и поэтому получаем дополнительные записи, такие как <1С>, также показанные на рис.
Используя файл LMHOSTS, мы ускоряем процесс регистрации, не выполняя при этом ни широковещательного запроса, ни запроса WINS, и, кроме того, сокращаем сетевой трафик. Стандартная проблема с реализацией LMHOSTS состоит в размещении его на всех клиентских машинах. Выход простой: поместите LMHOSTS в сценарий регистрации, и он сам скомпонуется на клиентские машины. На машине WIN NT он помещается в каталоге \\system32\drivers\etc. На машине Windows 9.x он помещается в каталог \\windows.
Нужно ли иметь больше контроллеров доменов? Обычно процесс регистрации происходит между 8 и 9 часами утра. Сколько реально необходимо иметь серверов регистрации? Помните, что добавление дополнительных резервных контроллеров доменов увеличивает сетевой трафик, как мы увидим в следующей главе. Это означает, что было бы плохой идеей сделать каждый сервер в сети резервным контроллером домена (что встречается достаточно часто).
Используя очень консервативную оценку, один контроллер домена может легко управлять 2000 пользователей. Если вернуться к нашему окну регистрации, можно видеть, что в течение одного часа (3600 секунд), происходит в среднем меньше двух регистрации в секунду (если запросы регистрации распределены равномерно). Что делать в такой ситуации? Прежде всего, необходимо использовать монитор производительности для создания протокола утренней деятельности по регистрации. Как можно видеть на рис. лучшим способом это сделать является создание протокола (log) монитора производительности и протокола использования памяти, процессора и серверного объекта. Для этого надо перейти во view\log и выбрать соответствующие режимы. В меню режимов выбирается тип протокола (log), а затем вводится имя протокола. Можно использовать, например, logon.log или добавить дату. Выберите хорошее место для размещения протокола (не в корне), интервал обновления и нажмите save (сохранить). Теперь необходимо добавить некоторые показатели, нажимая кнопку "плюс", как показано на рис.
Когда показатели будут добавлены, необходимо вернуться в меню режимов, выбрать тип протокола (log) и запустить протокол, как показано на рис. Это будет достаточно большой протокол, так как записи в нем появляются каждую секунду.
Если после создания протокола будут замечены периоды, когда происходит множество попыток регистрации в секунду, необходимо сделать несколько дополнительных изменений.
PDC по умолчанию будет проверять свою базу данных каждые пять минут. Если будут обнаружены изменения в любой из трех баз данных, то он пошлет сообщение всем резервным контроллерам домена, указывая изменение в SAM. PDC имеет таблицу каждого BDC, которая содержит идентификатор версии каждой из его баз данных. Если BDC имеет актуальную базу данных и не требуется никаких изменений, то она не будет модифицироваться.
Windows NT 4.0 будет посылать объявление обновления одновременно максимум десяти BDC, чтобы не перегружать полосу пропускания сети. Эту величину можно, конечно, изменить для ситуаций, где полоса пропускания не является проблемой. Преимущество управления обновлениями состоит в сокращении использования полосы пропускания сети. Обратной стороной этого будет увеличение времени для изменения всех BDC.
Как можно видеть на распечатке ниже, PDC выполняет команду "Announce Change to UAS or SAM". Отметим, что кадр включает имя PDC и имя домена. Он содержит также порядковый номер, используемый для сравнения версий базы данных. Этот кадр посылается из PDC прямо в BDC. Это не широковещательный кадр; он посылается в порт UDP 138, который является портом службы дейтаграмм NetBIOS. Это дейтаграмма, направленная в \mailslot\net\NetLogon.
Когда Exchange общается с другим сервером, он использует не РОРЗ или SMTP, а вызовы удаленной процедуры (RPC), которые являются значительно более безопасной и надежной формой коммуникации. Чтобы понять более полно, как работает эта коммуникация, нам необходимо рассмотреть несколько вещей, уникальных для RPC. Служба вызова удаленной процедуры выполняется на сервере Windows NT и решает множество задач, таких как идентификация номера порта, на котором действует определенная служба. Вызов удаленной процедуры помогает Exchange при поиске номеров UUID (универсальной уникальной идентификации), связанных с определенной службой. Эти UUID классифицируются по первым двум символам числа, и хотя другие службы помимо Exchange используют эти числа, несколько из них являются уникальными для продукта. Три наиболее важных номера перечислены ниже.
• А4 — хранилище обмена
• F5 — каталог обмена
• Е1 — служба вызова удаленной процедуры
Если служба вызова удаленной процедуры отказывает, то серверы обмена (Exchange) не могут общаться друг с другом, а также с другими клиентскими машинами. По этой причине хорошее понимание функции RPC может существенно помочь при поиске неисправностей.
Если два сервера обмена (Exchange) хотят общаться друг с другом, прежде всего необходимо запросить службу вызова удаленной процедуры на другом сервере обмена, чтобы определить, где осуществляет прием МТА (агент транспорта сообщений). Необходимость этого обусловлена тем, что МТА будет перемещаться и осуществлять прием на различных портах при последовательных перезагрузках. Служба вызова удаленной процедуры занимается отслеживанием всех различных служб и поддерживает список портов, которые они используют. Когда сервер Microsoft Exchange запускается, он зарегистрируется в службе вызова удаленной процедуры и запросит номер выделенного порта. Служба вызова удаленной процедуры обслуживает запросы TCP/IP на порте 135. Она имеет фиксированный UUID, равный E1AF8308-5D1F-11C9-91A4-08002B14A0FA.
Общение между серверами будет начинаться с механизма разрешения имени (поиск WINS, DNS, Broadcast, LMHOST), после чего следует трехходовое квитирование. Затем Exchange посылает кадр в порт TCP 135, который является службой местонахождения на другом сервере, и связывает RPC со службой вызова удаленной процедуры на другом сервере обмена. Мы узнаем об этом, рассматривая абстрактный интерфейс UUID E1AF8308-5D1F-11C9-91A1-08002B14A0FA. El сообщает нам, что это служба вызова удаленной процедуры.
