Устранение ассиметричной маршрутизации в Juniper SRX

  • Tutorial
     В данной статье я опишу, как с помощью родных средств Juniper SRX можно действительно легко и изящно разрулить некоторые раздражающие схемы маршрутизации. Речь пойдет об использовании виртуального маршрутизатора, а точнее, в терминах Джуниперов, routing-instance virtual-router.
     Кратко проблему можно сформулировать так: есть два или больше внешних Интернет-канала (ISP1 и ISP2) и есть веб-сервер внутри сети. На шлюзе поднят source NAT, который отдает страничку обоим внешним интерфейсам. Надо чтобы клиенты обоих провайдеров видели веб-страницу. Проблема в том, что, если, допустим, основным шлюзом у нас является ISP1, то веб-запросы из сети ISP2 приходят к нам на сервер и уходят через основной шлюз в сеть к ISP1, который это дело, понятное дело, блочит.



     Проблема, в общем-то, стара как мир и есть много способов ее решения. Я опишу, на мой взгляд, самый простой и наименее время- и ресурсоемкий. Сразу скажу, это не я такой мозг, что вычитал и допер – мне просто сказали, как это сделать проще всего. Сам бы я обязательно изобрел что-нибудь ужасное!
     Пусть основным шлюзом ISP1 у нас будет 1.2.3.1, а шлюзом ISP2 будет 5.6.7.1. Создаем routing-instance:
root@srx# set routing-instances ISP2_route instance-type virtual-router
root@srx# set routing-instances ISP2_route interface ge-0/0/2
root@srx# set routing-instances ISP2_route routing-options static route 0/0 next-hop 5.6.7.1

     Теперь импортируем маршруты в таблицу маршрутизации в сеть ISP2.
root@srx# set routing-options interface-routes rib-group inet ISP2
root@srx# set routing-options rib-groups ISP2 import-rib ISP2_route.inet.0
root@srx# set routing-options rib-groups ISP2 import-rib inet.0
     Вот собственно и все! Применив эту конфигу, пакеты придя с сети, ISP2 будут уходить обратно уже в сеть ISP2.
     Что мы сделали? И что вообще такое этот virtual-router? По сути, виртуальный роутер – это практически полноценный маршрутизатор со своей таблицей маршрутизации и своими интерфейсами. Первой серией команд мы создали его, указали, что интерфейс ge-0/0/2 теперь является его интерфейсом, а также указали, что его основным шлюзом является шлюз ISP2. На данном этапе была создана новая таблица маршрутизации ISP2_route.inet.0 всего с одной записью (основной шлюз)
     Вторая серия команд позволила импортировать в новую таблицу маршрутизации, так называемые, интерфейс-роуты, т.е. локальные маршруты до интерфейсов Джунипера. Без них виртуальный роутер не смог бы увидеть веб-сервер. Интерфейс-роуты были взяты из дефолтной таблицы маршрутизации, которая в Джуниперах имеет название inet.0.
     Вот и все!

P.S. Не шарю в веб-дизайне. Кто-нибудь, скажите, как картинку по центру поставить?
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 25

    0
    В поле «Написать комментарий» справа есть «html-теги». Один из перечисленных
    <img src="" />
    

    Вставка изображения, в атрибуте src нужно указывать полный путь к изображению. Возможно выравнивание картинки атрибутом align.

    Скорее всего, что-то типа
    src="" align="center"
    

    Вопрос не совсем по теме, есть ли симуляторы juniper под vmware, для тренировки так сказать?
      0
      Есть виртуалка Junos OS 12.1R1.9 (более менее последняя) вот здесь
      rutracker.org/forum/viewtopic.php?t=4061726
      Но в каком виде все это работает — если честно, без понятия! )

      Кстати, не работает align почему-то. Ставил и center и middle…
        0
        Для тренировки: habrahabr.ru/post/111172/, образ ОС — rutracker.org/forum/viewtopic.php?t=2419674.
          0
          Junos OS 9.3 — ужасно древняя и страшно глючная, не надо ее ставить!
        0
        Уважаемый автор, хотел бы обратиться к Вам с просьбой проверки материала перед публикацией.

        1.
        На шлюзе поднят source NAT, который отдает страничку обоим внешним интерфейсам.


        я уже не говорю, что NAT вероятно либо statis, либо destination. Во-вторых «отдает страничку обоим внешним интерфейсам» — вообще не понятно.

        2.
        если основным шлюзом у нас является ISP1, то веб-запросы из сети ISP2 приходят к нам на сервер и уходят через основной шлюз в сеть к ISP1, который это дело, понятное дело, блочит.


        С чего бы? Другое дело пользователь сервиса, он отправлял запрос на адрес 1.2.3.4, а получил ответ от 5.6.7.8. Не все приложения нормально это переваривают.

        3. И самое главное. Трафик возвращается от сервера к клиенту, на основании чего маршрутизатор должен или сделает вывод об обработке пакета той или иной таблицей маршрутизации?
          0
          Хорошо.
          1. Если я скажу, что на каждом интерфейсе внешнем поднят source NAT — так станет понятнее? Или в чем вопрос?
          2. Я описал нормальную ситуацию среди нормальных провайдеров. Не цепляйтесь к словам, коллега.
          3. В данном случае маршрутизатору не из чего выбирать. Он всегда обязан обработать входящие пакеты соответствующей таблицей маршрутизации. Соответственно, на одном внешнем интерфейсе она одна, на другом — другая. Здесь нет балансировки, т.к. задачи такой не стоит.
            0
            Не понял, а как обратный пакет от веб-сервера будет отправлен в интерфейс ISP2? На основании чего?
            Шлюзу прилетает пакет от веб-сервера. Веб-сервер находится в дефолтном VRF. Почему он вдруг отправит его в другой VRF?
              0
              По идее статья и должна была ответить на этот вопрос. Но о policy routing ни слова, а главное на основании чего маршрутизировать?
              0
              2.
              если основным шлюзом у нас является ISP1, то веб-запросы из сети ISP2 приходят к нам на сервер и уходят через основной шлюз в сеть к ISP1, который это дело, понятное дело, блочит.

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


              Если правильно понял, Вы хотите сказать, что если провайдер ISP1 выдал нам адрес 1.2.3.4 и получил на вход трафик с источником 5.6.7.8, то такой трафик будет заблокирован? Если так, то это ситуация с домопровайдерами, а не нормальными провайдерами.

              3. Представьте ситуацию. Клиент (IP 20.20.20.20) отправляет запрос на сервер и, допустим, приходит через ISP1. Сервер обрабатывает запрос и отправляет ответ на 20.20.20.20. Этот пакет получает маршрутизатор. Какому провайдеру будет отправлен пакет и почему? А потом клиент 30.30.30.30 также запрашивает информацию у сервера, но приходит через ISP2. Сервер отправляет ответ на 30.30.30.30. Как этот пакет обрабатывает маршрутизатор (какому провайдеру будет отправлен и почему)?
                –1
                Если честно, я не в курсе, как в деталях работает эта схема, но она работает, это проверено.
                По факту она делает следующее: все, что приходит с ISP2 — уходит в него же. Все, что приходит с ISP1, тоже уходит в него же.
                Короче, с какого внешнего интерфейса пакет пришел — в тот он и уйдет. Это реально удобно.
                  0
                  Не есть хорошо писать про то, что сами не знаете как работает :)

                  > который это дело, понятное дело, блочит.
                  Совсем не понятно, почему это он должен блочить. Симметричный трафик в интернете нормальное явление, корневые и провайдерские роутеры самостоятельно считают наиболее оптимальные для себя маршруты. Соотвественно маловероятно, что пакет который был отправлен с одного континента в другой (из одной AS в другую, значительно удаленную) вернрется тем же путем.
                    0
                    Совсем не понятно, почему это он должен блочить.

                    Это же очевидно. Вот есть клиент с PA блоком адресов, выданным данным провайдером. Есть PE роутер, который анонсирует соседям маршрут на этот PA префикс. Префикс не может засветиться в какой-нибудь другой точке Сети, или у другого провайдера, он всегда в одном месте. Потому провайдер делает совершенно правильно, когда включает RPF проверку на PE. Она сработает и дропнет пакет только если клиент что-то неправильно настроит (с этими настройками у него все равно ничего работать не будет, так как обратка улетит неизвестно куда), либо если клиент активно кого-то атакует (тем более имеет смысл блокировать). Третий вариант — «клиенту принадлежат два PA блока от разных провайдеров, и исходящие пакеты могут улетать не в ту сторону» вряд ли часто рассматривается, и думаю, для того, чтобы провайдер не блокировал такие пакеты, надо доказать ему факт владения этой подсетью.

                    А кому требуется слать пакеты с одним и тем же source сразу нескольким провайдерам, тот покупает PI блок. Все так делают.

                    celebrate, это действительно очень плохо, когда вы создаете микроскопический пост про жалкие 6 команд, и не можете объяснить, что они делают. Хуже — то, что вы настроили это у себя в боевой инфраструктуре, не разобравшись в них. Да, я тоже не понял, что вы наворотили. Просто статический маршрут для ECMP что ли? Обычно NAT отрабатывает после роутинга, то есть проблемы очень даже будут, если провайдеры осуществляют RPF проверку.
                      0
                      В соседней ветке речь пошла про PI AS, соотвественно, мой комментарий именно про эти условия.
                      Прошу прощения, выразился не точно.
                        0
                        На самом деле, даже при PI AS нужно заранее договориться, кто кому какие сети отдает. В таких условиях тоже имеет смысл включать RPF для ентерпрайз клиента, который не может анонсировать чужие префиксы и не станет пускать через себя транзитный трафик.
                        Уже бывали факапы масштабом со всю страну — когда провайдер не догадался фильтровать анонсы от клиента, а клиент сильно укорачивал AS PATH. По аналогии, какой смысл НЕ фильтровать приходящие от клиента пакеты?
                  0
                  3. Это кстаит и есть точная формулировка вопроса на который должна была ответить статья. На сколько я знаю наиболее правильным решением будет являтся анонс собсвтенной AS по BGP и загрузкой full view от обоих провайдеров.
                    0
                    А что это даст? Где гарантия, что маршрут к клиенту во 2 случае будет лучше через ISP2, чем через ISP1?
                    Самый простой вариант — 2 ip-адреса на сервере. Один интерфейс шлюза (к ISP1) натит на первый адрес веб-сервера, а второй интерфейс (к ISP2) — на второй адрес. И policy-based routing направляет траффик с source 2 адресом веб-сервера на интерфейс к ISP2.
                    Про full view и его необходимость (вернее, как раз отсутствие необходимости) отлично расписано тут
                      0
                      Ну да, гарантий на обратный маршрут это всё равно не даст…
                      Но если натить два интерффейса на разных провайдеров (тут нам и as своя не нужна), встает вопрос о том каким образом обеспечивать доступность для клиента? Допустим это веб-сервер, придется делать dns round robin, что тоже не является хорошим решением.
                        0
                        Где гарантия, что маршрут к клиенту во 2 случае будет лучше через ISP2, чем через ISP1?

                        Никакой гарантии, но в среднем по больнице пакеты будут ходить по наиболее короткому AS PATH, и можно сделать хоть какой-то load-sharing, не полагаясь на DNS.
                        В любом случае — будет иметься фейловер без разрыва соединений в пределах пары минут. В предложенном вами сценарии при падении одного из провайдерских каналов все клиенты, прицепившиеся к его адресу, будут довольно долго тупить.
                          0
                          Про фейловер в течение пары минут не понял, если честно. Что имелось ввиду?
                            0
                            По моим экспериментам, если отказал один из линков, то апдейт разойдется полностью максимум за пару минут. Реально — быстрее. Без необходимости переустанавливать сессии, тем более — с другим адресом.
                              0
                              Имелось ввиду время схождения BGP.
                  0
                  А не подскажет ли кто, как это же самое делается в обычном Линуксе?
                  0
                  Хей-хо, товарищи.
                  Я тут наткнулся на решение схожей задачи на Cisco (выпустить людей, находящихся в VRF, в интернет), и, думаю, оно нам может немного помочь.

                  На Cisco это решается так:
                  1. Создаём маршрут по умолчанию для VRFа, который будет брать next-hop из глобальной таблицы адресов. Это указывается словом global в конце команды ip route…
                  2. Включаем NAT обычным образом, указав в конце команды ip nat inside… ключевые слова VRF xxx. Тогда (ход конём!) внутренние адреса (inside local) берутся из VRF xxx, а интерфейс, куда будет натиться (inside global) берётся из глобальной таблицы.
                  Когда трафик возвращается назад, NAT отрабатывает раньше роутинга и помещает пакеты в нужный интерфейс (и VRF соответственно).

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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое