RIP. Динамическая маршрутизация #2

Итак, продолжая историю про RIP и маршрутизацию.

В прошлый раз я закончил на том, что у этого (первого протокола динамической маршрутизации) был один изъян - его медлительность. Это не единственное, в чём он так откровенно плох.

Петли маршрутов - вот это действительно плохо. Как это проявляется?

Допустим у вас есть центральный офис, и два дополнительных.

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

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

И они смотрят друг на друга такими маршрутами и эти маршруты будут работать ещё 30 секунд, пока RIP не скажет иначе. Попадая в такой канал, с пин-понгом маршрутов, трафик начинает ходить между роутерами до тех пор пока не истратит свой TTL (а это, в дефолтной сети, 120 раз для каждого пакета). Количество трафика, до наполнения канала полностью, возрастает мгновенно и канал перестаёт функционировать нормально. А так как сам RIP обменивается маршрутами простыми широковещательными рассылками, эти два соседа не могут передать друг другу информацию о изменениях. Петля в таком состоянии может жить ещё очень долго, даже после того как основной роутер уже поднялся, сходимость сети не гарантируется.

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

В качестве итога:

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

Однако даже это не спасло протокол, т.к. в момент рождения он уже был слабо пригоден ("как протокол назовёшь") для его современного (в тот момент) применения. Хотя это и не остановило разработчиков, RIP поддерживался вплоть до Windows Server 2008 R2 и включён по-умолчанию в Windows XP при создании PPTP соединения (простите, но историю поддержки в *nix я не скажу, т.к. и сейчас вы можете его там завести, как и на цисках).

На смену RIP пришла целая куча протоколов, среди который, родной для Cisco IGRP (или его продвинутая версия EIGRP), открытый и любимый многими OSPF, крутой и основной для Интернета BGP, а так же тёмный брат и повелитель всея сетей IS-IS (мета протокол, от мала до велика, от IP до IPX).

И каждый из этих протоколов, на своём старте, всегда ссылался на RIP для сравнения (по всем аспектам делая старика и высмеивая его непродуманную архитектуру). Да вот только, кто ж в 69-том году мог подумать, что нам вздумается строить сеть из сотен маршрутизаторов всего лишь для компании среднего размера (когда-то это был весь интернет).

Stay connected and don't use RIP

https://t.me/cooladmin