маршрутизация между vrf

[loginex]

есть циска WS-SUP720-3BXL+WS-X6704-10GE+ACE10-6500-K9

ACE10-6500-K9 используется исключительно для ната серых айпи адресов(10./8), на нем лицензия на 4гигабита

 

логическая схема, а так же packet flow выглядит как-то так(jpg):

зеркало http://img405.imageshack.us/i/ciscological.jpg/

 

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

Вопрос: как правильно(и хорошо) реализовать траффик для реальных айпи адресов так, чтобы они шли в обход модуля ACE10(из-за лицензии) ?

 

В vrf bgp можно сделать статические маршруты на сети реальных айпи адресов, вопрос только в том, какой шлюз указать для них ?

Возможно если поднять интерфейсы на этих двух vrf и как-то их скоммутировать между собой(на цискокоме предлагают сделать перевязку между двумя физическими интерфейсами, но это не является правильным решением, особенно если это дорогие 10G интерфейсы), тогда прописав статический маршрут из vrf bgp на интерфейс vrf localnet, входящий трафик из интернета пойдет в обход модуля ACE10. В свою очередь в vrf localnet сделать PBR для реальников и назначить им некстхоп в виде интерфейса в vrf bgp. Тут встает вопрос - как соединить эти два интерфейса в разных vrf, может кто может подсказать, или же может есть более элегантное решение прямо под носом ?

p.s. уже была похожая тема: http://forum.nag.ru/forum/index.php?showtopic=51102, но в ней я не нашел ответа на свой вопрос.

[sirmax]

у вас есть глобальная таблица? У меня когда-то не получилось сделать полноценный обмен между глобойал и врф. Все встало на свои места когда все вынес в ВРФы....

или я чето недопонял?

 

[loginex]

у вас есть глобальная таблица? У меня когда-то не получилось сделать полноценный обмен между глобойал и врф. Все встало на свои места когда все вынес в ВРФы....

или я чето недопонял?

в глобальной таблице разве что один loopback интерфейс есть, все остальное в vrf

[s.lobanov]

loginex

В чём вообще смысл было делать vrf bgp и заталкивать туда fullview? Принимайте префиксы от внешних операторов в глобальную таблицу, туда же поселите клиентов с реальниками. nat для всех остальных делайте между vrf local и пулом(ами) из глобальной таблицы.

 

Если же всё-таки хотите плодить vrf'ы, то выносите клиентов с реальными ip в отдельный vrf (например, local2) и делайте import и export между vrf bgp и vrf local2. Или сразу размещайте клиентов с реальниками в vrf bgp, это будет тоже самое, но не надо будет поднимать mp-bgp ради import и export.

[loginex]

loginex

В чём вообще смысл было делать vrf bgp и заталкивать туда fullview? Принимайте префиксы от внешних операторов в глобальную таблицу, туда же поселите клиентов с реальниками. nat для всех остальных делайте между vrf local и пулом(ами) из глобальной таблицы.

смысл в том, что этих vrf с bgp и fullview предполагается не 1 шт. а без фульвью еще несколько. поселить клиентов с реальниками отдельно нельзя, они терминируются задолго до циски и приходят по одному маршруту с внутренними адресами.

Если же всё-таки хотите плодить vrf'ы, то выносите клиентов с реальными ip в отдельный vrf (например, local2) и делайте import и export между vrf bgp и vrf local2. Или сразу размещайте клиентов с реальниками в vrf bgp, это будет тоже самое, но не надо будет поднимать mp-bgp ради import и export.

нельзя их вынести отдельно перед железкой, только если ставить еще одну циску с PBR на ней.

 

p.s. я понимаю, что покритиковать схему все любят, особенно не зная всей картины, но все останется так, как есть.

[s.lobanov]

Тогда попробуйте на интерфейсе, с которого приходят маршруты в vrf local(там где реальники с серыми в перемешку) сделать route-map, в котором выполнить set vrf по acl

(config-route-map)#match ip address ...

(config-route-map)#set vrf ...

Таким образом, я считаю, можно заталкать абонентов с реальниками в vrf bgp.

[loginex]

Тогда попробуйте на интерфейсе, с которого приходят маршруты в vrf local(там где реальники с серыми в перемешку) сделать route-map, в котором выполнить set vrf по acl

(config-route-map)#match ip address ...

(config-route-map)#set vrf ...

Таким образом, я считаю, можно заталкать абонентов с реальниками в vrf bgp.

вот этого не знал, спасибо, попробую.

[s.lobanov]

не, похоже так в лоб не получится. на сайте циски написано, что если интерфейс уже принадлежит какому-то vrf'у (ip vrf forwarding), то set vrf делать route-map'ом нельзя. Т.е. надо убирать интерфес из vrf'а , route-map'ом по acl'ям заталкивать нужные ip в нужные vrf, но тогда не понятно что делать с ospf'ом, т.е. как тогда принимать маршруты из ospf в vrf local

[loginex]

А как на счет такого варианта:

поднимаем vlan15 в vrf local с адресом1/30

vlan 16 в vrf bgp с адресом2/30

эти два интерфейса добавляем в один бридж: bridge-group 1

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

далее bridge irb

bridge 1 protocol vlan-bridge

И вроде бы и интерфейсы vlan15 и 16 подняты(навесил их на транковый интерфейс, где линк поднят на физ. интерфейсе), но друг друга они не пингуют, более того, даже mac адресов противоположенных интерфейсов в своих vrf нету(т.е. в localnet vrf нету мак адреса от vlan16 интерфейса.

чувствую, что придеться все решать по тупому: делать петельки между гигабитными портами, возможно даже несколько штук(объединив пары в IEEE 802.3ad - link aggr)