Требуется воспроизвести функционал iproute2:

ip route add default via 10.10.0.1 dev eth0 table One
ip route add default via 10.10.2.1 dev eth0 table One2

ip rule add from 10.10.15.0/24 table One
ip rule add from 10.10.17.0/24 table One2

в cisco усмотрел для себя два пути, первый route-map и второй vrf.

что делал по route-map:

!
access-list 10 permit 10.10.15.0 0.0.0.255
!
route-map Mymap40 permit 10
match ip address 10
set ip default next-hop 10.10.0.1
!
казалось бы всё хорошо, но
Вариант с set ip default next-hop 10.10.0.1 даёт результат:
Route-map Mymap40 not supported for Policy-Based Routing

принимается только вариант с set ip next-hop 10.10.0.1 , который игнорирует маршруты на текущей cisco и передаёт пакеты как есть на удалённый роутер 10.10.0.1. Почему так - не важно, по другому с текущим оборудованием не будет. Значит route-map это решение с ограничениями, не подходит.

Взялся за vrf и загруз, потому что понять идеологию построения виртуального роутера не смог. Кроме того прочел, что "переливать трафик между vrf-ами (vrf route leaking) - это плохой дизайн." Как пытался делать:

ip vrf One
rd 1:1

ip vrf One2
rd 1:2

на интерфейсе 10.10.15.1 давал команду:
ip vrf forwarding One

на интерфейсе 10.10.17.1 давал команду:
ip vrf forwarding One2

добавил маршруты:
ip route vrf One 0.0.0.0 0.0.0.0 10.10.0.1
ip route vrf One2 0.0.0.0 0.0.0.0 10.10.2.1

и... ничего не получилось. Скорее всего я совершенно не понимаю работу vrf. Мог бы кто-то подсказать куда думать дальше?

• Аналог iproute2 в cisco,VolanD, 17:33 , 18-Дек-14
• Аналог iproute2 в cisco,ShyLion, 07:01 , 19-Дек-14
  • Аналог iproute2 в cisco,fantom, 11:53 , 19-Дек-14
    • Аналог iproute2 в cisco,Merridius, 12:31 , 19-Дек-14
• Аналог iproute2 в cisco,eek, 12:45 , 19-Дек-14
  • Аналог iproute2 в cisco,ShyLion, 13:01 , 19-Дек-14
    • Аналог iproute2 в cisco,eek, 14:29 , 19-Дек-14

Скажите что хотите сделать.

> set ip default next-hop 10.10.0.1

это выключает CEF, при приличной загрузке умрет CPU

> Взялся за vrf и загруз, потому что понять идеологию построения виртуального роутера
> не смог. Кроме того прочел, что "переливать трафик между vrf-ами (vrf
> route leaking) - это плохой дизайн." Как пытался делать:

https://www.google.com/search?q=cisco+vrf+route+leaking

первая же ссылка

>> set ip default next-hop 10.10.0.1
> это выключает CEF, при приличной загрузке умрет CPU
>> Взялся за vrf и загруз, потому что понять идеологию построения виртуального роутера
>> не смог. Кроме того прочел, что "переливать трафик между vrf-ами (vrf
>> route leaking) - это плохой дизайн." Как пытался делать:
> https://www.google.com/search?q=cisco+vrf+route+leaking
> первая же ссылка

ip на интерфейсе надо назначать ПОСЛЕ
ip vrf forwarding One2
кроме того
вроде как очень желательно
route-target в ip vrf добавить... т.е. какие маршруты для этого vrf-а считать родными.

>[оверквотинг удален]
>>> не смог. Кроме того прочел, что "переливать трафик между vrf-ами (vrf
>>> route leaking) - это плохой дизайн." Как пытался делать:
>> https://www.google.com/search?q=cisco+vrf+route+leaking
>> первая же ссылка
> ip на интерфейсе надо назначать ПОСЛЕ
> ip vrf forwarding One2
> кроме того
> вроде как очень желательно
> route-target в ip vrf добавить... т.е. какие маршруты для этого vrf-а считать
> родными.

Route-target необходим для MPLS L3VPN. По сути с помощью RT добавляется community для ваших префиксов в VRF.

Для Vrf-lite достаточно RD.

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

> VRF между собой можно связать через физические интерфейсы, что зачастую решает бОльшую
> часть проблем, по крайней мере на момент обкатки дизайна.

Да, но только для обкатки. Два раза обрабатывать один и то-же траффик - злое зло. Плавали, знаем.

>> VRF между собой можно связать через физические интерфейсы, что зачастую решает бОльшую
>> часть проблем, по крайней мере на момент обкатки дизайна.
> Да, но только для обкатки. Два раза обрабатывать один и то-же траффик
> - злое зло. Плавали, знаем.

Согласен. Случаи разные бывают.

Например бывает лучше один и тот же трафик обработать 3 раза, но сделать экономию капекса на 70% бюджета.