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

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

Вовлекаемые процессы

Начнем с того, что в построении и обслуживании таблицы маршрутизации вовлекаются три процесса:

Различные процессы маршрутизации, которые работают на сетевых проколах маршрутизации, таком как Дистанционно векторный протокол маршрутизации (Enhanced Interior Gateway Routing Protocol,EIGRP), Пограничный протокол маршрутизации (Border Gateway Protocol ,BGP), Intermediate System-to-Intermediate System (IS-IS) и протокол поиска наикратчайшего пути (Open Shortest Path First ,OSPF)
Сама роутинговая таблица, которая принимает информацию от процесса маршрутизации, и также отвечает на запросы процесса пересылки
Процесс пересылки, который запрашивает информацию из таблицы маршрутизации, чтобы выдать решение о пересылке пакета

Рассмотрим взаимодействие между протоколом маршрутизации и таблицей маршрутизации, чтобы понять, как строится эта таблица маршрутизации

Построение таблицы маршрутизации

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

Административная дистанция - это мера достоверности источника маршрута. Если маршрутизатор изучил о месте назначения более чем от одного протокола маршрутизации, сравнивается административная дистанция и предпочтение отдается маршрутам чья административная дистанция меньше
Метрика – это мера, используемая протоколом маршрутизации для вычисления наилучшего пути к любому данному месту назначения, если протокол изучает несколько путей к оному и тому же месту назначения. Каждый протокол маршрутизации использует различные метрики.
Длина префикса

Поскольку каждый протокол маршрутизации принимает обновления и другую информацию, он выбирает наилучший путь к данному месту назначения и пытается инсталлировать этот путь в таблицу маршрутизации. Например, если EIGRP изучает путь к 10.1.1.0/24 и решает, что данный путь является самым лучшим EIGRP путем к месту назначения, он пытается инсталлировать данный путь в таблицу маршрутизации.
Маршрутизатор решает, инсталлировать или нет маршруты представленные процессом маршрутизации основываясь на административной дистанции. Если этот путь имеет наименьшую административную дистанцию к месту назначения (во время сравнения с другими маршрутами в таблице), он инсталлируется в роутинговую таблицу. Если маршрут не является маршрутом с лучшей административной дистанцией, тогда маршрут отвергается.

Давайте рассмотрим следующий пример. Предположим роутер имеет четыре работающих процесса маршрутизации: EIGRP, OSPF, RIP, и IGRP. Сейчас все четыре процесса изучили ряд маршрутов к сети 192.168.24.0/24 и каждый выбрал свой лучший путь к этой сети через свои внутренние метрики. Каждый из четырех процессов пытается инсталлировать свой маршрут на сеть 192.168.24.0/24. Процесс маршрутизации обрабатывает административную дистанцию каждого протокола, которая используется для решения того, какой маршрут будет инсталлирован.

Следующая табличка показывает Административные дистанции для каждого протокола, назначенные по умолчанию

Connected – 0
Static - 1
eBGP - 20
EIGRP (internal) – 90
IGRP – 100
OSPF – 110
IS-IS – 115
RIP – 120
EIGRP (external) – 170
iBGP – 200
EIGRP summary route – 5

Поскольку внутренний EIGRP маршрут имеет самую лучшую административную дистанцию (чем меньше, тем лучше, не забыли?), то он и будет проинсталлирован в таблицу маршрутизации.

Резервные маршруты

А что же делают другие протоколы RIP, IGRP, OSPF со своими маршрутами, которые не были проинсталлированы? Что будет если самый предпочтительный маршрут, изученный из EIGRP, упадет? Cisco IOS использует два подхода для решения данной проблемы. Во первых: каждый процесс маршрутизации периодически пытается инсталлировать свои лучшие маршруты. Если самый предпочтительный маршрут упал (нет канала связи или отказал соседний маршрутизатор), следующий лучший маршрут (в соответствие с административной дистанцией) будет успешно инсталлирован при очередной попытке.
Второе решение: Для протокола который не смог инсталлировать свой маршрут, необходимо зарегистрировать маршрут как резервный и сказать процессу обслуживающему таблицу маршрутизации послать сообщение, если лучший маршрут упадет.

Для протоколов которые не имеют своих собственный таблиц с информацией о маршрутизации, такие как IGRP, используется первый метод. Каждый раз когда IGRP принимает обновления о маршруте, он пытается инсталлировать обновленную информацию в таблицу маршрутизации. Если в таблице уже существует маршрут на данную сеть, то попытка инсталляции завершается неудачно.
Для протоколов которые имеют свои собственные базы данных с информацией о маршрутизации, такие как, EIGRP, IS-IS, OSPF, BGP, и RIP, регистрируется резервный маршрут, когда первая попытка инсталляции в таблицу маршрутизации завершается неудачей. Если маршрут инсталлированный в таблицу маршрутизации падает по некоторым причинам, процесс обслуживающий таблицу маршрутизации вызывает каждый роутинговый протокол, который зарегистрировал резервный маршрут и просит его переинсталировать маршрут в таблицу маршрутизации. Если существуют несколько протоколов с зарегистрированными маршрутами, предпочтительный маршрут выбирается на основе административной дистанции.

Настраиваем административную дистанцию.

Административная дистанция по умолчанию может не всегда отвечать нуждам вашей сети. Вам может быть нужно, например, чтобы RIP маршруты были предпочтительными над IGRP маршрутами. Однако, изменение административной дистанции для протокола маршрутизации может быть опасным. Изменение значений по умолчанию может привести к петлям маршрутизации и другим странностям в вашей сети. Мы рекомендуем изменять административную дистанцию с осторожностью и только после того, как вы хорошо подумали и еще раз подумали. Для протокола маршрутизации, изменение административной дистанции достаточно легко: просто настраиваете дистанцию с помощью команды distance в конфигурационном режиме протокола маршрутизации. Вы также можете изменить дистанцию для маршрутов изученных от одного источника только в некоторых протоколах или вы можете изменить дистанцию только для нескольких маршрутов.

Для статических маршрутов вы можете изменить дистанцию для маршрута введя числовое значение после команды ip route

ip route network subnet mask next hop distance

Например,

ip route 192.168.1.0 255.255.255.0 192.168.1.1 100

Теперь маршрут на сеть 192.168.1.0/24 имеет административную дистанцию 100. Однако, вы не можете изменить дистанцию для всех статических маршрутов за один раз.

Как Метрика определяет выбор маршрута.

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

Длина префикса

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

EIGRP (internal): 192.168.32.0/26
RIP: 192.168.32.0/24
OSPF: 192.168.32.0/19

Какой из этих маршрутов будет инсталлирован в таблицу маршрутизации? Поскольку внутренние маршруты EIGRP имеют наилучшую административную дистанцию, можно предположить, что будет инсталлирован первый маршрут. Однако, поскольку каждый из этих маршрутов имеет различную длину префикса (маску подсети), они рассматриваются как различные приемники и все будут инсталлированы в таблицу.

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

Выполнение решения о пересылке

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

router# show ip route
     ....
     D   192.168.32.0/26 [90/25789217] via 10.1.1.1
     R   192.168.32.0/24 [120/4] via 10.1.1.2
     O   192.168.32.0/19 [110/229840] via 10.1.1.3
     ....

Если пакет, предназначенный для 192.168.32.1 прибывает на интерфейс маршрутизатора, какой из маршрутов выберет роутер? Это зависит от длины префикса или количества бит установленных в маске подсети. Более длинный префикс предпочтителен чем короткий.
В этом случае, пакет предназначенный для 192.168.32.1 направляется к узлу 10.1.1.1, поскольку адрес 192.168.32.1 попадает в сеть 192.168.32.0/26 (192.168.32.0 до 192.168.32.63). Он также попадает и в два других доступных маршрута, но 192.168.32.0/26 имеет самый длинный префикс в таблице (26 бит против 24 или 19).

Точно также, если пакет, предназначенный для 192.168.32.100 прибывает на один из интерфейсов роутера, он пересылается к 10.1.1.2, так как 192.168.32.100 не попадает в сеть 192.168.32.0/26, но попадает в сеть 192.168.32.0/24 и в сеть 192.168.32.0/19. Но сеть 192.168.32.0/24 имеет более длинный префикс.

IP Classless

Нас иногда часто запутывает команда ip classless когда встречается в конфигурации роутера. В действительности эта команда влияет только на работу процесса пересылки в IOS. Она не влияет на способ которым строится таблица маршрутизации. Если ip classless не конфигурирована (используется команда no ip classless), маршрутизатор не пересылает пакеты на суперсети (supernet). В качестве примера, снова поместим три маршрута в таблицу маршрутизации.

router# show ip route
....
     172.30.0.0/16 is variably  subnetted, 2 subnets, 2 masks
D        172.30.32.0/20 [90/4879540] via  10.1.1.2
D       172.30.32.0/24  [90/25789217] via 10.1.1.1
S*   0.0.0.0/0 [1/0] via 10.1.1.3

Помним, что сеть 172.30.32.0/24 включает адреса с 172.30.32.0 до 172.30.32.255, а сеть 172.30.32.0/20 включает адреса с 172.30.32.0 до 172.30.47.255. Теперь попытаемся скоммутировать три пакета через такую таблицу и посмотреть на результат.

пакет предназначенный для 172.30.32.1 пересылается к 10.1.1.1, поскольку маршрут имеет самый длинный префикс
пакет предназначенный для 172.30.33.1 пересылается к 10.1.1.2, поскольку маршрут имеет самый длинный префикс
пакет предназначенный для 192.168.10.1 пересылается к 10.1.1.3; поскольку сеть не существует в таблице маршрутизации и используется маршрут по умолчанию.
пакет предназначенный для 172.30.254.1 отбрасывается.

Неожиданным ответом из этих четырех является последний пакет, который отбрасывается. Он отбрасывается потому, что место назначение 172.30.254.1 лежит в известной основной сети 172.30.0.0/16, но роутер не знает о данной подсети этой основной сети.

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

Роутер удаленного офиса конфигурирован как:

interface Serial 0
     ip address 10.1.2.2 255.255.255.0
   !
   interface Ethernet 0
     ip address 10.1.1.1 255.255.255.0
   !
   ip route 0.0.0.0 0.0.0.0 10.1.2.1
   !
   no ip classles

В этой конфигурации хосты удаленного офиса могут достичь хостов в Интернет (через облако 10.x.x.x), но не хостов самого облака 10.x.x.x, которое является корпоративной сетью. Поскольку удаленный роутер знает о некоторой части сети 10.0.0.0/8 - двух напрямую подключенных подсетях, но больше не знает ни о каких других подсетях 10.x.x.x, он полагает, что другие подсети не существуют и отбрасывает любые пакеты предназначенные для них. Трафик в Интернет, в любом случае не попадает в диапазон 10.x.x.x и поэтому корректно маршрутизируется через маршрут по умолчанию.

Выполние команды ip classless на удаленном маршрутизаторе решит проблему, разрешив роутеру игнорировать классовые границы сетей в своей таблице маршрутизации.

На заметку: Если суперсеть или маршрут по умолчанию изучен через IS-IS или OSPF, то команда no ip classless игнорируется.

По материалам: cisco.com

Источник: CiscoLab.ru

Инструменты Internet Explorer 8 Beta 2 для разработчиков.

В марте этого года мы уже писали об инструментах для разработчика в IE8 Beta 1, но IE8 Beta2 позволяет более полно использовать инструменты за счет значительных изменений в имеющихся функциях, а также новых возможностей. В принципе инструменты для разработчика должны обладать следующими свойствами: Быть интегрированными и простыми в использовании; Иметь визуальный интерфейс; C их помощью можно быстро протестировать сайт.

Дата проведения: 28 октября 2008 г.; Место проведения: Амбер Плаза, Москва, Россия. Конференция для веб-разработчиков и разработчиков мобильных приложений в Москве. Узнайте, как наилучшим образом использовать инструменты разработки и API от Google, чтобы создавать социальные, мобильные и картографические приложения, как использовать AJAX/JavaScript инструменты и библиотеки от Google и многое другое из первых уст.

ТОП 10 самых раздражающих факторов для программиста.

Совсем недавно наткнулся в интернете на забавный "хит-парад" наиболее раздражающих вещей для программиста. Поскольку он был на английском — решил перевести текст и несколько адаптировать к нашим реалиям…