Ответ к задаче №8.9

Тесты IP SLA для проверки доступности провайдеров (в реальной жизни лучше делать более сложные тесты, по аналогии с задачей 8.8):

ip sla 1
icmp-echo 101.0.0.1 source-interface FastEthernet0/0
threshold 200
timeout 200
frequency 3
ip sla schedule 1 life forever start-time now
!
ip sla 2
icmp-echo 102.0.0.1 source-interface FastEthernet0/1
threshold 200
timeout 200
frequency 3
ip sla schedule 2 life forever start-time now

Треки, которые отслеживают тесты:

track 101 ip sla 1 reachability
!
track 102 ip sla 2 reachability

Привязка трека к статическому маршруту и создание запасного маршрута:

ip route 0.0.0.0 0.0.0.0 101.0.0.1 track 101
ip route 0.0.0.0 0.0.0.0 102.0.0.1 200

Создание ACL, которые описывают нужный трафик.
HTTP-трафик из локальной сети 10.0.1.0:

ip access-list extended HTTP
permit tcp 10.0.1.0 0.0.0.255 any eq 80

Весь трафик из сети 10.0.2.0:

ip access-list extended LAN2
permit ip 10.0.2.0 0.0.0.255 any

Весь трафик, кроме трафика из локальных сетей:

ip access-list extended EX_LAN
deny ip 10.0.1.0 0.0.0.255 any
deny ip 10.0.2.0 0.0.0.255 any
permit ip any any

Создание route-map, которая описывает правила PBR с привязкой треков для отслеживания состояния провайдеров:

route-map PBR_RULES permit 10
match ip address HTTP
set ip next-hop verify-availability 101.0.0.1 1 track 101
route-map PBR_RULES permit 20
match ip address LAN2
set ip next-hop verify-availability 102.0.0.1 1 track 102

Если в адресе отправителя будет стоять IP-адрес не принадлежащий локальным сетям, то такие пакеты будут отброшены:

route-map PBR_RULES permit 30
match ip address EX_LAN
set interface null 0

Применение правил PBR к пакетам, который генерирует сам маршрутизатор (так как локальные сети представлены loopback-интерфейсами):

ip local policy route-map PBR_RULES


Итоговая конфигурация:

hostname msk-arbat-gw1
!
track 101 ip sla 1 reachability
!
track 102 ip sla 2 reachability
!
interface Loopback1
ip address 10.0.1.1 255.255.255.0
ip nat inside
!
interface Loopback2
ip address 10.0.2.1 255.255.255.0
ip nat inside
!
interface FastEthernet0/0
description Balagan_Telecom_Internet
ip address 101.0.0.2 255.255.255.252
ip nat outside
duplex auto
speed auto
!
interface FastEthernet0/1
description Philkin_Certificate_Internet
ip address 102.0.0.2 255.255.255.252
ip nat outside
speed 100
full-duplex
!
ip nat inside source route-map BALAGAN interface Fa0/0 overload
ip nat inside source route-map PH_CERT interface Fa0/1 overload
!
ip route 0.0.0.0 0.0.0.0 101.0.0.1 track 101
ip route 0.0.0.0 0.0.0.0 102.0.0.1 200
!
!
ip access-list extended LAN
permit ip 10.0.1.0 0.0.0.255 any
permit ip 10.0.2.0 0.0.0.255 any
!
ip access-list extended HTTP
permit tcp 10.0.1.0 0.0.0.255 any eq 80
!
ip access-list extended LAN2
permit ip 10.0.2.0 0.0.0.255 any
!
ip access-list extended EX_LAN
deny ip 10.0.1.0 0.0.0.255 any
deny ip 10.0.2.0 0.0.0.255 any
permit ip any any
!
ip sla 1
icmp-echo 101.0.0.1 source-interface FastEthernet0/0
threshold 200
timeout 200
frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 102.0.0.1 source-interface FastEthernet0/1
threshold 200
timeout 200
frequency 3
ip sla schedule 2 life forever start-time now
!
route-map BALAGAN permit 10
match ip address LAN
match interface FastEthernet0/0
route-map PH_CERT permit 10
match ip address LAN
match interface FastEthernet0/1
!
route-map PBR_RULES permit 10
match ip address HTTP
set ip next-hop verify-availability 101.0.0.1 1 track 101
route-map PBR_RULES permit 20
match ip address LAN2
set ip next-hop verify-availability 102.0.0.1 1 track 102
route-map PBR_RULES permit 30
match ip address LAN
set interface null 0
!
ip local policy route-map PBR_RULES


Примечание: Эта конфигурация упрощена для задачи и, для использования в реальной сети, должна быть дополнена.
Доступность провайдеров конечно же лучше проверять не по ближайшему интерфейсу, а по аналогии с задачей 8.8.
Кроме того, так как локальная сеть представлена интерфейсами loopback, то правила PBR применены локально.
В реальной сети, скорее всего, нужны будут правила для трафика, который проходит сквозь маршрутизатор. Соответственно, правила PBR должны будут применяться в таком случае не локально, а к интерфейсу, в который входит трафик.

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

5 комментариев

avatar
Исправьте ACL в route-map PBR_RULES permit 30.
avatar
Спасибо! Исправим
avatar
Спасибо за задачи)
И кстати, исправьте это-же в итоговой конфигурации.
avatar
Получается, что в route-map в конце нету implicit deny? Поэтому нам нужно добавить ещё одно условие route-map PBR_RULES permit 30. В то время как non-HTTP traffic из сети 10.0.1.0/24, не подпадающий под условия permit 10, permit 20 и permit 30, благодаря наличию implicit permit не будет отброшен. Правильно ли понимаю логику?
avatar
нет, там есть implicit deny, даже задача была на эту тему:http://linkmeup.ru/blog/58.html
Просто, как мне кажется, при применении route-map как policy deny значит маршрутизировать стандартно, а permit — маршрутизировать согласно policy.
Если ошибаюсь-поправьте меня, пожалуйста)
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.