Для предотвращения появления петель маршрутизации и зацикливания пакетов протоколы маршрутизации используют метод расщепления горизонта .Также эту проблему можно решать по средствам служебных сообщений, таймеров, и удаления маршрутов в обратном направлении, но в этой статье мы попытаемся пролить свет именно на технологию split horizon.
Использование метода расщепления горизонта основано на том, что , как правило, нет необходимости в отправке информации о маршруте в обратном направлении, точнее в том направлении, по которому этот маршрут поступил. С точки зрения здравого смысла и правил маршрутизации такой подход является оптимальным.
Но в некоторых конфигурациях сетей может оказаться целесообразным отключение механизма расщепления горизонта: отключение производится для каждого отдельного интерфейса отдельно!
Для отключения механизма используется команда split horizon совместно с ключевым словом no.
На одной из олимпиад по сетевым технологиям стояла задача по решению именно такой проблемы. И так, перейдем к примеру:
На схеме frame-relay облако и и serial – интерфейсы, подключенные к нему, под облаком подразумеваются глобальные линии связи , с различными протоколами маршрутизации и разными сетевыми технологиями, но с помощью packet tracert мы можем заменить это небольшой настройкой. Также настроен протокол маршрутизации RIP , и выглядит настройка следующим образом:
R0:
Router>en Router#conf t Router(config)#hostname R0
Конфигурируем интерфейсы:
R0(config)#interface fastEthernet 0/0 R0(config-if)#ip address 50.0.0.1 255.255.0.0 R0(config-if)#no shutdown R0(config)#interface serial 0/1/0 R0(config-if)#ip address 22.0.0.1 255.255.255.0 R0(config-if)#no shutdown
Задаем тип инкапсуляции:
R0(config-if)#encapsulation frame-relay
Далее указываем идентификаторы (DLCI), которые будут принадлежать этому интерфейсу, и с помощью которых другие устройства смогут взаимодействовать с настраиваемым.
R0(config-if)#frame-relay interface-dlci 100 R0(config-if)#frame-relay interface-dlci 200
Настраиваем мапинг для frame-relay, где число после ip – адреса – это уникальный идентификатор ,DLCI, номер должен быть уникальным, ключевое слово broadcast позволяет маршрутизатору рассылать широковещательные сообщения через уникальный идентификатор DLCI соседнему устройству (устройствам).
R0(config-if)#frame-relay map ip 22.0.0.2 100 broadcast R0(config-if)#frame-relay map ip 22.0.0.3 200 broadcast
Настраиваем протокол маршрутизации:
R0(config)#router rip R0(config-router)#network 50.0.0.0 R0(config-router)#network 22.0.0.0
R1:
Router>en Router#conf t Router(config)#hostname R1
Конфигурируем интерфейсы:
R1(config)#interface fa 0/0 R1(config-if)#ip address 100.0.0.1 255.255.0.0 R1(config-if)#no shutdown R1(config)#interface serial 0/1/0 R1(config-if)#ip address 22.0.0.2 255.255.255.0 R1(config-if)#no shutdown
Задаем тип инкапсуляции:
R1(config-if)#encapsulation frame-relay
Указываем DLCI на интерфейсе:
R1(config-if)#frame-relay interface-dlci 101
Настраиваем мапинг:
R1(config-if)#frame-relay map ip 22.0.0.1 101 broadcast
Настраиваем протокол маршрутизации:
R1(config)#router rip R1(config-router)#network 22.0.0.0 R1(config-router)#network 100.0.0.0
R2:
Router>en Router#conf t Router(config)#hostname R2
Конфигурируем интерфейсы:
R2(config)#interface fastEthernet 0/0 R2(config-if)#ip address 150.0.0.1 255.255.0.0 R2(config-if)#no shutdown R2(config)#interface serial 0/1/0 R2(config-if)#ip address 22.0.0.3 255.255.255.0 R2(config-if)#no shutdown
Задаем тип инкапсуляции:
R2(config-if)#encapsulation frame-relay
Указываем DLCI на интерфейсе:
R1(config-if)#frame-relay interface-dlci 201
Настраиваем мапинг:
R2(config-if)#frame-relay map ip 22.0.0.1 201 broadcast
Настраиваем протокол маршрутизации:
R2(config)#router rip R2(config-router)#network 150.0.0.0 R2(config-router)#network 22.0.0.0
Далее настроим облако так, чтобы DLCI на интерфейсах маршрутизаторов совпадали с DLCI на условных интерфейсах в облаке. Условных по тому что в нашем случае облако играет роль глобальных линий связи (internet):
И последняя настройка – это настройка взаимодействия DLCI внутри облака, нужно настроить так, чтобы R0 взаимодействовал с R1 и R2, при этом R1 и R2 не должны взаимодействовать между собой.
Из всех этих настроек видно что маршрутизация между сетью 100.0.0.0/16 и 150.0.0.0/16 происходит через R0, чему свидетельствует таблица маршрутизации :
Посмотреть таблицы маршрутизации можно командой :
show ip route
Также для диагностики вводим команду для просмотра мапинга frame-relay :
show frame-relay map
В то время как остальные маршрутизаторы могут обмениваться пакетами только с R0:
Из вывода мы видим что хосты из сети 50.0.0.0 могут взаимодействовать со всеми хостами:
Но из следующего вывода видно что маршрутизаторы R1 и R2 не получают информацию друг о друге и следовательно сети 100.0.0.0 и 150.0.0.0 не взаимодействуют !
В силу вступила технология расщепления горизонта, тем самым заблокировав работу сети. Маршрутная информация, приходя на R0 не уходила дальше, так как во всех этих процессах был задействован один интерфейс, который был и приемником и передатчиком.
Для исправления этой ситуации следует отменить split horizon на маршрутизаторе R0:
R0(config)#interface serial 0/1/0 R0(config-if)#no ip split-horizon
Надеюсь что материал получился понятным. Лабораторную с данной конфигурацией можно скачать внизу статьи.
Примечание :
Для нормальной работы конфигурации , после отключения и включения технологии расщепления горизонта,стоит очистить таблицу маршрутизации командой :
clear ip route *
Александр
Millenio
Morello
Так держать!!!
Статья, пальчики оближешь! Доходчиво, наглядно, лаконично. А лаба в конце статьи это просто вишенка на тортике!
Статья ни о чем. Толкового объяснения технологии нет, как работает – нет, зачем нужно – нет, подводных камней – нет. В стандартном ICND2 и то лучше описано.
Для того чтобы было доходчиво и пожевано – читайте многотомные мануалы! Или же пишите сами у нас на сайте. Ознакомтесь с политикой сайта, потом Вам станет понятно почему статья написана в такой форме!
спасибо, молодца
Гапон Анатолий, написано все хорошо. Но на практике отключение горизонта не есть решение, особенно в больших сетях (проблема петель). Быть можеть, будет лучше, если напишите статью об этом и рассмотрите другие варианты решения (субинтерфейсы или фулл-мэш топологии). Было бы интересно.
Всегда за, хотелось бы более конкретной постановки вопроса, использование sub-interfaces в каком-то роде описано здесь http://www.netconfig.org/routing/864, хотя это несколько не подходит для данного примера.