Обобщение маршрутов в октете

Предположим, что маршрутизатор получает обновления маршрутизации для сле­дующих маршрутов (рис. 2.10):

172.16.168.0/24

172.16.169.0/24

172.16.170.0/24

172.16.171.0/24

172.16.172.0/24

172.16.173.0/24

172.16.174.0/24

172.16.175.0/24

Рис. 2.10. Обобщение маршрутов в октете

Для определения обобщенного маршрута маршрутизатор определяет количество старших битов, которые совпадают во всех адресах. После записи всех IР- адресов в би­нарном формате легко определить количество старших битов, которые совместно ис­пользуются всеми IP-адресами. На рис. 2.10 общими для всех адресов являются 21 бит. Следовательно наилучшим обобщенным маршрутом является 172.16.168.0/21. Обобще­ние адресов возможно в том случае, когда количество адресов является какой-либо сте­пенью числа 2. Если количество адресов не является степенью 2, то следует разделит эти адреса на группы и обобщить маршруты этих групп отдельно.

Для того, чтобы маршрутизатор мог обобщить наибольшее количество маршру­тов в одном, план адресов должен быть организован иерархическим образом. Такой поход особенно важен при использовании масок VLSM.

Обобщение маршрутов во фрагментарной сети

Основанные на классах протоколы маршрутизации автоматически выполняют обобщение маршрутов на границах сети. Такое поведение, которое не может быть из­менено протоколами RIPvl или IGRP, имеет приведенные ниже важные следствия.

• В крупных сетях различного типа подсети не анонсируются.

• Сети, не являющиеся непрерывными, невидимы друг для друга.

На рис. 2.11 протокол RIPvl не анонсирует подсети 172.16.5.0 255.255.255.0 и 172.16.6.0 255.255.255.0, поскольку этот протокол не может анонсировать подсе­ти; оба маршрутизатора, маршрутизатор А и маршрутизатор В анонсируют этот маршрут 172.16.0.0. Однако это приводит к путанице при маршрутизации через сеть 192.168.14.0. В этом примере маршрутизатор С получает маршруты, относя­щиеся к сети 172.16.0.0, с двух различных направлений, вследствие чего не может принять правильного решения о маршрутизации.

Рис. 2.11. Обобщение маршрутов во фрагментирован­ных сетях

Возникшую проблему можно разрешить путем использования какого-либо из протоколов: RIPv2, OSPF, IS-IS или EIGRP, однако не следует использовать обоб­щение маршрутов, поскольку маршруты подсетей будут анонсированы вместе с их нынешними масками подсетей.

Программное обеспечение IOS Cisco также предоставляет функцию ненумерован­ных IР-(адресов), которая позволяет разделять фрагментированные сети ненумеро­ванным каналом. Ненумерованным называется канат, который может еще не иметь назначенного номера IP-адреса, однако его видят другие подсети, что позволяет пре­дотвратить разрывы в каналах. Наличие ненумерованного канала без использования IP- функции ненумерованного канала может привести к разрывам в каналах.

Флэппинг маршрутов

Флэппинг маршрутов происходит в том случае, когда интерфейс маршрутизатора быстро переходит из состояния “включен” в состояние “выключен” (“up” and “down” states). Это явление может вызываться рядом причин, в том числе неисправностью ин­терфейса или плохо терминированной средой передачи.

Обобщение маршрутов эффективно изолирует находящиеся в восходящем на­правлении маршрутизаторы от проблем флэппинга. Если интерфейс маршрутизато­ра RTC, подсоединенный к сети 200.199.56.0 выходит из строя, то RTC удалит этот маршрут из своей таблицы маршрутизации. Если бы эти маршрутизаторы не были сконфигурированы для to обобщения маршрутов, то RTC отправил бы срочное (неплановое) сообщение маршрутизатору RTZ об удалении сети 200.199.56.0. В свою очередь маршрутизатор RTZ отправил бы сообщение обновления маршрутизатору в восходящем направлении и т.д. Каждый раз, когда на эти маршрутизаторы посту­пает новая информация, их процессоры приступают к работе. Эта работа может по­требовать довольно больших вычислительных затрат и повлиять на производитель­ность работы сети ( особенно в случае OSPF-маршрутизации).

Рассмотрим какое влияние на производительность сети оказывает восстановление через несколько секунд работоспособности интерфейса маршрутизатора RTC, связанного с се­тью 200.199.56.0. Маршрутизаторы посылают друг другу сообщения обновления и заново пересчитывают маршруты. Кроме того, что произойдет если через несколько секунд канал RTC вновь выйдет из строя? А затем вновь вернется в работоспособное состояние? Такая ситуация называется флэппингом и она делает маршрутизатор практически неработоспо­собным, поскольку он “завален” сообщениями обновлений и пересчетами маршрутов.

Однако конфигурирование обобщения маршрутов предотвращает воздействие флэппинга маршрута RTC на другие маршрутизаторы. Маршрутизатор RTC посылает RTZ сообщение обновления о суперсети (200.199.56.0 /21), которая включает в себя восемь сетей (от 200.199.56.0 до 200.199.63.0). при этом потеря одной сети не делает не­действительным маршрут к суперсети. Хотя маршрутизатор RTC может оказаться по­стоянно занятым своим собственным флэппингом на маршруте, маршрутизатор RTZ и все находящиеся в восходящем направлении маршрутизаторы ничего не заметят. Та­ким образом, обобщение маршрутов эффективно изолирует другие маршрутизаторы от проблемы флэппинга маршрута.