[artplanet]

Читаем статью http://xgu.ru/wiki/Cisco_PBR и возникает несколько вопросов если изменить немного конфигурацию, а именно в обоих строчках роутмапа ставим один и тот же ACL:

route-map POLICY permit 10
match ip address odd
set ip next-hop verify-availability 192.168.1.5 1 track 1
route-map POLICY permit 20
match ip address odd
set ip next-hop verify-availability 192.168.2.6 2 track 2

 

Суть в том - что хотим сделать полноценный резерв. И в случае когда первый next-hop не работает - трафик по тому же ACL полностью отправлялся по другому ACL

а когда первый nexthop доступен - то весь трафик отправляется на первый next-hop

 

Но если Мы правильно понимаем работу route-map - то пакеты которые попали в acl в 10ом правиле route-map уже не попадут в 20ое правило, даже при условии что next-hop там не доступен. И все пакеты будут обработаны стандартной таблицой маршрутизации.

 

Есть ли у кого идеи как реализовать схему:

один ACL, если первый next-hop доступен - весь трафик отправляем на него, если первый next-hop не доступен - отправляем весь трафик на второй next-hop, и вот только если оба next-hop не доступны - то только тогда отправляем трафик по стандартной таблице маршрутизации.

Изменено 9 июля, 2017 пользователем artplanet

[VitMain]

http://www.cisco.com/c/en/us/support/docs/ip/ip-routed-protocols/48003-pbrtracking.html

 

route-map POLICY permit 10
match ip address odd
set ip next-hop verify-availability 192.168.1.5 1 track 1
route-map POLICY permit 20
match ip address odd
set ip next-hop verify-availability 192.168.2.6 2 track 2
route-map POLICY permit 30
match ip address odd

должно помочь

[artplanet]

эхххх....

на 6500 шасси есть подобная команда

(config-route-map)#set ip next-hop ?
 A.B.C.D              IP address of next hop
 dynamic              application dynamically sets next hop
 encapsulate          Encapsulation profile for VPN nexthop
 peer-address         Use peer address (for BGP only)
 recursive            Recursive next-hop
 self                 Use self address (for BGP only)
 verify-availability  Verify if nexthop is reachable

а вот на 4900m на которые мы решили перейти нет команды.

 

config-route-map)#set ip next-hop ?       
 A.B.C.D       IP address of next hop
 dynamic       application dynamically sets next hop
 peer-address  Use peer address (for BGP only)
 recursive     Recursive next-hop
 self          Use self address (for BGP only)

 

софт System image file is "bootflash:/cat4500e-entservicesk9-mz.152-2.E6.bin"

как я понял на 49xx серии можно забыть о verify-availability и аналогов нет ?

[zstas]

а статику с треками даёт нарисовать?

[artplanet]

статика не катит - так как нужен именно PBR - то есть нужно отправлять не весь трафик - а определенный (по source ip)

[zstas]

это понятно. просто вы можете указать next-hop - ип который статиком заворачивается за определенный next-hop, который имеет трек уже.

ну аля

route-map PBR permit 10
match ip address odd
set ip next-hop 1.1.1.1

ip route 1.1.1.1 255.255.255.255 192.168.1.5 track 1 10
ip route 1.1.1.1 255.255.255.255 192.168.2.6 track 2 20

последнее - приоритет. за точность не ручаюсь - лень лезть в мануалы.

 

ну и, конечно, не факт что всё это взлетит :)

[artplanet]

хз как такое переварит пару миллионов пакетов в секунду, нужно будет стенд сделать

[artplanet]

начинаем поднимать стенд, итак, если PBR Имеет такой вид:

show route-map TEST-PBR
route-map TEST-PBR, permit, sequence 10
 Match clauses:
   ip address (access-lists): TEST-PBR 
 Set clauses:
   ip next-hop 10.10.128.1
 Policy routing matches: 21 packets, 1260 bytes

 

то трасса идет

 1 80.87.207.152 0 msec 0 msec 0 msec
 2 10.10.128.1 [AS 1299] 0 msec 0 msec 0 msec

второй прыжок верный

 

А вот если мы делаем PBR вида

route-map TEST-PBR, permit, sequence 10
 Match clauses:
   ip address (access-lists): TEST-PBR 
 Set clauses:
   ip next-hop 192.168.1.1
 Policy routing matches: 21 packets, 1260 bytes

и просто прописываем статик роут:

ip route 192.168.1.1 255.255.255.255 10.10.128.1

 

то трассирвока становится:

 1 80.87.207.152 0 msec 0 msec 0 msec
 2 80.87.207.155 [AS 1299] 0 msec 0 msec 0 msec

то есть 2 прыжок не верный и статик роут просто игнорируется. Видимо для nexthop требуется наличие arp записи

в тоже время трасса до ip 192.168.1.1 имеет вид:

 1 80.87.207.152 0 msec 4 msec 0 msec
 2 10.10.128.1 [AS 1299] 0 msec 0 msec 0 msec

 

так что получается что next-hop на тот хост который доступен через статик роут не получится сделать

[artplanet]

пока что видится только один вариант

event manager applet InternetSupremet
event syslog pattern "ip sla 1 reachability Up->Down"
action 1.0 cli command "clear ip nat translation *"

 

через подобное извращение программировать нужный next hop в PBR

[zstas]

хм, на asr9k в принципе такая же логика - next-hop должен быть directly-connected и иметь arp запись.

ну значит только вариант с извратом через EEM

[artplanet]

через EEM получилось реализовать то что было нужно - но это изврат. Но работать будет.

[ikiliikkuja]

Но если Мы правильно понимаем работу route-map - то пакеты которые попали в acl в 10ом правиле route-map уже не попадут в 20ое правило, даже при условии что next-hop там не доступен. И все пакеты будут обработаны стандартной таблицой маршрутизации.

 

Есть ли у кого идеи как реализовать схему:

один ACL, если первый next-hop доступен - весь трафик отправляем на него, если первый next-hop не доступен - отправляем весь трафик на второй next-hop, и вот только если оба next-hop не доступны - то только тогда отправляем трафик по стандартной таблице маршрутизации.

 

почему бы не

route-map POLICY permit 10
match ip address odd
set ip next-hop verify-availability 192.168.1.5 1 track 1
set ip next-hop verify-availability 192.168.2.6 2 track 2

[zhenya`]

Нет у него verify-availability

[artplanet]

а обновив софт с 152-2.E6.bin до 152-4.E2.bin verify-availability появился.

интересно с чего такие изменения.

[v_r]

Почитайте release notes к IOS, они для 49й постоянно допиливают какие-то полезные мелочи. Правда и неприятные баги в работавших фичах добавляются, например на 152-4.E в IPv6 BGP-сессии префиксы от не-Cisco соседа не принимались.

[vurd]

Странно, если бы там это не работало, но речь в топике про 4900

[Giga-Byte]

vurd

действительно. заглянул на форум мысли развлечь от авраала за чашкой чая.