Одновременное использование двух провайдеров на маршрутизаторах cisco (продолжение)

    Одновременное использование двух провайдеров

    Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
    Для начала: нам надо обоих провайдеров проверять на «живость» и переключать все потоки на одного в случае, если кто то «упал». Это делается полностью аналогично проверке ISP1 в главе про Резервирование. С тем лишь отличием, что оба маршрута по умолчанию имеют одинаковую административную дистанцию

      ip route 0.0.0.0 0.0.0.0 Gate(ISP1) track 11
      ip route 0.0.0.0 0.0.0.0 Gate(ISP2) track 22
    


    Правила NATа не претерпевают изменений. Те же route-map в динамических и статических трансляциях. Но как определить, какой пакет отправлять через какого провайдера? Можно принудительно раскидывать входящие с g0/0 пакеты ещё одним route-map.

    ! Заготавливаем списки доступа с «интересным» трафиком. Все знают, что такое
    ! «интересный» трафик? :)
    ip access-list extended ACLISP1
      permit {трафик на ISP1}
    !
    ip access-list extended ACLISP2
      permit {трафик на ISP2}
    !
    route-map STRELKA 10
      match ip address ACLISP1
      set ip next-hop {GateISP1}
    route-map STRELKA 20
      match ip address ACLISP2
      set ip next-hop {GateISP2}
    !
    int g0/0
      ip policy route-map STRELKA
    

    Правда в этом случае пакет, попавший в ACLISP1, пойдет на первого провайдера всегда, независимо от того, жив провайдер или нет. Чтобы этого избежать есть возможность в этом route-map применить проверку по track

      set ip next-hop verify-reachability {GateISPX} {sequence#} track {track#}
    

    sequence# — это число от 1 до 65535. Если таких возможных next-hop будет много, то они будут упорядочены по этому числу.

    Напомню, что в случае если пакет явно не попал в route-map, он будет использовать обычную таблицу маршрутизации.

    Ну а теперь давайте попробуем разобраться с двумя очень сложными вопросами: каким образом будут ходить пакеты, если вы не используете явно разделение трафика при помощи route-map на внутреннем интерфейсе. И как сделать так, чтобы пакет, пришедший снаружи на адрес сервера Srv(ISP1) ушел обратно через тот же интерфейс, через который пришёл. Это действительно сложные вопросы. И красивого решения для них нет, поэтому я в своей практике стараюсь избегать таких топологий.
    Однако, жизнь может заставить, поэтому разберемся.

    Пусть снаружи приходит пакет на интерфейс f0/0 на адрес Srv(ISP1). Благодаря статической трансляции адрес назначения будет изменен на Srv(LAN) и пакет пойдет дальше на сервер. На маршрутизаторе в кеше NAT трансляций появится запись о соответствии Srv(LAN) и Srv(ISP1). Сервер ответит, ответ дойдет обратно до маршрутизатора и…возникнет вопрос: по какому маршруту отправлять пакет в Интернет? В кеше трансляций есть явная запись, какой адрес ставить вместо Srv(LAN) – Srv(ISP1). Но нет ни намека, через какой интерфейс при этом посылать пакет. Для исправления этой неоднозначности надо по какому то критерию разделять приходящий с разных интерфейсов трафик. Этого можно добиться, но способ, по моему мнению, не очень элегантный: надо использовать подмену реальных адресов клиентов на разные пулы внутренних адресов. Надо только подобрать размер этого пула соответственно нагрузке на сервер – по одному адресу на каждого обращающегося, т.к. для внешнего NATa (outside NAT) на маршрутизаторах нельзя сделать РАТ (Port Address Translation), только трансляция адрес в адрес. Тогда всегда точно известно, с какого интерфейса поступил запрос. В качестве критерия для трансляции адреса сервера можно в существующие route-map добавить такие списки доступа

    ip access-list extended FORISPX
      permit ip host Srv(LAN) OUTPOOLX
    

    Таким образом получим:

    ! задаем пулы для каждого из интерфейсов
    ip nat pool OUTPOOL1 {start-ip-1} {end-ip-1}
    ip nat pool OUTPOOL2 {start-ip-2} {end-ip-2}
    !
    ! задаем критерий для outside NAT
    ip access-list extended OUTNAT1
      permit ip any host Srv(ISP1)
    ip access-list extended OUTNAT2
      permit ip any host Srv(ISP2)
    !
    ! транслируем адреса источника клиентов
    ip nat outside source list OUTNAT1 pool OUTPOOL1
    ip nat outside source list OUTNAT2 pool OUTPOOL2
    !
    ! дополняем route-map
    route-map ISP1 permit 10
      match interface f0/0
      match ip address FORISP1
    !
    route-map ISP2 permit 10
      match interface f0/1
      match ip address FORISP2
    

    Это решение, пусть не красивое, но все же полностью решает задачу, не затрагивая сервер (его часто и нельзя затрагивать: например, если это не приложение, а VPN сервер). Потеря здесь явная одна: сервер никогда не знает, с кем реально он общается, а значит нельзя собрать адекватную статистику и т.д.

    Если же использовать возможности серверов, то на ум приходит несколько решений, не требующих внешнего NATа.
    Первое – сделать на самом деле 2 сервера-партнера, с разными адресами и связанными друг с другом для репликации ещё одним линком. Каждый сервер транслируется в свой адрес, но в случае падения одного из каналов переключается на партнерский адрес.
    Не самое простое и дешевое решение.

    Второе: задать на одном и том же сервере 2 адреса. Если они из одной подсети, то проблемы с маршрутизацией не будет. Каждый из локальных адресов сервера строго транслируется только одного из провайдеров, т.к. физически сервер один и никакой выгоды по нагрузке мы все равно не получим. Для явного указания выходного интерфейса применяем route-map STRELKA. Тут может возникнуть проблема с самим сервером: часто бывает так, что при ответе сервер использует только первичный адрес интерфейса, независимо от того, на какой адрес пришел запрос.
    Характерный пример: VPN сервер. Если в качестве VPN ¬сервера выступает маршрутизатор cisco, то он всегда отвечает с первичного адреса интерфейса.

    _________________
    UPD on 23:45 14.01.2010


    Пришло письмо мне от читателя из Литвы, где он сослался на интересную статью. Пожалуй, она дополнит именно серверную часть задачи:
    Тут на сайте НИЛа. Автор — Иван Пепельняк, один из ранних CCIE, очень глубокий специалист (его блог «IOS hints and tricks»

    Вкратце: на виндузовом сервер можно создать интерфейсы loopback (2 штуки) и сорсировать пакеты от сервисов именно от этих адресов. И транслировать их в разные внешние. Дополнительно надо на маршрутизаторах прописать обратные маршруты в сети этих loopback. Тогда проблема адреса источника будет решена
    __________________

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

    PS Сегодня наконец собрал стенд и ещё раз все проверил, благодаря Вашему интересу! Так что пользуйтесь, дорогие мои :)

    Сергей Фёдоров, CCIE Security #22974
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

      –2
      cпасибо, попробуем
        +3
        А что такое «интересный трафик»?
          +2
          присоединяюсь к вопросу
            +9
            Ну как что, то, что вам интересно :) Кому хабр, а кому… по настроению :))

            шутк

            На самом деле в терминах циски «интересный трафик» — это тот трафик, который понуждает определенную технологию к действию. Например, «интересный трафик» для IPSec, это то, что надо шифровать (а значит поднимать туннели, договариваться с соседом и т.д.)

            В данном случае я назвал «интересным трафиком» для ISP1 тот трафик, который вы принудительно хотели бы пускать через ISP1

            Пример: один безлимитный недорогой помоечный (ненадёжный) канал. Туда всех юзверей, фтп, торренты, ввв. А второй канал — дорогой, с гарантированными характеристиками. Туда принудительно — голос, видеоконференции и т.д.

            «Интересный трафик» описывается на цисках списком доступа. Что явно прописано словом permit — то и есть интересный трафик. Этот список применяется для конкретной технологии (в нашем случае — для PBR, в IPSec применяется в crypto map и т.д.)
              0
              Это наверное все таки у вас плохой перевод, я считаю. А трафик интересующий (нас). Это разные слова, с разными коннотативными значениями.

              Это конечно не умаляет ничуть, того, как я рад читать ваши статьи: )
                0
                К сожалению наверно, но тут сложно что то придумать
                В оригинале это пишется как interesting traffic
                «Интересный» он не для пользователя, а для технологии. Ведь это циска для себя пишет :)

                ЗЫ Спасибо за ваше удовольствие :)
              +2
              Не понял, куда то делся ответ :( Писал писал…

              Попробую повторить: «интересный трафик» это то, что побуждает определенную технологию к действию. Например, для IPSec это те пакеты, которые надо будет шифровать.

              В данном случае я назвал «интересным трафиком» для ISP1 тот трафик, который мы хотим принудительно гнать через первого провайдера
                0
                Да, спасибо за развернутый ответ.
                Ответ пришел мне на почту, где с ним и ознакомился
                  0
                  ГЫ! Осталось сообразить, КАК я это сделал?

                  Я через такую пень-колоду личные сообщения отправляю, а тут оказывается есть простейший механизм! Откройте мне глаза, хабраламеру :)
                    0
                    признаться, я списал это на происки НЛО ибо сейчас комментарий доступен и виден.
                  0
                  Хм… появился первый ответ… чудеса…

                  Сорри за «мусор» Я правда ненарочно
                    0
                    А Somewan'у приходило не личное сообщение, а уведомление на почту об ответе на его комментарий.
                      0
                      Ага, понятно. Трафик в мыло ушел, а на сайте сразу не отобразился. Фух, выдохнул :)
              0
              Это наверное работает в случае, когда 2 провайдера кабелем воткнуты в роутер. А если у меня один провайдер — кабелем, а другой — через ADSL-модем? т.е. роутер будет проверять доступность интерфейса при работающем модеме, и будет считать его доступным даже если сам провайдер доступен не будет, так? как быть, не подскажете?
                +2
                А в чем принципиальное отличие? Если модем у вас стоит «бриджом» — то пингуем гейт, а если стоит как роутер, то пинговать надо следующий хост (за «ненадёжным» АДСЛ-линком). Можно и ещё выше: подобный вопрос задавали в предыдущем топике. Если вы ходите через провайдера, который провайдером не является :) т.е. сам использует н свои адреса, а вышестоящие и один выход наверх, то возможно размнее пинговать не вашего, а вышестоящего провайдера.
                  0
                  у некоторых «гавно»-провайдеров разумно проверять на живость например их бордюры, а не устройства доступа абонента .) другое дело что для этого в таблице маршрутизации должны быть нужные маршруты :)
                    0
                    Для этого вполне достаточно найти по запросу в NIC например, чья сеть внешняя, которую пользует провайдер. А также пустить банальный трейс, чтобы обнаружить внешнюю границу провайдера.
                  –2
                  да, все так, ip sla monitor чуть более чем полностью решает все проблемы с несколькими аплинками без динамики. (-:

                  только тут нет никаких откровений или хитростей, все банально и есть даже на cisco.com в примерах :( но наверно типа «доступнее». Ж)

                  я вообще не мыслю себе уже офис или что-то еще без маршрутизатора cisco :D писюки, линагзы, фряхи, шелл-скриптенг — это все так уныло :(

                  пс: кстате вышеозначенное имеет небольшие недостатки, к примеру, если сурсойпи с которым вы ходите в интернет на разных аплинках разный, а значит и трансляции в таблице ната отличаются, то после падения основного линка не будет «прозрачного» переключения, т.е. пользователи вполне заметят «отвал» основного канала: фтп поломается, ссх отвалится, ойсикью реконектиться и так далее… впрочем это нормально и ничего с этим особо не сделаешь :) просто если оба аплинка работают нестабильно то все становится несколько не комильфо :)
                    0
                    ну и слегка офтопик :)

                    рас уж такая пьянка с CCIE :) то не постесняюсь спросить: есть ли способ «слить» маршруты из неглобальной в глобальную таблицу маршрутизация посредством, например, BGP? наоборот, все прекрасно работает, да, я знаю :(

                    пс: речь о не очень «свежих» cisco маршрутизаторах ( 36, 37, 38 и иже с ними ), у 29ых и 39ых впринципе можно указывать прямо в роутмапе и некстхоп и нужную таблицу маршрутизации… :\

                    ппс: действительно интересно.
                      0
                      ой… наверно для ясности надо было таки приводить сценарий :( но как-то лень :) поэтому «пс» в этом посту можно вычеркнуть, он не совсем имеет отношение к вопросу.
                        0
                        видимо, речь идет о route-leak между vrf и глобальной таблицей маршрутизации.
                        если vrf-vrf обмен маршрутами посредством bgp + extended community — все ясно и понятно.
                        а вот если нужно часть маршрутов из какого-то vrf забросить в global routing table — начинаются проблемы.
                        у меня не вышло, так что присоединяюсь к вопросу =)
                          0
                          Чтобы вас не путать в конфигах (я их сам не знаю :)) скажу словами: да, кажется можно, но путь тот тернист и требует ещё одного лишнего VRFa, если я правильно помню. Дело в том что так извращался не я, а мой коллега (Серега Сиверцев, тоже инструктор наш). Он помню (по радостным возгласам) победил. Могу спросить.
                            0
                            был бы очень благодарен, если вам не сложно
                              0
                              Получил ответ от Сереги. Передаю все, что он написал.

                              ________________________________
                              Серёга, привет!

                              Наверное, слишком поздно я читаю твоё письмо (но лучше позже чем никогда).
                              Из vrf в vrf действительно всё понятно — согласен с написанным в посте.

                              В global мне нужно собрать стенд вспомнить-проверить. Колхоз этот в рамках железки насколько я помню возможен при организации vrf-aware GRE ( тут ). Идея в том, что один конец GRE находится в одной VRF, другой в global. Сам я такое чудо не творил, но у меня на MPLS около года назад был один увлечённый АМТшник, который даже конфигу высылал, но это решение так в почте и умерло (нужно долго его восстанавливать и искать из архива почты). Как пример, такой завод трафика в туннель насколько я знаю народ делает, чтобы загнать трафик через FWSM модуль в 6500. Сам я такое увы не делал.

                              В книжке Пепельняка по MPLS такой туннель как пример тоже приводится (случай правда другой) — делается это для того, чтобы клиент смотрел на провайдера своим интерфейсом в VRF X, а для выхода в Интернет при невозможности организации другого интерфейса (физического или логического) кидают от клиента GRE туннель, который на провайдерской железке проходит через VRF (т.е souce и destination туннеля сидят в VRF X), а сам IP туннеля — в Global. Называется это — «прокалывание». Циска такое не рекомендует — рекомендуется 2 отдельных интерфейса (а не GRE туннель как интерфейс). (Но это решение проще — железка не одна, а две — одна клиентская без VRF, другая провайдерская).

                              Вовка Кокшенёв рассказывал ещё один колхоз — на железяке делаешь физическую петельку сам на себя (при наличии двух свободных интерфейсов) — и тогда разные интерфейсы в разные VRF или global распихиваешь — но это ещё больший колхоз.

                              Ну ещё есть фишки, которые ты наверное знаешь:

                              Маршрут для VRF:
                              Ip route vrf X x.x.x.x x.x.x.x next-hop global — тогда next-hop ищется в глобальной таблице маршрутизации
                              И наоборот:
                              Для global
                              Ip route x.x.x.x x.x.x.x interfaceInVRF next-hop — тогда next-hop ищется в VRF.

                              ___

                              На сколько я понял в диалоге человек спрашивает: можно ли через BGP для того, чтобы слить сразу много (или очень много) маршрутов. Поэтому описанные выше решения для route leaking действительно слабоваты. ИМХО Циска всё сделала для того, чтобы изолировать global от такого. Отрабатывает стратегия изоляции: VRF отдельно, global — для переноса VPNv4 маршрутов. В связи с этим иногда удобнее держать Интернет маршруты (или разные их наборы) в разных VRF. Женя даже рассказывал, что у него на MPLS у кого-то из людей на железяке было 7 VRF с full view. Вопрос конечно упирается в возможности железки, CEF и т.д. Сама циска в курсе MPLS 2.2 опять-таки не рекомендовала держать full view в VRF (нужно смотреть ограничения по CEF). В общем, вопрос не простой. Зарубаться, что я точно знаю как правильно — не буду.

                              С уважением,
                              Сергей
                              _____________________________

                              Можно ним связаться: sivertsev () ciscotrain.ru
                              Пусть за базар ответчает :)
                              (Серже, если читаешь — НЛ! :))
                                0
                                спасибо за ответ :)

                                как я понимаю краткий ответ на вопрос выглядет как «человеческим способом этого не сделать» :)

                                ну тянуть туннели из глобальной зоны в vrf это далеко не то что хотелось бы, да и вообще тянуть туннели между vrf'ами занятие дурное… :( статик, да, но желание было именно часть динамики сунуть в vrf. да, я тоже пришел к выводу кукожить на линк отдельный vrf и уже между ними переливать префиксы как мне захочется. конечно, проблемы ограничения cef и так далее забывать не надо.

                                ps: не холивара ради отмечу что в junos такие вещи легкореализуемы и не требуют ломания мозга, ну, по-крайней мере, в данном вопросе. :)

                        0
                        Пальцы видно за версту: )

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

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

                        Но это явный недостаток современной технологии IP, а также того, что собственно спецам по большому счету пофиг, а провайдерам наоборот хорошо — меньше рыпаться будут, и надежность высокая огромный козырь. А если бы не было такой проблемы, то надежность вполне можно было бы приподнять за счет пары тройки лишних линков: )

                        Философские такие рассуждения в общем. Даже есть надстройка, DNS, которая местами проблему решает, но ее возможности слабо прокачены. Ой, все, стоп, Остапа понесло: )
                          0
                          Тогда придётся не экономить, а купить BGP автономку и провайдеронезависимые сети, а также рутер. Минимум 3845 с гигом оперативы (если говорить про циски), а лучше 7206.

                          И все будет :) Хотя тоже не элементарно для некоторых случаев.
                            0
                            ой, ну зачем же так Ж) 3845 с гигом памяти это если есть большое желание держать по фуллвью на аплинк, что обусловленно адекватными причинами далеко не всегда, имхо. если не задаваться желанием куда-то присунуть по несколько сотен тысяч префиксов с каждого аплинка, то вполне можно обойтись чем-то попроще и подешевле. ну просто в среднем мне кажется 8 тысяч долларов за бу роутир мало кто будет морально отдать. :)
                              0
                              Ну а куда девать ip bgp таблицу? А она несколько поболе таблички роутинга будет.

                              И как без фулл-вью использовать все бенефиты BGP?

                              Вот тут как раз кроилово ведет к попадалову :)

                              ЗЫ Отдать свою и взять 2 дефотлта может даже древнющая 2503, бесплатно на помойке валяющаяся :)
                                0
                                да, вопрос производительности лишь остается, а так любая сойдет. :)

                                ну, например, можно принимать не целиком фуллвью, а обрезанную, например, до /23 иди даже еще короче выбрать префикс… ну все бенефите никак, да, но так ли они нужны? :) если хочется всего по фень-шую, то да, дорога в супермаркет за роутиром за кучу денег или за писюком с кваггой как вариант для бедных :)

                                ps: насчет 25ых ) лично не откажусь от нескольких 2511RJ .)

                                  0
                                  Ха, консольные сервера самому нужны :)
                                  0
                                  just wonder: какие вам бенефиты видятся от фулл вью для нетранзитной АСки?
                                    0
                                    А не надо городить огород с интернет-сетями. При большой географической разнесенности выходов на провайдеров можно некисло сэкономить на неоптимальной маршрутизации. И когда какого-то магистрала колбасит гораздо проще и безболезненнее переключение на ещё живущие маршруты.

                                    А можно ещё свою комьюнити организовать зряче, суммаризацию хитрую, не боясь неоптимальностей…

                                    дезигн, короче :)
                              0
                              ну дык нынче даже физическое лицо может получить AS и PI-блок адресов, купить с инжапана c1812 за 400 баксов и подключить двух операторов, какие проблемы-то?

                              sla крут мониторингом и уверяю, гораздо удобнее и проще использовать sla (который кстате умеет вещать о событиях и в syslog и в snmp отсвечивать), чем изобретать велосипеды из километров быдло кода на sh или чем либо еще и вешать это все в крон на гореписироутире…

                              надежность и сейчас можно приподнять за счет пары-тройки лишних линков: еще раз, цена вопроса AS и PI вполне по зубам даже физическому лицу. да, речь, конечно, не идет о статусе LIR, но он в большинстве случаев не нужен…

                              если уж жаба давит на AS, то можно выкрутится с провайдером vpn и например держать два впн туннеля, по одному через каждого провайдера, тогда сурсойпи менятся не будет при переключении между провайдерами и все будет почти прозрачно…
                              0
                              Я искренне рад, что для Вас это не создает проблем, ни в настройке. ни в понимании. Вы — в первой десятке из сотни настройщиков циски, судя по моей статистике вопросов.

                              И про «хитрости» я в этом топике и не обещал писать :D

                              Ставлю себе задачей в понятной форме, по-русски и разговорным языком объяснить широкой аудитории основы технологии. На пальцах, так сказать. Я этим на работе занимаюсь каждый день, когда курс читаю :)

                              Если людям нравится, значит не зря я пишу.
                              А на циско.ком все равно придётся лазить: я не осилю и доли процента описать самостоятельно :)

                              Но если вам не нравится читать, то этого вполне можно не делать :)))
                                0
                                я не говорил что мне не нравится или что-то еще :) все очень хорошо :) продолжайте в том же духе :)
                                  0
                                  О, спасибо, приятно слышать :)
                              +2
                              Не жизнеспособный конфиг.
                              При маршрутизации от источника производительность никакая.
                                0
                                Согласен по факту: source routing действительно медленнее «обычного». Однако, не на столько (используя ip route-cache policy по-моему), насколько это было на 26хх серии.

                                28хх довольно бодро работают с PBR. К тому же, типичные интернет коннекты сейчас по 10 МБит (а часто гораздо меньше). Не хочу быть голословным, но рыться в технических деталях конкретных рутеров лень — 20МБит будут обработаны при помощи PBR легко.

                                Так что конфиг жизнеспособен, скажу более, распространен и часто выручает
                                  0
                                  Подтверждаю, PBR + NAT на 2х 10мбит каналах грузил 1840 на 30-40 cpu при полной нагрузке обоих каналов. С ip cef вероятно будет еще меньше, но там могут быть неприятные побочные эффекты
                                0
                                остался вопрос балансировки при получении 2 full-view от 2х пиров ) простой вариант — это смириться с выбором маршрутом на основании as-path и в один из линков ускачет бОльшая часть трафика, а иначе?
                                  0
                                  bgp maximum-paths — можно указать количество параллельно используемых путей маршрутизации.
                                    0
                                    А ещё можно использовать неафишируемую команду: ip bgp relax-...(не помню точно команду). Он позволяет использовать в BGP несколько маршрутов.

                                    ЗЫ Кстати, в классическом BGP возможен ТОЛЬКО ОДИН маршрут. По-моему, maximum-paths для BGP вещь нетипичная. Но тут я «плаваю» и спорить пока не буду :)
                                      0
                                      www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml#bgpmpath

                                      BGP Multipath allows installation into the IP routing table of multiple BGP paths to the same destination. These paths are installed in the table together with the best path for load sharing. BGP Multipath does not affect bestpath selection. For example, a router still designates one of the paths as the best path, according to the algorithm, and advertises this best path to its neighbors

                                      maximum-paths n

                                      best path — по прежнему один, да. остальные — альтернативные.
                                        0
                                        Ага, спасибо за выжимку.

                                        Мне казалось, что для того, чтобы рутер мог использовать несколько путей, получаемых по BGP как раз и нужна эта relax команда. Я гляну: у нас на форуме народ очень толково про BGP писал.
                                          0
                                          Вот эту команду имел ввиду:
                                          bgp bestpath as-path multipath-relax
                                            0
                                            сие will allow the router to load-share across multiple BGP paths even if the as-path is different. нужно только если маршруты от 2 разных AS приходят
                                              0
                                              Ну да, а разве не это требовалось?

                                              Тогда сорри, что ввожу тут в заблуждения — устал видимо, не внимателен…
                                                0
                                                да, это я пропустил что у человека по AS-PATH перекос
                                                0
                                                ____________
                                                мириться с выбором маршрутом на основании as-path
                                                _______

                                                МНе показалось из-за этой фразы, что не нравится, что длина AS-PATH разная и нельзя использовать в этом случае несколько путей.
                                            0
                                            без maximum-path будет юзать только best
                                            с — альтернативные тоже при условии равенства ряда атрибутов (там в доке ниже расписано каких)
                                            вроде больше никаких дополнительных команд для этого не надо
                                        0
                                        Заметьте, я в статье (в первой части) специально написал: без BGP. ЧТобы не было недоговорок.

                                        Я писал дешевое решение (согласитесь, full-view с соотв. железом уже не попадает в дешевое решение). Именно по нему возникает наибольшее количество вопросов.

                                        сли интересно мое мнение: BGP тоже устарел. Спасти может community и договоренность «за рюмкой кофе» между провайдерами.
                                        0
                                        Не затронут вопрос балансировки между каналами без BGP. Пост по теме umraf.habrahabr.ru/blog/77383/ благодаря которому я на хабре =)
                                          0
                                          Да, спасибо. Интересных хак. Про АРП я бы не додумался :)

                                          Кстати, кажется в cef можно рекурсию выключить. Может тогда поможет?

                                          А на счёт того, что cef при двух маршрутах будет делить трафик пополам — это не совсем верно. Он будет делить инициализацию сессий (или по пакетам, или по назначению, или по паре «источник-назначени», даже по портам делить может), но не само кол-во трафика. Т.е. может статься (по дефолту он делит НЕ по пакетам), что сессий поровну, а трафика на одном провайдере в 2-3 раза больше.
                                            0
                                            Интересно, посмотрю на досуге как в cef рекурсию выключить.

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

                                            Добавлю уточнения в свой пост.
                                              0
                                              Что то я поковырялся на железяке и на сайте — выключить рекурсию не получилось :(
                                              Тут возможно 2 варианта: или это нельзя сделать на новых ИОС, или я с чем о перепутал. В любом случае сорри за введение в заблуждение.
                                                0
                                                Не понравилось мне моё последнее предложение ;). Думаю правильно будет так:

                                                Так что пропорция по количеству сессий, в моём случае, практически соответствует пропроции входящего трафика.
                                                  0
                                                  Ну для ТСР вообще проблем особых нет: там сессии при больших загрузках саморегулируются. Хуже с каким-нить потоковым видео…

                                                  Я кстати как правило стараюсь отговаривать клиентов от провайдер шаринга имеено из-за сложностей с прогнозом. Как правило, я склоняю их к разделению провайдеров по трафику (много плохого или немного хорошего) и тогда могу сам регулировать загрузку каждого канала, применив политики QoS на интерфейсах.
                                                    0
                                                    Согласен.

                                                    Моя задача была именно равномерно прогрузить оба канала. Будет другая задача, будет другое решение ;)
                                                      0
                                                      Нене, очень хорошее и интересное исследование! Сам такое, неочевидное, очень люблю: заставляет копаться в проблеме, искать обходные маневры, хинты и вообще — думать, а это, говорят, полезно :)

                                                      Занес хинт с АРПом себе в блокнотеГ :)
                                            0
                                            А почему не OER для балансировки исходящих соединений?

                                            По поводу обратного маршрута — что скажете насчет такого варианта:
                                            прокинуть inside static NAT (PAT);
                                            Настроить dynamic NAT на основе route-mapов на оба маршрута
                                            с включенным ip cef входящее соединение кеширует маршрут и ответный пакет попадает на нужный интерфейс, где NAT-ится с нужным адресом.

                                            К сожалению не нашел нужного конфига в своих архивах, чтобы показать пример.
                                              0
                                              Почему? Потому что далеко не везде доступен (не на всех железках и ИОСах). Т.е. решение не универсальное, хотя очень мощное (к стыду своему, я его ещё не изучил досконально)

                                              На счет кэширования маршрутов: а собственно чем не нравится мой вариант? Он работает надежно.

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

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

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

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