Примеры практических решений на оборудовании Cisco Systems |
Этот цикл статей предназначен для читателей, знакомых с сетевыми технологиями и специально построен на рассмотрении примеров, позволяющих лучше проявить особенности, возможности и уместность применения рассматриваемых технологий. Он призван прежде всего помочь определиться с выбором подходящего решения, которое соответствовало бы текущим требованиям и, в тоже время, позволяло расширяться в будущем. Мы не будем слишком глубоко погружаться в рассмотрение технологий, а попытаемся рассмотреть вопросы их применения и на практике.
Рассматривая разные способы подключения, примеры использования протоколов маршрутизации, безопасные варианты подключения к интернет, способы резервирования каналов доступа и средства обеспечения различного уровня обслуживания для трафика данных и трафика реального времени, мы попытаемся создать целостное представление о сети и возможностях, которые она предоставляет.
В каждой статье мы рассмотрим реальный пример на применение рассматриваемых технологий. Но чтобы рассмотреть задачу из реальной жизни достаточно полно, без упрощения ключевых моментов решения, мы будем вынуждены ограничиться краткими пояснениями ко многим командам и понятиям, уделив основное внимание ключевым моментам рассматриваемых решений, и рекомендуем читателю обратиться к документации по оборудованию для получения более полной информации. Более того, практически все рассматриваемые решения в разных вариантах представлены на www.cisco.com.
Чтобы конкретизировать задачу, будем рассматривать различные варианты подключения филиала к центральному офису. При принятии решения о способе подключения на практике редко есть выбор из нескольких вариантов. Как правило реально осуществим только один. Между городами или разными районами города это могут быть услуги Frame Relay, ISDN или DialUp. У близко расположенных зданий это может быть выделенная линия.
Наиболее простым вариантом, по-видимому, является подключение по выделенной линии и именно ему мы уделим внимание в первой статье.
Во всех примерах предполагается, что в сети возможна адресация с использованием адресов, выделенных для свободного использования в частных сетях. Для определённости подсети сети 10.0.0.0 будут использоваться для адресации в LAN сегментах, а подсети сети 172.16.0.0 будут использоваться для WAN интерфейсов.
Наиболее простым вариантом является подключение филиала по выделенной линии Рис. 1.
Предполагая, что модемы настроены (как правило достаточно руководства к модему), рассмотрим конфигурации маршрутизаторов :
В центре :
int e0 ip address 10.0.0.1 255.255.255.0 int s0 ip address 172.16.0.1 255.255.255.0
В филиале :
int e0 ip address 10.1.1.1 255.255.255.0 int s0 ip address 172.16.0.2 255.255.255.0
В зависимости от полосы пропускания и административной политики можно использовать статическую или динамическую маршрутизацию. Для одного или двух филиалов и одной сети в центре проще использовать статическую маршрутизацию.
В центре
ip route 10.1.1.0 255.255.255.0 172.16.0.2
в филиале
ip route 0.0.0.0 0.0.0.0 172.16.0.1
маршрут по умолчанию - весь трафик не относящийся к локальной подсети отправлять в центр.
В случае, если в центре уже используется какой либо динамический протокол маршрутизации, его можно использовать и в филиале. К динамическому протоколу маршрутизации следует прибегнуть и при большом количестве филиалов или при сложной структуре центральной сети, например, состоящей из нескольких подсетей.
Например, для протокола EIGRP надо дать следующие команды
В центре и в филиале :
router eigrp 100 network 10.0.0.0 network 172.16.0.0 no autosummary
последняя команда позволит включать в таблицу маршрутизации не полноклассовые подсети.
Протокол EIGRP (Enhanced Interior Gateway Protocol) является фирменным протоколом, работающим только на маршрутизаторах Cisco Systems. Если нет необходимости обеспечить совместимость с другим оборудованием, то его использование более чем оправдано. Протокол EIGRP относится к протоколам гибридного типа, успешно сочетая в себе лучшие стороны протоколов Link State и Distance Vector. Потребляя даже меньше процессорных ресурсов чем протокол IGRP, Enhanced IGRP обеспечивает практически такую же скорость конвергенции, какую обеспечивает такой мощный протокол, как OSPF. Но в отличии от протокола OSPF, он гораздо проще настраивается и, в случае одной автономной системы, настроить его неправильно очень трудно. Он требует очень мало полосы пропускания передавая только изменившуюся часть таблиц маршрутизации и только в случае изменения топологии сети. Причем пересчет таблиц маршрутизации будет выполняться только на маршрутизаторах, на которые эти изменения повлияют. Он использует механизм обмена приветствиями с непосредственными соседями, который не зависит от нижележащего транспортного протокола. И, наконец, он поддерживает маршрутизацию нескольких протоколов, например, IP, IPX, AppleTalk, и редистрибуцию маршрутной информации в другие протоколы маршрутизации.
Еще одной важной особенностью этого протокола является поддержка маршрутизации не полноклассовых сетей, которую мы использовали в нашем примере, назначив подсети одной сети 10.0.0.0 для разных филиалов и центрального офиса.
При включении этого динамического протокола маршрутизации хорошим тоном будет добавить строчку
int s0 bandwidth 128
на обоих маршрутизаторах, где 128 Кб это реальная скорость канала. Данный параметр необходим для правильного вычисления метрики маршрута протоколом EIGRP.
Поскольку подключение осуществляется по выделенной линии, то на последовательных интерфейсах можно использовать инкапсуляцию предусмотренную режимом по умолчанию. Для маршрутизаторов Cisco это инкапсуляция HDLC. Протокол HDLC в реализации Cisco позволяет передавать различные протоколы третьего сетевого уровня IP, IPX, AppleTalk при минимальных накладных расходах.
Данная конфигурация будет работать, например, при попытке выйти в Internet из филиала через центральный офис (в случае, если в филиале используется маршрут по умолчанию, а на клиентской станции в качестве шлюза по умолчанию указан адрес LAN интерфейса маршрутизатора и задан адрес DNS сервера провайдера). Однако, если попытаться подключиться основному контроллеру домена NT (PDC - Primary Domain Controller) в сети Microsoft в центральном офисе, ничего не получиться.
В сетях Microsoft клиентские станции находят сервер домена, используя несколько методов:
При этом часть методов требует настройки станции, а часть требует также и настройки маршрутизатора.
Предположим что в центральном оффисе есть сервер NT выполняющий роль основного контроллера домена NT с адресом 10.0.0.101.
Для каналов с небольшой пропускной способностью и небольшим количеством клиентских станций эффективным будет использование файла lmhosts в который следует добавить строчку :
10.0.0.101 DOMAIN_PDC #PRE #DOM:DOMAIN
Если на этом сервере установлена службa WINS, то на клиентской станции (пусть это будет станция под Windows 95) достаточно будет указать адрес WINS сервера без какой либо настройки маршрутизатора.
В случае достаточно широкой полосы пропускания, можно настроить на маршрутизаторе трансляцию широковещательных сообщений (broadcast) в групповые запросы (multicast) и запросы конкретному устройству (unicast).
В филиале
int e0 ip helper-address 10.0.0.101
В этом случае все широковещательные запросы будут транслироваться в запросы к серверу в центральном офисе.
По умолчанию будут транслироваться запросы к tftp, dns, time, netbios, tacacs и bootpc. Однако, можно ограничить трансляцию широковешательных сообщений одним или несколькими типами.
В отличие от протокола IP, который по умолчанию маршрутизируется, протокол IPX, по умолчанию, коммутируется. Проблема : что лучше коммутация или маршрутизация для WAN каналов, однозначно решается в пользу последней, поскольку, во-первых, позволяет защитить полосу пропускания WAN соединения от неэффективного использования, и, во-вторых, на более высоком уровне управлять трафиком, что весьма существенно для IPX сетей.
Для включения маршрутизации IPX дадим команду
ipx routing
и присвоим номера сетей на интерфейсах.
В центре
int e0 ipx network 3 ipx encapsulation sap int s0 ipx network aaa1
в филиале
int e0 ipx network 777 ipx encapsulation sap int s0 ipx network aaa1
На уровне фрейма Ethernet для протокола IPX существует несколько типов инкапсуляции. Для Novell Netware 4.10 и выше по умолчанию используется 802.2 в нотации Novell, что соответствует IEEE 802.3 и sap в cisco IOS.
С протоколом IPX дело обстоит с одной стороны проще - при включении маршрутизации автоматически включается протокол маршрутизации IPX RIP, и маршрутизатор начинает формировать свою SAP таблицу и передавать SAP сообщения сразу обеспечивая работу IPX сетей.
С другой стороны для каналов с низкой пропускной способностью и при наличии достаточно большого количества серверов и клиентских станций, практически вся пропускная способность канала может быть "съедена" служебным трафиком.
Рассмотрим возможности фильтрации трафика IPX, которые предоставляют маршрутизаторы cisco.
Возможная схема IPX сети филиала и центрального офиса представлена на рис.2.
Вообще возможны 13 различных IPX фильтров для IPX интерфейсов. Несмотря на то, что наша задача достаточно проста для её решения, потребуется отфильтровать следующие виды трафика:
В общем случае фильтровать IPX трафик не требуется, поскольку, не имея информации о сервисах или маршрута, необходимого для установления соединения с сервером Netware, клиентские станции не смогут установить соединения с сервером и, следовательно, не будут порождать и IPX трафик. Это, например, может быть диалог между сервером и станцией по протоколу NCP.
Каждый Netware сервер шлет по своему внутреннему таймеру с интервалом в 60 секунд свою таблицу доступных сервисов (Service Advertisement Table) по протоколу SAP (Service Advertisement Protocol). Маршрутизатор Cisco формирует свою SAP таблицу на основе широковещательных сообщений, которые он получает из LAN сегмента от всех серверов Netware. Причем в эту таблицу включаются только те сервисы, для которых есть маршруты в таблице маршрутизации. И, на основе включенных в SAP таблицу сервисов, уже по своему внутреннему таймеру, маршрутизатор передает SAP сообщения на другие интерфейсы (в нашем случае на интерфейс s0).
Этот механизм уже щадит полосу пропускания, поскольку, независимо от количества серверов в LAN сегменте, маршрутизатор сводит все их сообщения в одну таблицу и уже ее посылает по своему таймеру в IPX сети, а не транслирует SAP пакеты от каждого сервера.
Для того, чтобы маршрутизаторы не отвергали сервисы анонсируемые в SAP пакетах, можно включить режим sap after rip - передачу SAP пакетов сразу за обновлениями маршрутов, что уменьшает вероятность отказа во включении сервиса в таблицу. Кроме того, можно увеличить интервал обновления таблиц маршрутизации на медленных каналах. При устойчивой работе серверов и корректном их выключении это не будет сказываться на работе клиентских станций. И наконец, можно явно отфильтровать не нужный для филиала IPX тарафик.
Как только сервер и клиент установили соединение, сервер будет регулярно посылать пакеты, чтобы убедиться, что клиентский компьютер работает (клиент должен подтверждать получение пакетов). По умолчанию, эти пакеты (watchdog) посылаются примерно раз в пять минут и интервал увеличивается, если подтверждение о получении не поступило. В случае использования протокола SPX, контрольные (keepalive) пакеты посылаются и сервером и клиентской станцией. Предотвратить попадание этого трафика в низкоскоростной канал можно, включив на маршрутизаторе функцию watchdog spoofing и SPX spoofing - в этом случае маршрутизатор А отвечает серверу от имени клиента, подключенного к маршрутизатору В, и наоборот, маршрутизатор В отвечает клиенту от имени сервера, подключенного к маршрутизатору А.
В нашем примере отфильтровывается информация о излишних маршрутах и сервисах, не требующихся в филиале.
На итрерфейсах s0 маршрутизаторов в центре и в филиале включим следующие фильтры.
int s0 ipx network AAA1
фильтруем обновление таблиц маршрутизации
ipx output-network-filter 901
фильтруем анонсируемые сервисы
ipx output-sap-filter 1001
отключаем fast-switching - это приводит к обработке всех пакетов в режиме route-processing, что необходимо для режимов watchdog spoofing и ipx spoofing
no ipx route-cache
включаем watchdog и ipx spoofing
ipx watchdog-spoof ipx spx-spoof
устанавливаем режим посылки анонсируемых сервисов сразу за обновлениями таблиц маршрутизации.
ipx update sap-after-rip
устанавливаем период посылки обновлений таблиц маршрутизации
ipx update interval rip 300
возможен так же режим посылки обновлений таблиц маршрутизации только в случае их изменения
ipx update interval rip changes-only
Соответствующие списки доступа выглядет так :
фильтруем RIP пакеты - разрешаем информировать удаленный маршрутизатор о сети 777 - внутренней сети сервера Netware в центре.
access-list 901 permit rip 777 all any rip
фильтруем SAP пакеты - разрешаем сообщать о существовании файлового сервиса и сервиса службы NDS (Netware Directory Service).
access-list 1001 permit 777 4 access-list 1001 permit 777 278
остальной трафик по умолчанию запрешен.
В случае использования динамического протокола маршрутизации EIGRP, можно настроить передачу информации о сервисах только при ее изменении, что для стабильных сетей практически полностью освободит низкоскоростной канал от загрузки этим видом трафика, сохранив при этом преимущества динамической маршрутизации.
ipx routing int s0 ipx network AAA1 ipx sap-incremental eigrp 100 ipx router eigrp 100 network AAA1 network 3
Поскольку router rip по умолчанию включен, то надо исключить сеть AAA1 из списка маршрутизируемых.
ipx router ripno network AAA1
В этой статье мы намеренно не коснулись способов фильтрации IP трафика, их мы рассмотрим в следующей статье, рассказывая об организации резервных каналов по коммутируемым линиям.
Конечно, рассмотренные способы не исчерпывают всего спектра возможностей предоставляемых этим оборудованием. За пределами нашего примера остались настройки IPX WAN, технологии позволяющей более точно определить задержку для WAN канала и влияющей на метрику маршрута. Это может быть существенно для сетей со сложной структурой. Схема подключения не предусматривала наличие серверов NT и Netware в филиале. Не рассматривалась структура сети в центральном офисе. Но, рассматривая данное решение как базовое, мы уже можем двигаться дальше. Обеспечив связь между центром и филиалом, и, настроив маршрутизацию протоколов IP и IPX, в следующей статье мы рассмотрим решение, обеспечивающее резервирование основных каналов связи.
 © TerraNet webmaster@terranet.ru |
||
Тел: +7 (495) 787-52-90,155-43-37/29/43 факс: +7 (495) 155-43-37/29/43 |