Comments 62
Ну как что, то, что вам интересно :) Кому хабр, а кому… по настроению :))

шутк

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наверное, слишком поздно я читаю твоё письмо (но лучше позже чем никогда).
Из 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
Пусть за базар ответчает :)
(Серже, если читаешь — НЛ! :))
спасибо за ответ :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЗЫ Кстати, в классическом BGP возможен ТОЛЬКО ОДИН маршрут. По-моему, maximum-paths для BGP вещь нетипичная. Но тут я «плаваю» и спорить пока не буду :)
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 — по прежнему один, да. остальные — альтернативные.
Ага, спасибо за выжимку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правда, я не игрался с тем, что cef себе пишет в табличку. Допускаю, что мог упустить настройку, в которой cef действительно будет кэшировать сессию в обе стороны.
Only those users with full accounts are able to leave comments. Log in, please.