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

Cisco PBR track

Читаем статью 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 не доступны - то только тогда отправляем трафик по стандартной таблице маршрутизации.

Edited by artplanet

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

эхххх....

на 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 и аналогов нет ?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

это понятно. просто вы можете указать 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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

начинаем поднимать стенд, итак, если 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 на тот хост который доступен через статик роут не получится сделать

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Но если Мы правильно понимаем работу 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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

vurd

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

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