Перейти к содержимому
Калькуляторы

обмен трафиком между 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-сегментов?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
На 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 стал показывать дикие цифры (возможно руки кривые, разобраться не смог, кол-во маршрутов, утекающих из глобала в врф и обратно небольшое). Пробовал эксперимента ради через тунели с лупбэка на лупбэк - работает, но тоже соответсвенно на проце. Оставил через соединение портов в итоге.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
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 не хотите ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
casperrr, маршрутизация между vrf и global работает по-другому, и настраивается проще.
Да, элементарно, через статические маршруты. Это когда, допустим деф. роут для врф - ип другого роутера, доступного из глобал, достаточно в статическом маршруте для этого врф добавить ключ глобал в конце. Из глобав в врф и того проще.

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

Изменено пользователем casperrr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у меня была проблема с загрузкой 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-строки.

 

Поделиться сообщением


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

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

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

Поделиться сообщением


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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
tgz, я ж написал:

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
tgz, я ж написал:

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

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

1. hairpin

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

 

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

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

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

 

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

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

болен?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
tgz, я ж написал:

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

 

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

 

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

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

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

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

Изменено пользователем casperrr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Опишите более общую задачу ради которой затеяли борьбу с VRF. Если таки хочется пообъединять VRF, то наверное import map и правильно нарисованная route-map...

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

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

 

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

Поделиться сообщением


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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


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

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

все так, да не так. из 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.

 

Поделиться сообщением


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

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

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

 

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

1. hairpin

А это как?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
А это как?
их ещё ласково называют "ушки" и "жопки" )

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
все так, да не так. из 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 ?

Изменено пользователем Mitya

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
если вы трафик на нужные префиксы проматчите в 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ом на страничку "Адрес недоступен локально"

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
если вы трафик на нужные префиксы проматчите в 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ом на страничку "Адрес недоступен локально"

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вот схема:

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. без нее никак не получится выкинуть трафик наружу.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас