Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Скажите, а при отключении канала (но при этом с «живым» интерфейсом) вы собираетесь ехать в командировку в Якутск вертолётом и оленями МО РФ, чтобы ввести «shutdown» на интерфейсе? Или есть способы добиться надёжного автоматического переключения?
Команда отключения интерфейса была применена в целях эксперимента автоматического переключения с основного маршрута на резервный. К слову, для чего нам отключать работающий интерфейс?
На практике, далеко не всегда интерфейс «падает» сам. Очень часто интерфейс продолжает быть в up / up статусе, но трафик через него уже не проходит. По-этому в вашем описанном экспериментальном случае, применённом на практике, придётся кому-то ехать и руками делать «shutdown» интерфейсу. Так как добиться надёжного автоматического переключения, чтобы не приходилось никуда кататься?
Возможно, я чего то не понимаю. Не могли бы вы пояснить как этого добиться?
Так, всё. Не могу больше молчать. Ненавижу такие вот ситуации, когда ищешь решение своей проблемы, находишь «random blog from 2007” в котором описана твоя проблема, но вместо решения видишь последний пост как у вас. “Пф. Это же элементарно! Мы тоже столкнулись с этим и для решения всего лишь 행운을 빌어”
Поэтому я решил закрыть эту тему для будущих поколений.
Для начала разберёмся с понятиями. Насколько мне известно, рекурсивная маршрутизация случается, если в маршруте до сети назначения (или основного шлюза) next hop’ом указан не выходной интерфейс, а ip-адрес. В таком случае маршрутизатор вынужден вначале найти в таблице маршрутизации маршрут для пакета, а потом рекурсивно искать к какому интерфейсу принадлежит next hop.
Например:
ip route 10.0.0.0 255.255.255.0 1.2.3.4
Маршрутизатор получает пакет, адресованный в сеть 10.0.0.0/24, проверяет таблицу маршрутизации и видит next hop 1.2.3.4, но не видит интерфейс выхода. Поэтому он осуществляет рекурсивный поиск маршрута до 1.2.3.4 и находит, например, что сесть 1.2.3.4/28 directly connected к интерфейсу G 0/1 После чего маршрутизатор посылает пакет через этот интерфейс.
Также рекурсивным маршрутом может считаться маршрут, который доступен через другой маршрут.
Например:
ip route 20.0.0.0 255.255.255.0 8.8.8.8
ip route 0.0.0.0 0.0.0.0 20.0.0.0
В данном будет аж два рекурсивных поиска. Вначале маршрутизатор будет искать шлюз по умолчанию, потом маршрут до 20.0.0.0, потом интерфейс, к которому подключена сеть 8.8.8.8
Всё это интересно, но не отвечает на два вопроса:
1. Что такое „Рекурсивный маршрут через 8.8.8.8 или любой другой высокодоступный“?
2. Как такой маршрут должен помочь в ситуации из поста?
Для проблемы „Есть два IPS, основной и резервный, и нужно чтобы в случае падения основного трафик уходил через резервный“ мне известны два решения. Динамическая маршрутизация или эти самые плавающие маршруты, но с IP SLA.
Динамический маршруты годятся любые: хоть BGP соседство с обоими IPS, хоть RIP, ходящий в туннелях, построенных через обоих IPS. В любом случае после падения канала (и не обязательно с драматичным interface down) анонсы маршрутов перестают приходить со стороны упавшего провайдера и маршрутизатор начинает слать трафик через второго.
Решение ОПа с плавающими маршрутами тоже далеко не идеально. Прежде всего, как уже отметили ранее, далеко не всегда «интернет не работает» выглядит как упавший интерфейс. Провайдер может по ошибке создать у себя «чёрную дыру» которая будет отсылать все пакеты в null 0, но канал до самого провайдера будет поднят.
Кроме того, плавающий маршрут не удаляется из таблицы маршрутизации после того, как интерфейс до основного провайдера поднялся. Т.е. если даже интерфейс упадёт и плавающий маршрут пропишется в таблицу маршрутизации, то для возврата трафика на канал основного провайдера придётся руками ложить интерфейс резервного. Тогда плавающий маршрут пропадёт из таблицы маршрутизации и туда пропишется основной.
Это «не проблема» (на самом деле это очень кривое решение), если основной и резервный каналы равнозначны, но если основной – это оптика, а резервный – это ADSL модем, то хотелось бы, чтобы маршрутизатор переключался на основной канал автоматически.
Более того, схема с плавающим маршрутом может привести к ассиметричной маршрутизации. Если у нас есть два офиса, на которых настроены плавающие маршруты и канал до основного падает (а потом поднимается) с int down только на одном отрезке, то трафик будет уходить через один канал, а приходить через другой.
Для решения части этих проблем можно использовать IP SLA. Я не буду описывать настройки, только принцип. Конфигурация почти как в статье, только мы дополнительно создаём некое условие, которое уберёт основной маршрут из таблицы маршрутизации. Чаще всего, это условие -«пинг не проходит». Т.е. мы создаём «пинговалку», которая непрерывно пингует адрес основного провайдера. Как только пинг не проходит, маршрут до него удаляется из таблицы, туда прописывается плавающий маршрут и трафик идёт через резервного провайдера. Однако, в отличии от схемы из статьи, маршрутизатор не просто пассивно ждёт действий админа, а продолжает пинговать основного провайдера и вернёт маршрут через него в таблицу маршрутизации, как только пинг появится вновь. Это не решает проблемы со сбоем маршрутизации внутри самого провайдера, но, хотя бы, не требует руками передёргивать каналы, когда связь с основным ISP восстанавливается.
Поэтому я решил закрыть эту тему для будущих поколений.
Для начала разберёмся с понятиями. Насколько мне известно, рекурсивная маршрутизация случается, если в маршруте до сети назначения (или основного шлюза) next hop’ом указан не выходной интерфейс, а ip-адрес. В таком случае маршрутизатор вынужден вначале найти в таблице маршрутизации маршрут для пакета, а потом рекурсивно искать к какому интерфейсу принадлежит next hop.
Например:
ip route 10.0.0.0 255.255.255.0 1.2.3.4
Маршрутизатор получает пакет, адресованный в сеть 10.0.0.0/24, проверяет таблицу маршрутизации и видит next hop 1.2.3.4, но не видит интерфейс выхода. Поэтому он осуществляет рекурсивный поиск маршрута до 1.2.3.4 и находит, например, что сесть 1.2.3.4/28 directly connected к интерфейсу G 0/1 После чего маршрутизатор посылает пакет через этот интерфейс.
Также рекурсивным маршрутом может считаться маршрут, который доступен через другой маршрут.
Например:
ip route 20.0.0.0 255.255.255.0 8.8.8.8
ip route 0.0.0.0 0.0.0.0 20.0.0.0
В данном будет аж два рекурсивных поиска. Вначале маршрутизатор будет искать шлюз по умолчанию, потом маршрут до 20.0.0.0, потом интерфейс, к которому подключена сеть 8.8.8.8
Всё это интересно, но не отвечает на два вопроса:
1. Что такое „Рекурсивный маршрут через 8.8.8.8 или любой другой высокодоступный“?
2. Как такой маршрут должен помочь в ситуации из поста?
Для проблемы „Есть два IPS, основной и резервный, и нужно чтобы в случае падения основного трафик уходил через резервный“ мне известны два решения. Динамическая маршрутизация или эти самые плавающие маршруты, но с IP SLA.
Динамический маршруты годятся любые: хоть BGP соседство с обоими IPS, хоть RIP, ходящий в туннелях, построенных через обоих IPS. В любом случае после падения канала (и не обязательно с драматичным interface down) анонсы маршрутов перестают приходить со стороны упавшего провайдера и маршрутизатор начинает слать трафик через второго.
Решение ОПа с плавающими маршрутами тоже далеко не идеально. Прежде всего, как уже отметили ранее, далеко не всегда «интернет не работает» выглядит как упавший интерфейс. Провайдер может по ошибке создать у себя «чёрную дыру» которая будет отсылать все пакеты в null 0, но канал до самого провайдера будет поднят.
Кроме того, плавающий маршрут не удаляется из таблицы маршрутизации после того, как интерфейс до основного провайдера поднялся. Т.е. если даже интерфейс упадёт и плавающий маршрут пропишется в таблицу маршрутизации, то для возврата трафика на канал основного провайдера придётся руками ложить интерфейс резервного. Тогда плавающий маршрут пропадёт из таблицы маршрутизации и туда пропишется основной.
Это «не проблема» (на самом деле это очень кривое решение), если основной и резервный каналы равнозначны, но если основной – это оптика, а резервный – это ADSL модем, то хотелось бы, чтобы маршрутизатор переключался на основной канал автоматически.
Более того, схема с плавающим маршрутом может привести к ассиметричной маршрутизации. Если у нас есть два офиса, на которых настроены плавающие маршруты и канал до основного падает (а потом поднимается) с int down только на одном отрезке, то трафик будет уходить через один канал, а приходить через другой.
Для решения части этих проблем можно использовать IP SLA. Я не буду описывать настройки, только принцип. Конфигурация почти как в статье, только мы дополнительно создаём некое условие, которое уберёт основной маршрут из таблицы маршрутизации. Чаще всего, это условие -«пинг не проходит». Т.е. мы создаём «пинговалку», которая непрерывно пингует адрес основного провайдера. Как только пинг не проходит, маршрут до него удаляется из таблицы, туда прописывается плавающий маршрут и трафик идёт через резервного провайдера. Однако, в отличии от схемы из статьи, маршрутизатор не просто пассивно ждёт действий админа, а продолжает пинговать основного провайдера и вернёт маршрут через него в таблицу маршрутизации, как только пинг появится вновь. Это не решает проблемы со сбоем маршрутизации внутри самого провайдера, но, хотя бы, не требует руками передёргивать каналы, когда связь с основным ISP восстанавливается.
Как все сложно-то.
Зато, я надеюсь, для понимания моих слов не нужен телепат.
Поэтому просто прилагаю скрин ниже. Сделать аналогично не составит большого труда.
Для тех, кто не понял, что это такое на скрине, сообщаю — на скрине графический интерфейс роутера MikroTik. К сожалению, на скрине только сама таблица маршрутизации и не видно настроек самих маршрутов, а там есть на что посмотреть. Микротик предлагает много быстрых и удобных решений, которые доступны только на их RouterOS. Причём, в отличие от циски с её CLI, графический интерфейс Winbox'а создаёт иллюзию, что всё просто и все так делают. И, например, site-to-site VPN через L2TP не кажется чем-то странным, ведь он настраивается в два щелчка мышки :)
Сделать аналогично не составит большого труда.
К сожалению, я не знаю, что вы сделали. Я предполагаю, что добавляя маршрут 0.0.0.0/0 через DNS гугла (што?..), вы включили опцию «Check getaway — ping». Т.к. я никогда этого не делал, я могу только предполагать, что микротик пингует 8.8.8.8 через каналы обоих провайдеров и переключается с основного провайдера на резервного, если через канал основного провайдера пинг до DNS гугла не проходит. Т.е. это аналог IP SLA от микротик и к рекурсивным маршрутам не имеет никакого отношения. Я, кстати, не понимаю зачем там эти рекурсивные маршруты. Что мешает просто сделать два default rout'а с разным приоритетом и на оба повесить пинговалку? Или микротик так не позволяет?
PS Я нашёл источник информации про «рекурсивные маршруты»: habr.com/ru/post/244385
Там сам автор говорит, что это «не совсем корректное использование параметра scope». Насколько помню, цисковский IP SLA позволяет сразу пинговать удалённый адрес (тот же 8.8.8.8), без таких выкрутасов. Возможно, что и микротик что-то поменяли за последние шесть лет (та статья на хабре — от 2014 года).
Не понял где именно плавающий маршрут.
2 статических маршрута с разной метрикой (дистанцией, административным расстоянием) вижу.
А что куда плывет не вижу.
2 статических маршрута с разной метрикой (дистанцией, административным расстоянием) вижу.
А что куда плывет не вижу.
Ещё одна задача вам на подумать. Задавая «ip route 0.0.0.0 0.0.0.0 s0/0/0» и «ip route 0.0.0.0 0.0.0.0 s0/0/1 5», вы сообщаете маршрутизатору, что все остальные адреса во всех остальных сетях являются непосредственно подключенными к интерфейсам s0/0/0 и s0/0/1. Что, конечно же, в реальной жизни совершенно не так, и они находятся за другими маршрутизаторами. Как вы думаете, не приведёт ли такая конфигурация к тому, что ваш маршрутизатор Edge_Router будет радостно дристать в гальюн отправлять ARP запросы с этих двух интерфейсов широковещательными запросами, при попытке обратиться к чему-либо? Какие ответы получит (или не получит) Edge_Router, что сделает, и как на это отреагирует клиент PC-A?
ARP на Serial интерфейсах???
Да, что-то я маху дал. Будем считать, что там какие-нибудь Gi0/2 и Gi0/3.
Позволю себе вмешаться (ради будущих поколений же). Очевидно, речь идёт про это: www.cisco.com/c/ru_ru/support/docs/dial-access/floating-static-route/118263-technote-nexthop-00.htm?
Циска рекомендует прописывать в статических маршрутах и IP адрес next hop'а и исходящий интерфейс, т.е. делать маршруты вида is ip route 0.0.0.0 0.0.0.0 Ethernet0 192.168.1.1
Cisco highly recommends that you specify the outbound interface and the next hop IP address when you configure static routes. When the outbound interface is a point-to-point type of link (for example, a serial link), the specification of the next hop address is not needed.
Циска рекомендует прописывать в статических маршрутах и IP адрес next hop'а и исходящий интерфейс, т.е. делать маршруты вида is ip route 0.0.0.0 0.0.0.0 Ethernet0 192.168.1.1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Packet Tracer. Лабораторная работа: Настройка плавающих статических маршрутов