Демон gated: более удачный демон маршрутизации
Категория: Маршрутизация | Автор: admin | 25-03-2010, 03:28 | Просмотров: 5730

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

 

В разработку демона gated внесли свой вклад многие люди. Изначально работа координировалась университетом Корнелла, а сам демон распространялся бесплатно. Но в 1992 г. он был приватизирован и перешел в ведение консорциума Merit GateD. Текущие версии демона доступны только членам консорциума. Таковым может стать каждый, но, во-первых, для этого требуется принять условия лицензионного соглашения, а, во-вторых, членство является бесплатным лишь для пользователей из научной среды.

Конечно, определение "только для академического и научно-исследовательского использования" является довольно широким, но мы советуем избегать бюрократической "трясины", в которой увяз демон gated. Последняя его общедоступная версия — номер 3 — работает вполне успешно. На момент написания книги самый свежий ее релиз имел номер 3.5.10, именно его мы и опишем ниже.

Демон gated поддерживает протоколы RIP (обе версии), OSPF и IS-IS для внутренней маршрутизации, EGP и BGP — для внешней. По историческим причинам предусмотрена поддержка старого протокола HELLO.

В табл. 14.3 представлены данные о поддержке демонов routed и gated в наших тестовых системах. Текущая версия демона gated компилируется практически на всех распространенных системах, поэтому их легко обновлять.

Таблица 14.3. Поддержка демонов маршрутизации в тестовых системах

Система

routed?

gated?

Solaris

Да

Нет

HP-UX

Нет

3.5 Beta 3

Red Hat

Да

3.5.10

FreeBSD

Да

3.5.11

 

Управление начальным запуском и параметрами демона

 

Обычно демон gated запускается на этапе начальной загрузки без аргументов. Способ запуска зависит от системы (подробнее об этом рассказывается в параграфе 14.6, нужную информацию можно также найти в главе 2).

Демон берет свои инструкции из единственного конфигурационного файла. По умолчанию он называется /etc/gated.conf, но благодаря специальному флагу командной строки можно задать другой файл. После запуска демона управлять им можно посредством команды gdc, которая инсталлируется вместе с ним. Как правило, она имеет такой формат:

gdc инструкция

 

Ниже дан список наиболее распространенных инструкций.

interface                    Сообщает демону о необходимости повторно просмотреть список активных сетевых интерфейсов ядра. Демон сам делает это периодически, но, если

                                    конфигурация какого-нибудь интерфейса только что изменилась, можно запросить немедленное обновление

reconfig                     Заставляет демон повторно прочитать свой конфигурационный файл

checkconf                 Осуществляется синтаксический анализ конфигурационного файла и поиск в нем ошибок, но демону не сообщается о необходимости загрузки файла

toggletrace               Запуск или останов режима регистрации

stop                             Завершение работы демона; по возможности осуществляется корректное завершение, но в случае необходимости демон останавливается принудительно

start                           Запуск демона, если он еще не выполняется

restart                       Уничтожение демона и повторный его запуск; эквивалентно инструкции stop, за которой следует инструкция start

 

Трассировка

 

Демон gated может выполняться в режиме отладки (трассировки), в котором все действия регистрируются в журнальном файле. Этот режим очень удобен, когда создается новый конфигурационный файл. Кроме того, в журнальном файле фиксируются все обновления маршрутов.

Когда включены некоторые опции трассировки, журнальный файл может очень быстро разрастаться, поэтому его нужно периодически очищать и формировать заново. Команда gdc toggletrace закрывает журнальный файл, чтобы его можно было переименовать или очистить. Следующая команда gdc toggletrace опять включит режим регистрации.

Опции трассировки могут задаваться в конфигурационном файле или в строке запуска демона (перед опциями должен стоять флаг -t, перед именем журнального файла ничего указывать не нужно). В конфигурационном файле можно задавать различные опции для каждого конкретного протокола. Опции указываемые в командной строке, являются глобальными. Ниже перечислены наиболее полезные опции.

all                               Включение всех опций трассировки

normal                       Трассировка обычных событий; необычные события регистрируются всегда

policy                          Отслеживание того, каким образом административные правила безопасности влияют на распространение маршрутов

route                          Трассировка изменений в таблице маршрутизации

general                      Включение опций normal и route

 

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

 

Конфигурационный файл

 

В отличие от многих административных утилит UNIX, по умолчанию демон gated работает достаточно хорошо. У него имеются сотни опций, не для простейших сетей требуется лишь несколько строк конфигурационного файла. Поэтому, читая далее настоящую главу, а также документацию помните, что большинство опций демона будут неактуальными в конкретной системе.

Ниже описаны самые основные параметры конфигурации демона gated. Синтаксис многих из них дан в усеченном виде — указаны только те компоненты, о которых мы хотим поговорить. Если читателям кажется, что должны существовать дополнительные компоненты, то, возможно, так оно и есть: они просто не показаны. Подробности можно узнать в документации по демону gated.

В документации объясняется формат конфигурационного файла, но не говорится о сложных вопросах маршрутизации. Если у читателей возникнет необходимость разобраться в назначении той или иной опции, советуем обратиться к списку литературы, представленному в параграфе 14.9.

Конфигурационный файл состоит из набора инструкций, разделенных символами точки с запятой. Лексемы разделяются пробельными символами, к которым относится также символ новой строки. Иногда для группировки употребляются фигурные скобки.

Имеется несколько классов инструкций. Инструкции каждого типа должны размещаться рядом в конфигурационном файле, а секции следует располагать в таком порядке:

  • опции и определения (включая объявления сетевых интерфейсов);
  • конфигурационные настройки отдельных протоколов;
  • статические маршруты;
  • параметры импорта, экспорта и агрегации.

Допускаются пустые секции.

Опции трассировки могут находиться где угодно. Если они стоят в фигурных скобках, то относятся только к контексту конфигурируемого параметра или протокола. Такие опции задаются с помощью инструкции traceoptions:

traceoptions  [ "журнальный_файл"  [replace]   [size размер[km]

files число]]  опции_трассировки

[except опции_трассировки] ;

 

Аргумент журнальный_файл — это имя файла, в котором сохраняются результаты трассировки. Если указано ключевое слово replace, файл будет очищаться при каждом запуске демона (по умолчанию информация добавляется в конец файла). Аргумент размер задает максимальный размер журнального файла в кило- или мегабайтах. Когда файл становится слишком большим, он очищается и все старые файлы подвергаются переименованию: журнальный_файл.1, журнальный_файл.2 и т.д. вплоть до файла с номером, заданным аргументом число. Если указано предложение size, должно обязательно присутствовать и предложение files.

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

Ниже приведена инструкция, создающая журнальный файл /usr/local/etc/gated.log, предельный размер которого — 1 Мбайт, число сохраняемых версий — 3, и все возможные опции трассировки включены:

traceoptions "/usr/local/etc/gated.log" replace size 1m files 3 all;

 

Задание конфигурационных параметров

 

Формат задания конфигурационных параметров таков:

options [nosend] [noresolv] [syslog [upto] уровень_регистрации];

 

Аргументы имеют следующий смысл:

 

nosend                       Запрещает демону посылать любые пакеты. Эта опция полезна при отладке, так как можно попросить демон обрабатывать информацию, поступающую от

                                    других маршрутизаторов, но самому не взаимодействовать с ними

noresolv                     Запрещает демону использовать базу данных DNS для преобразования имен компьютеров в IP-адреса. DNS-запросы потерпят неудачу, если для их обработки

                                     недостаточно маршрутной информации, что приведет к возникновению взаимоблокировки. Мы советуем не указывать имена компьютеров в какой бы то ни было

                                     сетевой конфигурации — данная опция позволяет реализовать подобную политику

syslog                        Определяет, какой объем информации регистрируется через систему Syslog. Эта опция бесполезна, если в организации не используется система Syslog. Доступные уровни регистрации можно узнать на man-странице syslogmask. По умолчанию принята опция syslog upto info

 

Пример:

options noresolv;

 

Определение сетевых интерфейсов

 

Свойства сетевого интерфейса задаются посредством инструкции interfaces, формат которой имеет вид:

interfaces {

options  [strictinterfaces];

define адрес [broadcast адрес] | [pointtopoint адрес];

interface список_интерфейсов [preference приоритет] [passive]

[simplex];

[netmask маска] [multicast);

};

 

Может быть несколько инструкций options, interface или define либо ни одной. То же самое справедливо в отношении большинства инструкций конфигурационного файла.

Опция strictinterfaces делает нелегальной ссылку из конфигурационного файла на интерфейс, который на момент запуска не зарегистрирован в ядре и не упомянут в инструкции define. Подобная ссылка всегда является ошибкой, но при наличии опции strictinterfaces она становится не фатальной.

Инструкция define описывает сетевой интерфейс, который может отсутствовать на момент запуска демона. Обычно указываются коммутируемые каналы и платы PCMCIA.

Инструкция interface определяет параметры конкретного интерфейса или набора интерфейсов. В качестве имени может использоваться реальное имя интерфейса, такое как de0 или le1, обобщенное имя, например de или lе (ссылается на все экземпляры интерфейсов данного типа), доменное имя, IP-адрес или ключевое слово all.

Если интерфейс объявлен с ключевым словом passive, маршруты через него будут существовать даже в том случае, когда сам интерфейс не подключен. Ключевое слово simplex указывает на то, что интерфейс не должен принимать свои собственные широковещательные пакеты. Обычно демон gated самостоятельно выполняет подобного рода конфигурирование, но в некоторых системах его нужно задавать явно.

Предложение preferences требует более подробного пояснения. Поскольку протоколы маршрутизации работают по-разному и используют различные метрики стоимости для определения "кратчайшего" пути, нет гарантии, что любые два протокола смогут договориться о том, какой маршрут наилучший. Если результаты, полученные с помощью разных протоколов, оказываются неодинаковыми, необходимо на административном уровне решить, какие маршруты следует занести в таблицу ядра и послать другим маршрутизаторам.

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

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

Обычно маршруты к непосредственно подключенным сетям имеют приоритет 0. Если необходимо предпочесть один интерфейс другому, можно воспользоваться предложением preference для расстановки  приоритетов. В табл. 14.4 перечислены некоторые стандартные приоритеты, признаваемые демоном gated.

В следующем примере интерфейс lе0 объявляется пассивным, т.е. через него не будет распространяться маршрутная информация:

interface {

interface le0 passive;

};

 

Таблица 14.4. Стандартные приоритеты маршрутов

Источник маршрутной информации

Приоритет

Маршруты к непосредственно подключенным сетям

0

Маршруты, полученные с помощью протокола OSPF

10

Переадресующие директивы ICMP

30

Статические маршруты, определенные внешне

40

Статические маршруты, заданные в файле gated.conf

60

Маршруты, полученные посредством протокола RIP

100

Маршруты между РРР-интерфейсами

110

Маршруты через интерфейсы, которые не работают

120

 

Другие определения

 

В секции определений можно задавать ряд других глобальных параметров, например:

routerid узел;

 

Инструкция routerid задает идентификатор маршрутизатора, который используется протоколами BGP и OSPF. Он должен быть представлен в формате IP-адреса и по умолчанию соответствует адресу первого физического интерфейса машины. Это значение важно для протоколов, которые им пользуются. Другие маршрутизаторы могут явно ссылаться на него в своих конфигурационных файлах.

martians {

host узел [allow];

сеть [allow]   [exact  |  refines];

сеть mask маска  [allow]   [exact  | refines];

сеть masklen число [allow]   [exact  |  refines];

default  [allow];

};

 

"Марсианские" маршруты — это маршруты к адресатам, которых нужно игнорировать. В сети могут существовать неправильно сконфигурированные маршрутизаторы, осуществляющие широковещательную рассылку маршрутов к фиктивным адресатам. Помимо этого может потребоваться просто исключить некоторые записи из таблицы маршрутизации. Любой маршрут к адресату, указанному в инструкции martians, игнорируется демоном gated.

С каждым пунктом маршрутизации связаны адрес и сетевая маска. Различные варианты инструкции martians представляют собой различные способы задания пары адрес/маска.

В предложениях mask и masklen оба значения задаются явно. Если маска не указана, она вычисляется на основании класса адреса.

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

При наличии ключевого слова exact целевой адрес и маска должны в точности соответствовать значениям, приведенным в инструкции, чтобы адресат считался "марсианином". Точное совпадение определяет выбор самой сети, но не ее подсетей или надсетей.

При наличии ключевого слова refines целевая маска должна быть длиннее, чем та, что указана в инструкции. В подобном случае адреса сравниваются обычным способом (с использованием маски из инструкции). Это эквивалентно выбору подсетей, а не самой сети.

Записи

host узел;

default;

 

можно представить так:

 

узел mask 255.255.255.255 exact;

0.0.0.0 mask 0.0.0.0 exact;

 

Ключевое слово allow разрешает адрес, запрещенный ранее более общей спецификацией. Например:

martians {

128.138.0.0 mask 255.255.0.0;

128.138.145.0 mask 255.255.255.0 allow;

};

 

В данной конфигурации запрещаются все маршруты к сети 128.138 класса В, однако допускается маршрут в подсеть 128.138.145. Более конкретно; правило всегда имеет приоритет.

 

Конфигурирование протокола RIP

 

Обе версии протокола RIP конфигурируются посредством инструкции rip:

rip yes  | no  | on | off [(

broadcast;

nobroadcast;

preference приоритет;

defaultmetric метрика;

interface список_интерфейсов

[noripin | ripin]   [noripout | ripout]

[version 1] | [version 2 [multicast | broadcast]];

trustedgateways список_шлюзов;

sourcegateways список_шлюзов;

traceoptions [packets | request | response [detail]];

}];

 

Ключевые слова yes и no являются синонимами слов on и off. Протокол RIP по умолчанию разрешен. Если нужно запретить его, включите такую запись:

rip no;

Опции broadcast и nobroadcast аналогичны флагам -s и -q демона routed. Опция broadcast заставляет демон рассылать RIP-обновления даже тогда, компьютер подключен всего к одной сети. Опция nobroadcast запрещает посылать любые RIP-обновления.

Предложение defaultmetric назначает указанную метрику стоимости маршрутам, которые были получены от других протоколов, но повторно рассыпаются средствами RIP. Вообще говоря, это не самый лучший способ трансляции маршрутов, но элегантного решения просто не существует. По умолчанию метрика задается равной 16, т.е. адресат недоступен, поэтому маршруты других протоколов никогда не будут распространяться через RIP. Если же нужно разрешить подобную рассылку, хорошим значением будет 10.

Имена интерфейсов назначаются так же, как и в инструкции interfaces, описанной выше. Опция ripin задает прием RIP-обновлений для данного интерфейса, а опция noripin запрещает их принимать. Опции ripout и noripout являются аналогами опций broadcast и nobroadcast, используемыми для отдельных интерфейсов. Опция noripout установлена по умолчанию для РРР-соединений.

Предложение version определяет, какую версию протокола — RIP-1 или RIP-2 — следует применять для заданных интерфейсов. В случае протокола RIP-2 по умолчанию осуществляется групповая, а не широковещательная рассылка маршрутов, поэтому маршрутизаторы RIP-1 их не получат. Чтобы отменить подобное поведение, задайте опцию broadcast.

По умолчанию демон gated принимает RIP-обновления от каждого, кто их посылает. Но, если присутствует список trustedgateways, допускаться будут только сообщения от упомянутых в нем узлов. Список шлюзов представляет собой перечень IP-адресов, разделенных пробелами.

В предложении sourcegateways перечислены узлы, RIP-обновления к которым должны посылаться напрямую, а не широковещательно. Подобная возможность используется для отправки разной маршрутной информации заданным шлюзам и для доступа к маршрутизаторам в сети, где широковещание не поддерживается или запрещено.

Опции трассировки устанавливаются посредством уже знакомой нам инструкции traceoptions. Перечисленные здесь опции применимы только к протоколу RIP. Опции request, response и packets задают регистрацию полученных запросов, отправленных запросов и всех пакетов соответственно. В последнем случае обычно записывается суммарная информация, но при наличии опции detail формируется подробный отчет о каждом пакете.

 

Базовые сведения о протоколе OSPF

 

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

 

Области маршрутизации

 

В крупных организациях обычно не требуется распространять всю информацию о состоянии канала из одного конца сети в другой. Протокол OSPF позволяет с целью уменьшения трафика, вызываемого обновлениями маршрутов, объединять отдельные сети в области. Канальная информация (т.е. данные о физической топологии сети) распространяется только в пределах области. Сведения об областях передаются во внешний мир в виде маршрутных резюме.

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

Маршрутные резюме представляют собой совокупность маршрутов следующего вида: "Маршрутизатор X может посылать пакеты в сеть Y, находящуюся на расстоянии трех переходов" (где X — пограничный маршрутизатор). Маршрутизаторы, находящиеся за пределами данной области складывают метрику стоимости, заявленную в резюме, с вычисленной стоимостью доступа к пограничному маршрутизатору и получают итоговою стоимость пути в требуемую сеть.

Описанная схема напоминает завуалированный дистанционно-векторный протокол, но есть два важных отличия. Во-первых, резюмирующие сообщения распространяются точно в том виде, в котором они поступают от пограничных маршрутизаторов. Маршрутизатор может подсчитать для себя, что если он находится на расстоянии двух переходов от сети X, а сеть X расположена в трех переходах от Y, то от него до Y — 5 переходов. Но он никогда не откроет результаты своих вычислений другому маршрутизатору, а просто передаст дальше исходный резюмирующий маршрут.

Другое отличие от дистанционно-векторных протоколов заключается в том, что протокол OSPF не пытается подстроиться под произвольные сетевые топологии. Требуется, чтобы все области маршрутизации были логически смежными с центральной опорной областью, известной как область 0 (они также могут быть смежными друг с другом). Маршрутные резюме могут распространяться только от краевых областей в центральную и наоборот, но не между краевыми областями. Подобная простая двухуровневая иерархия предотвращает возникновение циклов.

Если архитектура реальной сети не соответствует двухуровневой модели, OSPF, еще не все потеряно. Построить двухуровневую иерархию можно, воспользовавшись имеющейся в OSPF концепцией "виртуальных каналов". К сожалению, эта тема выходит за рамки нашей книги.

 

Отмеченные маршрутизаторы

 

Теоретически топологические протоколы распространяют маршрутную информацию в виде записей, описывающих связи между маршрутизаторами, например: "Маршрутизатор А граничит с маршрутизаторов Б, а стоимость соединения равна 1". Если в сети 6 маршрутизаторов, придется рассылать 30 различных канальных уведомлений, поскольку каждый маршрутизатор граничит с пятью другими. Более того, все маршрутизаторы будут считать друг друга соседями, и, таким образом, потребуется синхронизация их баз данных.

Протокол OSPF сокращает объем рассылаемой информации, делая один из маршрутизаторов в сети отмеченным. Отмеченный маршрутизатор принимает канальные уведомления от всех других маршрутизаторов, а затем рассылает итоговый отчет о собранных маршрутах.

Маршрутизаторы договариваются о том, кого из них выбрать на "руководящую должность", основываясь на значениях приоритетов, заданны; административным путем. Маршрутизаторы с приоритетом 0 не могут быть отмеченными. Среди оставшихся победителем становится тот, у кого самый высокий приоритет. Если таких маршрутизаторов несколько, выбор осуществляется псевдослучайным способом.

Аналогичным образом назначается резервный отмеченный маршрутизатор. Каждый маршрутизатор в сети постоянно держит связь с обоими отмеченными маршрутизаторами. Если центральный выходит из строя, его место тут же занимает резервный, а на освободившуюся "должность" проводятся новые выборы.

Отмеченные маршрутизаторы обрабатывают больший объем данных. Это следует учитывать при их выборе.

 

Конфигурирование протокола OSPF

 

Настройка параметров протокола OSPF проводится с помощью инструкции ospf:

ospf yes | no | or | off [{

defaults {

router-prio;

};

traceoptions опции_трассировки;

backbone | (area область)   {

networks {

сеть [exact | refines]   [restrict];

сеть mask маска [exact | refines]   [restrict];

сеть masklen число [exact | refines]   [restrict];

host узел [exact | refines]   [restrict];

};

stubhosts {

узел cost стоимость;

};

 

interface список_интерфейсов [cost стоимость]   {

enable | disable;

priority приоритет;

};

};

};

 

Эта инструкция проще, чем кажется на первый взгляд. Ключевые слова on, off, yes и no имеют очевидное значение. По умолчанию протокол OSPF не используется.

Ключевое слово router-prio в разделе defaults указывает на то, что маршрутный приоритет (применяется при выборе отмеченного маршрутизатора) равен 1 для всех интерфейсов. При желании это значение можно переопределить, описывая конкретный интерфейс. По умолчанию приоритет равен 0, вследствие чего демон gated не может стать отмеченным маршрутизатором какой бы то ни было сети.

Определение области начинается с ключевого слова backbone или area. Необходимо, чтобы была одна такая инструкция для каждой области, членом которой является маршрутизатор. В спецификации протокола OSPF сказано, что опорная область должна быть областью 0, но демон gated требует указывать ключевое слово backbone, а не area 0.

Аргумент область может быть задан в виде десятичного числа или четырехбайтового числа в формате IP-адреса (например, 128.138.45.2). Демон gated никогда не интерпретирует номер области как IP-адрес, но точечная четырехбайтовая запись предусмотрена для того, чтобы области можно было помечать IP-адресами основных маршрутизаторов или серверов.

В списке networks перечислены сети, входящие в область. Сети нужно указывать только в конфигурационных файлах пограничных маршрутизаторов. Спецификация адреса и сетевой маски дается так же, как и в рассмотренной выше инструкции martians, за исключением того, что ключевое слово allow отсутствует. Сети, помеченные ключевым словом restrict, не включаются в маршрутные резюме. Они являются "секретными" и доступны только в пределах данной области.

В списке stubhosts перечислены непосредственно подключенные узлы, которые объявляются доступными через данный маршрутизатор и имеют указанную стоимость (обычно 1). Обычно таким образом описываются PPP- и SLIP-соединения.

Наконец, в списке interface указывается стоимость маршрута к каждой подключенной сети (по умолчанию 1) и приоритет демона gated для нее (используется при выборе отмеченного маршрутизатора). Если для интерфейса задано ключевое слово disable, то через него не будет проходить OSPF-трафик.

 

Конфигурирование переадресующих ICMP-директив

 

Демон gated позволяет обеспечивать административный контроль над маршрутами, найденными благодаря переадресующим IСМР-директивам (см. параграф 13.5).

redirect yes | no | on | off [{

preference приоритет;

interface список_интерфейсов [noredirects] | [redirects];

trustedgateways список_шлюзов;

traceoptions опции_трассировки;

}];

 

Все опции должны быть уже знакомы читателям. Предложение preference задает общий приоритет переадресованных маршрутов (по умолчанию 30, что вполне приемлемо). Опции redirects и noredirects соответственно разрешают и запрещают прием переадресующих сообщений по данному интерфейсу. В списке trustedgateways перечислены маршрутизаторы, от которых разрешается принимать такие сообщения. С переадресацией не связаны никакие дополнительные опции трассировки.

В некоторых системах ядро самостоятельно обрабатывает переадресующие ICMP-директивы, не позволяя вмешиваться демону gated. В этом случае демон проверяет, приняло ли ядро директиву, и самостоятельно удаляет маршрут из таблицы, если он нежелателен.

 

Статические маршруты

 

Статические маршруты конфигурируются посредством инструкции static:

static {

адрес gateway список_шлюзов [interface список_интерфейсов]

[preference приоритет] [retain] [reject] [blackhole]

[noinstall];

};

 

Аргумент адрес может быть задан одним из следующих традиционных способов:

host узел

default

сеть

сеть mask маска

сеть masklen длина

 

 

Аргумент список_шлюзов — это перечень маршрутизаторов, посредством которых можно достичь указанного адресата. Теоретически может существовать несколько шлюзов, но в большинстве систем ядро не поддерживает многовекторную маршрутизацию. Если обозначенный шлюз не находится в непосредственно подключенной сети (список интерфейсов подключения задается в предложении interface), маршрут игнорируется.

По умолчанию приоритет маршрута равен 60, что позволяет перекрывать его маршрутами, найденными посредством протокола OSPF или переадресующих ICMP-директив.

Если маршрут помечен ключевым словом retain, он будет существовать в таблице маршрутизации ядра, пока выполняется демон gated. Обычно демон производит после себя очистку, оставляя лишь адреса интерфейсов и те маршруты, которые существовали до него. В противоположность этому ключевое слово noinstall запрещает помещать маршрут в локальную таблицу маршрутизации, разрешая лишь сообщать о нем другим маршрутизаторам. Данная возможность оказывается полезной при реализации "серверов маршрутизации", которые реально не осуществляют переадресацию трафика, а лишь управляют маршрутной информацией в рамках сети.

Маршруты, помеченные ключевыми словами blackhole и reject, запрещают перенаправление пакетов в тех системах, где оно поддерживается. В случае опции reject отправителю возвращается ICMP-пакет с сообщением об ошибке; а при использовании опции blackhole пакеты просто исчезают.

 

Экспортируемые маршруты

 

Если демон gated нашел все необходимые ему маршруты, он помещает их в таблицу ядра. Для большинства приложений больше ничего не требуется. Но иногда нужно так сконфигурировать демон, чтобы он выступал в роли транслятора, принимая информацию от одного протокола и направляя ее в другой. Управление этим процессом осуществляется посредством инструкции export:

export proto протокол

[interface список_интерфейсов | gateway список_шлюзов]

restrict;

 

или

 

export proto протокол

[interface список_интерфейсов | gateway список_шлюзов]

[metric метрика]   {

экспортируемый_список;

};

 

Аргумент протокол — это протокол маршрутизации, осуществляющий рассылку транслируемой информации. В экспортируемом списке содержится по одному предложению proto для каждого транслируемого набора данных. Вот пример такого списка:

proto static {

ALL metric 1;

};

 

В соответствии с этим списком все статические маршруты помещаются в экспортируемый список с метрикой стоимости 1.

 

Полный пример конфигурации демона gated

 

Ниже показана конфигурация сети, в которой используется как протокол RIP, так и OSPF. Конфигурационный файл предназначен для пограничной маршрутизатора (рис. В).

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

Содержимое конфигурационного файла выглядит так:

Секция 1:

rip yes {

broadcast;

defaultmetric 10;

interface 192.225.40.253 noripout;

interface 192.225.55.253 ripout;

};


Секция 2:

ospf yes {

area 0.0.0.2 {

authtype none;

networks {

192.225.55.0 mask 255.255.255.0;

};


interface 192.225.55.253 cost 1 {

priority 2;

};

};


backbone {

interface 192.225.40.253 {

priority 2;

};

};

};


Секция 3:

static {

default gateway 192.225.40.254 preference 140 retain;

};


Секция 4:

export proto rip {

proto ospf (

ALL metric 1;

};

proto direct {

ALL metric 1;

};

proto static {

ALL metric 1;

};

};


Секция 5;

export proto ospf {

proto direct (

ALL metric 1;

};

};

 

В секции 1 демону gated сообщается о необходимости поддержки протокола RIP. Демон принимает широковещательные RIP-обновления от других маршрутизаторов по обоим интерфейсам, но собственные RIP-пакеты посылает только через интерфейс 192.225.55.253. Это позволяет устранить нежелательный широковещательный трафик в корпоративной магистрали.

В секции 2 активизируется протокол OSPF. Интерфейс 192.225.40.253 находится в опорной области 0. Через него демон рассылает другим маршрутизаторам "приветственные" OSPF-сообщения (протокол HELLO), чтобы обнаружить своих соседей. Интерфейс 192.225.55.253 располагается в области 2.

Данная сеть имеет лишь один выход во внешний мир. Поэтому в секции 3 объявляется стандартный статический маршрут к Internet-шлюзу в сети 192.225.40.0

В секциях 4 и 5 демону gated сообщается о том, какие маршруты следует распространять через протоколы RIP и OSPF соответственно. В RIP-уведомления будут включаться маршруты к непосредственно подключенным сетям, стандартный статический маршрут, а также любые маршруты, полученные через протокол OSPF. В OSPF-уведомления будут включаться только маршруты к непосредственно подключенным сетям (например, 192.225.55.0). Объявлять стандартный шлюз нет необходимости, так как это внутренний маршрутизатор.


 (голосов: 1)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page