Jump to content
Калькуляторы

обмен трафиком между vrf

На cisco 6509 попробовал завести 2 vrf - один для бордерной части (где крутится bgp c аплинками), другой - для внутренний сегмент (там ospf).

Причем нужна маршрутизация между ними. Первое, что пришло в голову - объединить их через ethernet-порты, находящиеся в разных vrf-ах.

как написано в http://www.cisco.com/en/US/tech/tk436/tk83....shtml#diffvrfs

The other way of leaking routes between VRFs is to connect together two Ethernet interfaces on the PE-4 router and associate each Ethernet interface with one of the VRFs. You also must configure static ARP entries in the VRF tables for the respective next hop addresses. However, this is not a recommended solution for route leaking between VRFs; the previously described BGP technique is the recommended solution.
конечно, насторожило "this is not a recommended solution", но решил попробовать...

 

к слову сказать, ip-адреса сети /30, которая была на этом линке, навешивались не на физические интерфейсы, а на vlan-овские. все виртуальные интерфейсы в 6509 имеют один и тот же МАС-адрес, И встреченные в сети рекомендации по прописыванию в arp-таблицы нужных ip-мас-адресов, ничего не дали - шлюзовые ip друг друга не пинговали. помогло только изменение на одном из vlan-интерфейсов МАС-адреса на другой. после этого даже не пришлось прописывать МАС-адреса вручную. роутинг работал, пакеты перелетали из одного vrf в другой и обратно. Вроде все чудесно

Вот только с производительностью какая-то лажа произошла.

Как пустил трафик через этот линк, начались жуткие тормоза - терялись пакеты, причем не только на меж-vrf-ном линке, но и на всех остальных интерфейсах. Вплоть до того, что начали отваливаться bgp-сессии с аплинками. при этом cpu был загружен всего на 30. поток через линк шел на скорости не более 70мбит/с, хотя должен был быть как минимум на порядок больше - до переключения шло несколько сот мегабит.

 

ошибок на ethernet-интерфейсе не было.

Кто-то пробовал метод объединения vrf-сегментов?

какая пропускная способность обеспечивалась?

Share this post


Link to post
Share on other sites
На cisco 6509 попробовал завести 2 vrf - один для бордерной части (где крутится bgp c аплинками), другой - для внутренний сегмент (там ospf).

Причем нужна маршрутизация между ними. Первое, что пришло в голову - объединить их через ethernet-порты, находящиеся в разных vrf-ах.

как написано в http://www.cisco.com/en/US/tech/tk436/tk83....shtml#diffvrfs

The other way of leaking routes between VRFs is to connect together two Ethernet interfaces on the PE-4 router and associate each Ethernet interface with one of the VRFs. You also must configure static ARP entries in the VRF tables for the respective next hop addresses. However, this is not a recommended solution for route leaking between VRFs; the previously described BGP technique is the recommended solution.
конечно, насторожило "this is not a recommended solution", но решил попробовать...

 

к слову сказать, ip-адреса сети /30, которая была на этом линке, навешивались не на физические интерфейсы, а на vlan-овские. все виртуальные интерфейсы в 6509 имеют один и тот же МАС-адрес, И встреченные в сети рекомендации по прописыванию в arp-таблицы нужных ip-мас-адресов, ничего не дали - шлюзовые ip друг друга не пинговали. помогло только изменение на одном из vlan-интерфейсов МАС-адреса на другой. после этого даже не пришлось прописывать МАС-адреса вручную. роутинг работал, пакеты перелетали из одного vrf в другой и обратно. Вроде все чудесно

Вот только с производительностью какая-то лажа произошла.

Как пустил трафик через этот линк, начались жуткие тормоза - терялись пакеты, причем не только на меж-vrf-ном линке, но и на всех остальных интерфейсах. Вплоть до того, что начали отваливаться bgp-сессии с аплинками. при этом cpu был загружен всего на 30. поток через линк шел на скорости не более 70мбит/с, хотя должен был быть как минимум на порядок больше - до переключения шло несколько сот мегабит.

 

ошибок на ethernet-интерфейсе не было.

Кто-то пробовал метод объединения vrf-сегментов?

какая пропускная способность обеспечивалась?

На каталисте 3560G пробовал объединять vrf и global через соединение портов - работало хорошо, статическая привязка арп помогла (из глобала в врф можно просто статикой - маршрут на интерфейс). Еще пробовал через bgp по инструкции с циско.ком - заработало, но маршрутизация ушла на проц, sh cef not-cef-switched стал показывать дикие цифры (возможно руки кривые, разобраться не смог, кол-во маршрутов, утекающих из глобала в врф и обратно небольшое). Пробовал эксперимента ради через тунели с лупбэка на лупбэк - работает, но тоже соответсвенно на проце. Оставил через соединение портов в итоге.

 

Share this post


Link to post
Share on other sites
http://www.cisco.com/en/US/tech/tk436/tk83....shtml#diffvrfs
The other way of leaking routes between VRFs is to connect together two Ethernet interfaces on the PE-4 router and associate each Ethernet interface with one of the VRFs. You also must configure static ARP entries in the VRF tables for the respective next hop addresses. However, this is not a recommended solution for route leaking between VRFs; the previously described BGP technique is the recommended solution.
конечно, насторожило "this is not a recommended solution", но решил попробовать...

 

А почему import через BGP не хотите ?

Share this post


Link to post
Share on other sites

casperrr, маршрутизация между vrf и global работает по-другому, и настраивается проще.

 

А почему import через BGP не хотите ?
можно и через него, но тут куча проблем других вылезает.

во-первых, в локальный vrf (назвал его vrf vpn), прилетает full-view таблица из бордерного vrf (vrf border). Соответственно, отъедается память. как вариант, можно зарезать префиксы, прилетающие из border в vpn. сразу появился первый вопрос. какие префиксы достаточно принимать?попробовал только до /16 - "sh ip ro vrf vpn sum" показывает 8153 сетей, 4974 подсетей. Попробовал от /0 до /19 - 18345 сетей, 25885 подсетей.

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

хотя, я подозреваю, можно обойтись без маршрутов из full-view. Дело в том, что все равно пакеты из локальной сети надо направлять наружу через полиси-роутинг - определенные сети - через определенные аплинки. но тут скрывается очередная проблема. в vrf vpn есть статические маршруты на некоторые локальные сети. пакеты от моих пользователей могут идти либо на внутренние ресурсы, либо наружу. в первом случае они должны роутиться согласно статическим маршрутам, прописанным в vrf vpn, во втором - согласно PBR через один из внешних каналов. отсюда второй вопрос - как сделать, чтобы для локальных dstIP использовались статические маршруты, а для всего остального - PBR. статические маршруты имеют distance 1, а маршруты, полученные с внешних bgp - distance 20. по идее, можно это как-то задействовать. но как - не знаю. либо еще по-другому. в роут-мапах для PBR не нашел.

 

со стороны vrf border другие проблемы. как я до этого писал - в vrf vpn гуляет ospf. от подключенных к этому сегменту vpn-серверов приходят анонсы об ip-адресах подключившихся юзеров. поэтому vrf vpn знает какой ip конечного пользователя за каким vpn-концентратором находится. чтобы не было петель в маршрутах, добавлены маршруты в null0 на все сети из которых vpn-щикам выдаваются ip-адреса. т.е., к примеру, есть маршрут на 10.0.0.0/16 null0. а когда пользователь получает ip 10.0.1.2, то в vrf vpn через ospf появляется маршрут на этот ip-адрес. так вот, если из vrf vpn в vrf border экспортировать только статические маршруты, то в vrf border появляется маршрут "10.0.0.0/16 null0". но пакеты с dstip=10.0.1.2, пришедшие снаружи , не роутятся в vrf vpn, чтобы уже там пройтись по таблице маршутизации vrf vpn, а сразу валятся на null0. поэтому приходиться редистрибьютить ospf из vrf vpn в vrf border. а это значит, что при подключении или отлючении юзера к vpn-серверу, в ospf прилетает маршрут на его ip, и этот маршрут передается в bgp vrf border (где и так содержится fullview). поэтому процесс bgp постоянно занят работой. Следовательно это лишняя нагрузка на CPU

 

Может есть более простые способы организации взаимодействия vrf?

 

Share this post


Link to post
Share on other sites
casperrr, маршрутизация между vrf и global работает по-другому, и настраивается проще.
Да, элементарно, через статические маршруты. Это когда, допустим деф. роут для врф - ип другого роутера, доступного из глобал, достаточно в статическом маршруте для этого врф добавить ключ глобал в конце. Из глобав в врф и того проще.

А вот когда нужно указать маршрут в врф-е на непосредственно присоединенную в глобал-е сетку - не будет работать. Ни по ип, ни через указание интерфейса. Во всяком случае с моим иос-ом. Проблему с бгп я озвучил, если знаете, в чем дело - научите.

Edited by casperrr

Share this post


Link to post
Share on other sites

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

"set ....." от простого (без vrf) роутинга.

т.е. было 2 цели set - одна с vrf, вторая - без. как только убрал лишнюю строчку - загрузка сразу упала. Еще знающий человек процитировал вот такую строку: "Any permit route-map sequence with no set statement will cause matching traffic to be processed by the RP"

т.е. не должно быть роут-мапов без set-строки.

 

Share this post


Link to post
Share on other sites
Может есть более простые способы организации взаимодействия vrf?

Йобанный йод!!!

Кто, #$%, кто вас научил так строить сети? Всенах, вера моя в разумность человечества иссякла.

Share this post


Link to post
Share on other sites
Может есть более простые способы организации взаимодействия vrf?

Йобанный йод!!!

Кто, #$%, кто вас научил так строить сети? Всенах, вера моя в разумность человечества иссякла.

Если Вы себя от человечества не отделяете, то как-бы себе топор на ногу...

Share this post


Link to post
Share on other sites

tgz, я ж написал:

Может есть более простые способы организации взаимодействия vrf?

 

вместо того, чтобы пальцы гнуть - лучше б подсказали.

 

PS кстати, в русской раскладке tgz=епя - понятно откуда такая тяга к матам ;)

Share this post


Link to post
Share on other sites
tgz, я ж написал:

Может есть более простые способы организации взаимодействия vrf?

 

вместо того, чтобы пальцы гнуть - лучше б подсказали.

 

PS кстати, в русской раскладке tgz=епя - понятно откуда такая тяга к матам ;)

То, что Вы делаете, мягко выражаясь не типично... Зачем сначала делить коробку на VRF, а потом мучиться и объединять их? :) Опишите более общую задачу ради которой затеяли борьбу с VRF. Если таки хочется пообъединять VRF, то наверное import map и правильно нарисованная route-map...

Share this post


Link to post
Share on other sites
tgz, я ж написал:

Может есть более простые способы организации взаимодействия vrf?

У всеми тут любимой цыски нет.

1. hairpin

2. туннель между loopback

 

вместо того, чтобы пальцы гнуть - лучше б подсказали.

У вас не сеть, а учебник того, как делать не надо. И это касается не только

межvrf'ного обмена.

 

PS кстати, в русской раскладке tgz=епя - понятно откуда такая тяга к матам ;)

Лично я тут вижу три ничего не значащие буквы. Вы видите мат. Кто из нас

болен?

 

Share this post


Link to post
Share on other sites
tgz, я ж написал:

Может есть более простые способы организации взаимодействия vrf?

 

вместо того, чтобы пальцы гнуть - лучше б подсказали.

 

PS кстати, в русской раскладке tgz=епя - понятно откуда такая тяга к матам ;)

То, что Вы делаете, мягко выражаясь не типично... Зачем сначала делить коробку на VRF, а потом мучиться и объединять их? :)

От чего же не типично? Масса может быть причин. Вот с которой я столкнулся. На каталисте 3560 с текущим sdm prefer desktop default не работает полиси роутинг. Роут-мап создается, на интерфейс не применяется. Смена профиля - перезагрузка. Перезагружать не дают. Стоит задача группе пользователей сделать свой деф. роут для инета. Раз нельзя с пбр - можно с врф. В таблице маршрутизации соотв. врф, куда их загоняем - свой деф. роут.

Типовое решение от циско есть, а задача не типична :) Погуглите на эту тему, полно примеров, когда реально нужна утечка маршрутов между врф. На certification.ru вообще пролетали интересные примеры, когда люди мутили врф для того, что бы НАТ в нем изолировать по хитрому.

Edited by casperrr

Share this post


Link to post
Share on other sites
Опишите более общую задачу ради которой затеяли борьбу с VRF. Если таки хочется пообъединять VRF, то наверное import map и правильно нарисованная route-map...

так сложилось, что есть отдельный сегмент с vpn-nas-ами и отдельно еще несколько сегментов, с которыми это nas-овский сегмент соединен напрямую, и к ним же был сегмент от бордера.

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

 

Так что насчет маршрутизации с применением policy-routing? чтобы вначале маршрутизация шла по статическим маршрутам, а если их нет - тогда уже использовался PBR? как-то можно так сделать?

Share this post


Link to post
Share on other sites
если насы пристыкую напрямую к бордеру, то пакеты со стороны нас-ов в остальные сегменты будут ходить не напрямую, а через линк от бордера к сегментам. Ну и еще некоторые тонкости, работа которых будет нарушена, если объединить бордерную часть с nas-овской. можно, конечно, оставить nas-овский сегмент на отдельном роутере, но не хочется, чтобы мощности 6509 простаивали, обслуживая только бордер.

Я не могу себе в голове представить разумную конструкцию, в которой нельзя передать пакеты напрямую (минуя Ваш бордер), но можно используя 2 разных vrf'а.

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

 

Share this post


Link to post
Share on other sites

ну да, можно. используя отдельный роутер для vpn-сегмента. но в том-то и дело, что не хочется городить цепочку из железок, а хочется использовать одну.

Share this post


Link to post
Share on other sites
чтобы вначале маршрутизация шла по статическим маршрутам, а если их нет - тогда уже использовался PBR?

set ip default next-hop a.a.a.a

в роут мапе. Заменяет для проматчевшихся пакетов только маршрут по умолчанию.

 

 

Share this post


Link to post
Share on other sites

все так, да не так. из vrf border в vrf vpn "прилетает" full-view, полученный от аплинков. т.е. будут маршруты на все префиксы, имеющиеся в интернете. и тогда set ip default next-hop уже не прокатывает - обязательно найдется маршрут в bgp. а мне надо, чтобы в инет пакеты от определенных ip выходили строго заданным каналом.

 

Можно зафильтровать все маршруты из vrf border, но тогда vrf vpn вообще не будет знать про внешние линки.

в принципе, если из border присылать в vpn только маршруты на аплинков, то это было бы самое то. и это можно сделать указанием "redistribute connected" в конфиге bgp в разделе address-family ipv4 vrf border. но как сделать, чтобы этот redistribute шел только в vrf vpn, но не разлетался на самих аплинков?

я хоть на аплинки и выставляю distribute-list out, все равно, в случае указания "redistribute connected" туда начинают рассылаться префиксы из моей AS, которые подключены непосредственно к интерфейсам, входящим в vrf border.

 

Share this post


Link to post
Share on other sites
так сложилось, что есть отдельный сегмент с vpn-nas-ами и отдельно еще несколько сегментов, с которыми это nas-овский сегмент соединен напрямую, и к ним же был сегмент от бордера.

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

Ничего не понял. Может нарисуете?

 

У всеми тут любимой цыски нет.

1. hairpin

А это как?

Share this post


Link to post
Share on other sites
А это как?
их ещё ласково называют "ушки" и "жопки" )

 

Share this post


Link to post
Share on other sites
все так, да не так. из vrf border в vrf vpn "прилетает" full-view, полученный от аплинков. т.е. будут маршруты на все префиксы, имеющиеся в интернете. и тогда set ip default next-hop уже не прокатывает - обязательно найдется маршрут в bgp. а мне надо, чтобы в инет пакеты от определенных ip выходили строго заданным каналом.
если вы трафик на нужные префиксы проматчите в pbr по src ip, то трафик этот уйдет на ip default next-hop, даже если найдеться dst в rib. pbr приоритетьнее dst routing.

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

Вам надо пропускать трафик от nas к бордеру и обратно через nets ? Я правильно понял ? Или же нужно обеспечить связь nas и nets через бордер но не через global ?

Edited by Mitya

Share this post


Link to post
Share on other sites
если вы трафик на нужные префиксы проматчите в pbr по src ip, то трафик этот уйдет на ip default next-hop, даже если найдеться dst в rib. pbr приоритетьнее dst routing.

Fail! set ip next-hop не будет смотреть на таблицу роутинг, set ip default next-hop будет.

 

У нас на 65 циске дефолт смотрит на бордер, однако пакеты с виртуальным src заворачиваются pbrом на страничку "Адрес недоступен локально"

Share this post


Link to post
Share on other sites
если вы трафик на нужные префиксы проматчите в pbr по src ip, то трафик этот уйдет на ip default next-hop, даже если найдеться dst в rib. pbr приоритетьнее dst routing.

Fail! set ip next-hop не будет смотреть на таблицу роутинг, set ip default next-hop будет.

 

У нас на 65 циске дефолт смотрит на бордер, однако пакеты с виртуальным src заворачиваются pbrом на страничку "Адрес недоступен локально"

Да. Согласен.

 

Share this post


Link to post
Share on other sites

вот схема:

vrf.jpg

 

наклонной пунктирной указано разделение двух vrf. cлева вверху - ферма VPN-NAS-ов, подключенных к vrf vpn на c6509. во всем сегменте между NAS-ами и c6509 поднят ospf, чтобы c6509 знал маршрут до каждого юзера, подключившегося по vpn

 

справа вверху - несколько сегментов с сервисами и клиентами.

 

трафик снаружи от аплинков приходит в vrf border и дальше отправляется: для vpn-щиков - в vrf vpn, для сервисов и клиентов - через R1.

 

трафик от vpn-щиков, приходя на vrf vpn, должен смаршрутизироваться в зависимости от назначения - если для сервисов и клиентов - напрямую через свитч S1 (зеленая стрелка), а если наружу, то в зависимости от того, с какого ip-адреса - на соответствующий аплинковский канал (черные пунктирные стрелки). вот тут загвоздка - как сделать такую схему маршрутизации, чтобы в vrf vpn использовалась статика (на сервисы и клиентов), а если пакеты должны идти наружу, тогда PBR (для отправки в аплинки). все остложняется тем, что в таблице маршрутов vrf vpn кроме статических маршрутов на сеть с сервисами и клиентами имеется еще и bgp-шная копия fullview, прилетевшая от vrf border. без нее никак не получится выкинуть трафик наружу.

 

 

 

Share this post


Link to post
Share on other sites

Вот картинка - это хорошо. Теперь давайте разберемся в вопросе, зачем тут 2 vrf'а. Почему не удается обойтись plain ip routing ?

Share this post


Link to post
Share on other sites

например, как без vrf зарулить трафик от vpn-щиков к "сервисы, клиенты" не через R1, а напрямую (через линк от c6509 на S1)?

просто маршруты до этих "сервисы, клиенты" прописать? но трафик из внешнего мира на "сервисы, клиенты" должен ходить через R1.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this