⚡ ѕ–ќ…ƒ» Ќќ¬џ… ќЌЋј…Ќ  ”–— ѕќ —≈“≈¬џћ “≈’ЌќЋќ√»яћ —ќ — »ƒ ќ… 50%

до конца скидки осталось

Ќачать обучение 🚀
ћерион Ќетворкс

21 минута чтени€

ѕротокол RIP (Routing Information Protocol)

ѕротокол Routing Information Protocol (RIP) был первоначально указан в RFC1058. ѕротокол Routing Information Protocol опубликован в 1998 году. ѕротокол был обновлен в серии более поздних RFC, включа€ RFC2435, RIP версии 2,3 и RFC2080, RIP Next Generation дл€ IPv6.

ќбучайс€ в Merion Academy

ѕройди курс по
сетевым технологи€м

Ќачать

–исунок 1 используетс€ дл€ объ€снени€ работы RIP.

–ис.1 ѕример работы RIP

–абота RIP обманчиво проста. Ќа рисунке 1:

  1. A обнаруживает 2001:db8:3e8:100::/64, поскольку он настроен на непосредственно подключенный интерфейс.
  2. A добавл€ет этот пункт назначени€ в свою локальную таблицу маршрутизации со стоимостью 1.
  3. ѕоскольку 100 :: / 64 установлен в локальной таблице маршрутизации, A будет анонсировать этот достижимый пункт назначени€ (маршрут) дл€ B и C.
  4.  огда B получает этот маршрут, он добавл€ет стоимость вход€щего интерфейса, чтобы путь через A имел стоимость 2, и провер€ет свою локальную таблицу на предмет любых других более дешевых маршрутов к этому месту назначени€. ѕоскольку у B нет другого пути к 100::/64, он установит маршрут в своей таблице маршрутизации и объ€вит маршрут к E.
  5.  огда C получает этот маршрут, он добавит стоимость вход€щего интерфейса, чтобы путь через A имел стоимость 2, и проверит свою локальную таблицу на предмет любых более дешевых маршрутов к этому пункту назначени€. ѕоскольку у C нет другого пути к 100 :: / 64, он установит маршрут в своей таблице маршрутизации и объ€вит маршрут D и E.
  6.  огда D получает этот маршрут, он добавл€ет стоимость вход€щего интерфейса от C, чтобы путь через C имел стоимость 3, и провер€ет свою локальную таблицу на предмет любых более дешевых маршрутов к этому месту назначени€. ѕоскольку у D нет другого пути к 100 :: / 64, он установит маршрут в свою таблицу маршрутизации и объ€вит маршрут к E.
  7. E теперь получит три копии одного и того же маршрута; один через C со стоимостью 3, один через B со стоимостью 4 и один через D со стоимостью 5. E выберет путь через C со стоимостью 2, установив этот путь на 100 :: / 64 в свою локальную таблицу маршрутизации.
  8. E не будет объ€вл€ть какой-либо путь к 100 :: / 64 к C, потому что он использует C как лучший путь дл€ достижени€ этого конкретного пункта назначени€. “аким образом, E выполнит split horizon своего объ€влени€ 100 :: / 64 в сторону C.
  9. ¬ то врем€ как E будет объ€вл€ть свой лучший путь через C как D, так и B, ни один из них не выберет путь через E, поскольку у них уже есть лучшие пути к 100 :: / 64. RIP объ€вл€ет набор пунктов назначени€ и определ€ет стоимость в один прыжок за раз через сеть. —ледовательно, он считаетс€ протоколом вектора рассто€ни€. ѕроцесс, который RIP использует дл€ поиска набора безцикловых путей через сеть, считаетс€ распределенной формой алгоритма Ѕеллмана-‘орда, но не совсем €сно, как процесс, который использует RIP, св€зан с Ѕеллманом-‘ордом.

—в€зь Bellman-Ford с RIP

„тобы увидеть соединение, лучше всего представить каждый переход в сети как одну строку в таблице топологии. Ёто отображено на рисунке 2.

–ис. 2 RIP и Bellman-Ford

–аздел Ђѕути одноадресной передачи без петельї, описывает работу Bellman-Ford с таблицей топологии, организованной как набор столбцов и строк. »спользу€ номера строк, показанные на рисунке 2, вы можете построить аналогичную таблицу топологии дл€ этой сети, как показано в таблице 1.

“аблица є 1 “аблица топологии, созданна€ из сети на рисунке 2

ѕредположим, что кажда€ строка таблицы проходит через алгоритм Ѕеллмана-‘орда другим узлом. Ќапример, A вычисл€ет Ѕеллмана-‘орда по первой строке и передает результат B. јналогичным образом, B вычисл€ет Bellman-Ford по соответствующим строкам и передает результат C. Ѕеллман-‘орд по-прежнему будет алгоритмом, используемым дл€ вычислени€ набор без петель в сети. ќн просто будет распределен по узлам в сети. ‘актически, так работает RIP. ”чтите следующее:

  1. A вычисл€ет первую строку в таблице, устанавлива€ предшественника дл€ 100::/64 в A и стоимость в 1. A передает этот результат B дл€ второго раунда обработки.
  2. B обрабатывает вторую строку в таблице, устанавлива€ дл€ предшественника 100 :: / 64 значение B, а стоимость - 2. B передает этот результат C дл€ третьего раунда обработки.
  3. C обрабатывает вторую строку в таблице, устанавлива€ дл€ предшественника 100 :: / 64 значение C, а стоимость - 2. C передает этот результат в D. –аспределенную обработку Ѕеллмана-‘орда труднее увидеть в более сложных топологи€х, потому что по сети передаетс€ более одной Ђтаблицы результатовї. ќднако эти Ђтаблицы результатовї в конечном итоге объедин€тс€ на исходном узле. –исунок 3 иллюстрирует это.
–ис. 3 ѕараллельное распространение Bellman-Ford

Ќа рисунке 3 A вычислит предварительную таблицу результатов в качестве первого Ђраундаї алгоритма Ѕеллмана-‘орда, передав результат как B, так и E. B вычислит предварительный результат на основе локальной информации, передав его в C, а затем из C в D. “аким же образом E вычислит предварительную таблицу результатов на основе локальной информации, передав ее в F, а затем F в D. ¬ D два предварительных результата объедин€ютс€ в окончательную таблицу с точки зрени€ D.  онечно, предварительна€ таблица считаетс€ окончательной дл€ устройства на каждом шаге. — точки зрени€ E, таблица, которую он вычисл€ет на основе локально доступной информации и объ€влени€ от A, €вл€етс€ финальной таблицей путей без петель дл€ достижени€ 100::/64.

¬есь распределенный процесс имеет тот же эффект, что и хождение по каждой строке в таблице топологии столько же раз, сколько записей в самой таблице топологии, медленно сортиру€ пол€ предшественника и стоимости дл€ каждой записи на основе вновь установленных предшественников в предыдущем раунде вычислений.

–еакци€ на изменени€ топологии

 ак RIP удал€ет информацию о доступности из сети в случае отказа узла или канала? –исунок 4 используетс€ дл€ объ€снение этого случа€.

–ис. 4 —бой канала в сети RIP

¬ зависимости от версии и конфигурации RIP, работающего в этой сети, существует две возможные реакции на потерю канала [A, B]. ѕерва€ возможна€ реакци€ - просто дать тайм-аут информации о 100::/ 64. ѕредполага€, что недействительный таймер (форма таймера удержани€) дл€ любого заданного маршрута составл€ет 180 секунд (обычна€ настройка в реализаци€х RIP):

  • B немедленно заметит сбой св€зи, поскольку он подключен напр€мую, и удалит 100 :: / 64 из своей локальной таблицы маршрутизации.
  • B прекратит объ€вл€ть достижимость 100 :: / 64 в направлении C.
  • C удалит доступность к этому месту назначени€ из своей локальной таблицы маршрутизации и прекратит объ€вл€ть достижимость от 100 :: / 64 до D через 180 секунд после того, как B перестанет объ€вл€ть достижимость до 100 :: / 64.
  • D удалит доступность к этому месту назначени€ из своей локальной таблицы маршрутизации через 180 секунд после того, как C прекратит объ€вл€ть достижимость до 100 :: / 64.

Ќа этом этапе сеть сконцентрировалась на новой информации о топологии. ќчевидно, что это довольно медленный процесс, так как каждый переход должен ждать, пока каждый маршрутизатор, ближайший к месту назначени€, отсчитает врем€, прежде чем обнаружит потерю соединени€.

„тобы ускорить этот процесс, большинство реализаций RIP также включают инициированные обновлени€. ≈сли инициированные обновлени€ реализованы и развернуты в этой сети, когда канал [A, B] выйдет из стро€ (или будет удален из службы), B удалит доступность 100 :: / 64 из своей локальной таблицы и отправит инициированное обновление в C, информацию C о неудавшейс€ достижимости к месту назначени€. Ёто инициируемое обновление обычно принимает форму объ€влени€ с бесконечной метрикой, или, скорее, того, что известно как €довитый реверс. »нициируемые обновлени€ часто выполн€ютс€ с заданной скоростью, поэтому колеблющеес€ соединение не приведет к тому, что сами инициированные обновлени€ не будут перегружать канал или соседний маршрутизатор.

ƒва других таймера указаны в RIP дл€ использовани€ во врем€ схождени€: flush timer и hold-down timer. ѕо истечении времени ожидани€ маршрута (как описано выше) он не удал€етс€ сразу из локальной таблицы маршрутизации. ¬место этого устанавливаетс€ другой таймер, который определ€ет, когда маршрут будет удален из локальной таблицы. Ёто flush timer.  роме того, существует отдельный период времени, в течение которого любой маршрут с метрикой хуже, чем ранее известна€, не будет приниматьс€. Ёто hold-down timer. ѕодведение итогов- RIP

RIP несет информацию о локально достижимых пунктах назначени€ сосед€м, а также стоимость дл€ каждого пункта назначени€. —ледовательно, это протокол вектора рассто€ни€. ƒостижимые пункты назначени€ изучаютс€ через локальную информацию на каждом устройстве и передаютс€ по сети протоколом независимо от потока трафика; следовательно, RIP-это проактивна€ плоскость управлени€.

RIP не формирует смежности дл€ надежной передачи данных по сети. —корее, RIP полагаетс€ на периодически передаваемые обновлени€, чтобы гарантировать, что информаци€ не устарела или не была случайно сброшена.  оличество времени, в течение которого хранитс€ люба€ часть информации, основано на таймере удержани€ (hold-down timer), а частота передач основана на таймере обновлени€ (lush timer). “аймер удержани€ обычно устанавливаетс€ в три раза больше значени€ таймера обновлени€.

ѕоскольку RIP не имеет истинного процесса смежности, он не определ€ет, существует ли двусторонн€€ св€зь- следовательно, нет двусторонней проверки подключени€ (Two-Way Connectivity Check-TWCC). ¬ RIP также не встроен метод проверки MTU между двум€ сосед€ми.


Enhanced Interior Gateway Routing Protocol

Enhanced Interior Gateway Routing Protocol (EIGRP) был выпущен в 1993 году дл€ замены протокола Interior Gateway Routing Protocol (IGRP) компании Cisco. ќсновной причиной замены IGRP была его неспособность передавать информацию о классовой маршрутизации. ¬ частности, IGRP не может переносить маски подсети. ¬место того, чтобы перестраивать протокол дл€ поддержки длины префикса, инженеры Cisco (в частности, ƒино ‘ариначчи и Ѕоб ќлбритсон) решили создать новый протокол, основанный на алгоритме диффузного обновлени€ √арсиа-Ћуны (Diffusing Update Algorithm-DUAL). ƒэйв  ац перестроил транспорт, чтобы решить некоторые часто встречающиес€ проблемы в середине 1990-х годов. ќсновыва€сь на этой первоначальной реализации, команда под руководством ƒонни —эвиджа в 2000-х годах сильно изменила работу протокола, добавив р€д функций масштабировани€ и переписав ключевые части реакции EIGRP на изменени€ топологии. ѕротокол EIGRP был выпущен вместе с практически всеми этими улучшени€ми в RFC7868 в 2013 году.

¬ то врем€ как EIGRP не часто рассматриваетс€ дл€ активного развертывани€ в большинстве сетей поставщиков услуг (большинство операторов предпочитают протокол состо€ни€ канала), DUAL вводит некоторые важные концепции в обсуждение о безцикловых пут€х. DUAL также используетс€ в других протоколах, таких как BABEL (указанный в RFC 6126 и используемый в простых домашних сет€х).

ћетрики EIGRP

ѕервоначально протокол EIGRP был разработан дл€ считывани€ полосы пропускани€, задержки, частоты ошибок и других факторов с каналов в режиме, близком к реальному времени, и передачи их в качестве метрик. Ёто позволит EIGRP реагировать на изменение сетевых условий в реальном времени и, следовательно, позволит сет€м, на которых запущен EIGRP, более эффективно использовать доступные сетевые ресурсы. ќднако в при первоначальном развертывании EIGRP, не существовало Ђзащитных огражденийї дл€ предотвращени€ петель обратной св€зи между, например, реакцией протокола на изменени€ доступной полосы пропускани€ и сдвигами в трафике в зависимости от доступной полосы пропускани€. ≈сли пара каналов с доступной полосой пропускани€, близкой к реальному времени, была размещена параллельно друг другу, трафик переключитс€ на канал с наиболее доступной полосой пропускани€, в результате чего протокол будет реагировать, показыва€ большую доступную полосу пропускани€ на другом канале, улучша€ его метрики и следовательно, трафик переместитс€ на другую линию св€зи. Ётот процесс переключени€ трафика между лини€ми может быть решен различными способами, но он вызывал достаточно проблем в ранних развертывани€х EIGRP дл€ того, чтобы эту возможность почти реального времени можно было удалить из кода. ¬место этого EIGRP считывает характеристики интерфейса в определенное врем€ и объ€вл€ет эти показатели дл€ интерфейса независимо от сетевых условий.

EIGRP несет п€ть различных атрибутов маршрута, включа€ полосу пропускани€, задержку, нагрузку, надежность и MTU. „етыре показател€ объедин€ютс€ по формуле, показанной на рисунке 5.

–ис.5 ‘ормула расчета метрики EIGRP

«начени€ K по умолчанию в этой формуле привод€т к сокращению всей формулы до (107/throughput) * delay. «амена пропускной способности (throughput) минимальной полосой пропускани€ (bandwidth) дает версию, с которой знакомо большинство инженеров: (107 / bandwidth) * delay.

ќднако значени€ пропускной способности (bandwidth) и задержки (delay) масштабируютс€ в более поздних верси€х EIGRP дл€ учета каналов с пропускной способностью более 107 кбит/с.

ѕримечание.¬ ходе этого обсуждени€ EIGRP предполагаетс€, что полоса пропускани€ каждого канала установлена на 1000, а значени€ K установлены на значени€ по умолчанию, оставл€€ задержку в качестве единственного компонента, вли€ющего на метрику. ”читыва€ это, только значение задержки используетс€ в качестве метрики в этих примерах дл€ упрощени€ расчетов. –исунок 6 используетс€ дл€ описани€ работы EIGRP.
–ис. 6 ѕример сети дл€ изучени€ работы EIGRP

–абота EIGRP в этой сети на первый взгл€д очень проста:

  1. A обнаруживает 2001: db8: 3e8: 100 :: / 64, потому что он напр€мую подключен (например, через настройки интерфейса).
  2. A добавл€ет к маршруту стоимость вход€щего интерфейса, котора€ здесь показана как задержка (delay) 100, и устанавливает ее в свою локальную таблицу маршрутизации.
  3. A объ€вл€ет 100 :: / 64 B и C через два других подключенных интерфейса.
  4. B получает этот маршрут, добавл€ет стоимость вход€щего интерфейса (обща€ задержка 200) и провер€ет свою локальную таблицу на предмет любых других (или лучших) маршрутов к этому месту назначени€. ” B нет маршрута к 100 ::/64, поэтому он устанавливает маршрут в своей локальной таблице маршрутизации.
  5. B объ€вл€ет 100 :: / 64 дл€ D.
  6. C получает этот маршрут, добавл€ет стоимость вход€щего интерфейса (обща€ задержка 200) и провер€ет свою локальную таблицу на предмет любых других (или лучших) маршрутов к этому месту назначени€. ” C нет маршрута к 100 :: / 64, поэтому он устанавливает маршрут в своей локальной таблице маршрутизации.
  7. C объ€вл€ет 100 :: / 64 дл€ D.
  8. D получает маршрут к 100 ::/64 от B, добавл€ет стоимость вход€щего интерфейса (обща€ задержка 300) и провер€ет свою локальную таблицу на предмет любых других (или лучших) маршрутов к этому месту назначени€. D не имеет маршрута к этому месту назначени€, поэтому он устанавливает маршрут в своей локальной таблице маршрутизации.
  9. D получает маршрут к 100 :: / 64 от C, добавл€ет стоимость вход€щего интерфейса (обща€ задержка 400) и провер€ет свою таблицу на предмет любых других (или лучших) маршрутов к этому месту назначени€. D действительно имеет лучший маршрут к 100 :: / 64 через B, поэтому он вставл€ет новый маршрут в свою локальную таблицу топологии.
  10. D объ€вл€ет маршрут от 100 :: / 64 до E.
  11. E получает маршрут к 100 :: / 64 от D, добавл€ет стоимость вход€щего интерфейса (обща€ задержка 400) и провер€ет свою локальную таблицу на предмет любых других (или лучших) маршрутов к этому месту назначени€. E не имеет маршрута к этому месту назначени€, поэтому он устанавливает маршрут в своей локальной таблице маршрутизации.

¬се это очень похоже на работу RIP. Ўаг 9, однако, требует более подробного рассмотрени€. ѕосле шага 8 у D есть путь к 100 :: / 64 с общей стоимостью 300. Ёто допустимое рассто€ние до пункта назначени€, а B - преемник, так как это путь с наименьшей стоимостью. Ќа шаге 9 D получает второй путь к тому же месту назначени€. ¬ RIP или других реализаци€х Bellman-Ford этот второй путь либо игнорируетс€, либо отбрасываетс€. EIGRP, основанный на DUAL, однако, проверит этот второй путь, чтобы определить, свободен ли он от петель или нет. ћожно ли использовать этот путь, если основной путь не работает?

„тобы определить, €вл€етс€ ли этот альтернативный путь свободным от петель, D должен сравнить допустимое рассто€ние с рассто€нием, которое C сообщила как стоимость достижени€ 100 :: / 64 - за€вленное рассто€ние. Ёта информаци€ доступна в объ€влении, которое D получает от C (помните, что C объ€вл€ет маршрут с его стоимостью до пункта назначени€. D добавл€ет к нему стоимость канала [B, D], чтобы найти общую стоимость через C дл€ достижени€ 100: : / 64). —ообщаемое рассто€ние через C составл€ет 200, что меньше локального допустимого рассто€ни€, равного 300. —ледовательно, маршрут через C не имеет петель и помечен как возможный преемник.

–еакци€ на изменение топологии.

 ак используютс€ эти возможные преемники? ѕредположим, что канал [B, D] не работает, как показано на рисунке 7.

–ис. 7 »спользование возможного преемника

 огда этот канал выходит из стро€, D провер€ет свою таблицу локальной топологии, чтобы определить, есть ли у нее другой путь без петель к месту назначени€. ѕоскольку путь через C отмечен как возможный преемник, у D есть альтернативный путь. ¬ этом случае D может просто переключитьс€ на использование пути через C дл€ достижени€ 100 :: / 64. D не будет пересчитывать допустимое рассто€ние в этом случае, так как он не получил никакой новой информации о топологии сети.

„то, если вместо этого произойдет сбой соединени€ между C и A, как показано на рисунке 8?

–ис. 8 –еагирование сбой без веро€тного преемника в EIGRP

¬ этом случае до сбо€ у C есть два пути к 100 :: / 64: один через A с общей задержкой 200 и второй через D с общей задержкой 500. ¬озможное рассто€ние в C будет установлено на 200 , поскольку это стоимость наилучшего пути, доступного после завершени€ сходимости. —ообщаемое рассто€ние в D, 300, больше, чем возможное рассто€ние в C, поэтому C не будет отмечать путь через D как возможный преемник. ѕосле сбо€ канала [A, C], поскольку C не имеет альтернативного пути, он пометит маршрут как активный и отправит запрос каждому из своих соседей, запрашива€ обновленную информацию о любом доступном пути к 100 :: / 64.

 огда D получает этот запрос, он провер€ет свою таблицу локальной топологии и обнаруживает, что его лучший путь к 100 :: / 64 все еще доступен. ѕоскольку этот путь все еще существует, процесс EIGRP на D может предположить, что на текущий лучший путь через B не повли€л отказ канала [A, C]. D отвечает на этот запрос своей текущей метрикой, котора€ указывает, что этот путь все еще доступен и не имеет петель с точки зрени€ D.

ѕолучив этот ответ, C заметит, что он не ждет ответа от других соседей (поскольку у него только один сосед, D). ѕоскольку C получил все ответы, которых он ожидает, он пересчитает доступные пути без петель, выбрав D в качестве преемника, а стоимость через D в качестве допустимого рассто€ни€.

„то произойдет, если D никогда не ответит на запрос C? ¬ более старых реализаци€х EIGRP C устанавливал таймер, называемый Stuck in Active Timer. ≈сли D не отвечает на запрос C в течение этого времени, C объ€вит маршрут как Stuck in Active (SIA), и сбросит соседнюю смежность с помощью D. ¬ новых реализаци€х EIGRP C установит таймер, называемый таймером запроса SIA (Query timer).  огда этот таймер истечет, он повторно отправит запрос к D. ѕока D отвечает, что он все еще работает над ответом на запрос, C будет продолжать ждать ответа.

√де заканчиваютс€ эти запросы?  ак далеко будет распростран€тьс€ запрос EIGRP в сети? «апросы EIGRP завершаютс€ в одной из двух точек:

  •  огда у маршрутизатора нет других соседей дл€ отправки запросов;
  •  огда маршрутизатор, получающий запрос, не имеет никакой информации о пункте назначени€, на который ссылаетс€ запрос.

Ёто означает, что, либо на Ђконце сети EIGRPї (называемой автономной системой), либо на одном маршрутизаторе, за пределами какой-либо политики или конфигурации, скрывающей информацию о конкретных местах назначени€. Ќапример, один переход после точки, в которой маршрут агрегируетс€.

ƒиапазон запросов EIGRP и дизайн сети.

EIGRP всегда был известен как Ђпротокол, который будет работать в любой сетиї из-за его больших свойств масштабировани€ и очевидной способности работать в Ђлюбойї топологии без особой настройки. ќднако основным фактором, определ€ющим масштабирование EIGRP, €вл€етс€ диапазон запросов. ќсновна€ задача проектировани€ сети в сети EIGRP - ограничение объема запросов через сеть. ¬о-первых, диапазон запросов вли€ет на скорость схождени€ EIGRP: каждый дополнительный переход диапазона запроса добавл€ет небольшое количество времени к общему времени конвергенции сети (в большинстве случаев около 200 мс). ¬о-вторых, диапазон запросов вли€ет на стабильность сети. „ем дальше по сети должны проходить запросы, тем больше веро€тность того, что какой-то маршрутизатор не сможет сразу ответить на запрос. —ледовательно, наиболее важным моментом при проектировании сети на основе EIGRP в качестве протокола €вл€етс€ ограничение запросов посредством агрегации или фильтрации определенного типа.

ќбнаружение соседей и надежна€ передача.

EIGRP провер€ет двустороннюю св€зь между сосед€ми, канал MTU, и обеспечивает надежную передачу информации плоскости управлени€ через сеть путем формировани€ отношений соседей. –исунок 9 демонстрирует процесс формировани€ соседей EIGRP.

–ис. 9 ‘ормирование соседей EIGRP

Ўаги, показанные на рисунке 9, следующие:

  1. A отправл€ет многоадресное приветствие (multicast hello) по каналу, совместно используемому между A и B.
  2. B переводит A в состо€ние ожидани€. ѕока A находитс€ в состо€нии ожидани€, B не будет отправл€ть стандартные обновлени€ или запросы к A и не будет принимать ничего, кроме специально отформатированных обновлений от A.
  3. B передает пустое обновление с битом инициализации, установленным в A. Ётот пакет отправл€етс€ на адрес одноадресного интерфейса A.
  4. ѕри получении этого обновлени€ A отвечает пустым обновлением с установленным битом инициализации и подтверждением. Ётот пакет отправл€етс€ на адрес одноадресного интерфейса B.
  5. ѕолучив это одноадресное обновление, B переводит A в состо€ние подключени€ и начинает отправл€ть обновлени€, содержащие отдельные записи таблицы топологии, в сторону A. ¬ каждый пакет добавл€етс€ подтверждение дл€ предыдущего пакета, полученного от соседа.

ѕоскольку EIGRP не формирует смежности с наборами соседей, а только с отдельными сосед€ми, этот процесс обеспечивает доступность как одноадресной, так и многоадресной рассылки между двум€ маршрутизаторами, образующими смежность. „тобы гарантировать, что MTU не совпадает ни на одном конце канала, EIGRP заполн€ет определенный набор пакетов во врем€ формировани€ соседа. ≈сли эти пакеты не принимаютс€ другим маршрутизатором, MTU не совпадает, и отношени€ соседства не должны формироватьс€.

ѕримечание. EIGRP отправл€ет многоадресные приветстви€ (multicast hellos) дл€ обнаружени€ соседей по умолчанию, но будет использовать одноадресные приветстви€, если соседи настроены вручную.

ѕодведение итогов Ц EIGRP.

EIGRP представл€ет р€д интересных решений проблем, с которыми сталкиваютс€ протоколы маршрутизации при отправке информации по сети, вычислении путей без петель и реагировании на изменени€ топологии. EIGRP классифицируетс€ как протокол вектора рассто€ни€, использующий DUAL дл€ вычислени€ путей без петель и альтернативных путей без петель через сеть. EIGRP объ€вл€ет маршруты без прив€зки к потокам трафика через сеть, поэтому это проактивный протокол.


ѕротоколы вектора рассто€ни€ и таблица маршрутизации.

¬ большинстве дискуссий о протоколах вектора рассто€ни€- эти протоколы объ€сн€ютс€ таким образом, что подразумевает, что они работают полностью отдельно от таблицы маршрутизации и любых других процессов маршрутизации, запущенных на устройстве. ќднако это не так. ѕротоколы векторов рассто€ний взаимодействуют с таблицей маршрутизации не так, как протоколы состо€ни€ каналов. ¬ частности, протокол вектора рассто€ни€ не объ€вл€ет маршрут к пункту назначени€, который он не установил в локальной таблице маршрутизации.

Ќапример, предположим, что EIGRP и RIP работают на одном маршрутизаторе. EIGRP узнает о некотором пункте назначени€ и устанавливает маршрут к этому пункту назначени€ в локальной таблице маршрутизации. RIP узнает о б этом же месте назначени€ и пытаетс€ установить маршрут, который он узнал, в локальную таблицу маршрутизации, но ему это не удаетс€ - маршрут EIGRP перезаписывает (или переопредел€ет) маршрут, полученный RIP. ¬ этом случае RIP не будет анонсировать этот конкретный маршрут ни одному из своих соседей.

ƒл€ такого поведени€ есть две причины. ¬о-первых, маршрут, полученный через EIGRP, может указывать на совершенно другой следующий переход, чем маршрут, полученный через RIP. ≈сли метрики установлены неправильно, два протокола могут образовать посто€нную петлю пересылки в сети. ¬о-вторых, RIP не может узнать, насколько действителен маршрут EIGRP. ¬озможно, RIP объ€вл€ет маршрут, заставл€€ другие маршрутизаторы отправл€ть трафик локального устройства, предназначенный дл€ объ€вленного пункта назначени€, а затем локальное устройство фактически отбрасывает пакет, а не пересылает его. Ёто один из примеров black hole.

„тобы предотвратить возникновение любой из этих ситуаций, протоколы вектора рассто€ни€ не будут объ€вл€ть маршруты, которых сам протокол не имеет в локальной таблице маршрутизации. ≈сли маршрут протокола вектора рассто€ни€ будет перезаписан по какой-либо причине, он остановит объ€вление о доступности пункта назначени€.


>