return

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

19 июля 2013, 08:28

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

like 0 views 9418 message 5

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

  • Получается, что в 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 не будет отброшен. Правильно ли понимаю логику?

    21 мая 2015, 21:21
  • Исправьте ACL в route-map PBR_RULES permit 30.

    12 сентября 2013, 17:13
  • нет, там есть implicit deny, даже задача была на эту тему:http://linkmeup.ru/blog/58.html
    Просто, как мне кажется, при применении route-map как policy deny значит маршрутизировать стандартно, а permit — маршрутизировать согласно policy.
    Если ошибаюсь-поправьте меня, пожалуйста)

    17 июля 2015, 21:52
  • Спасибо за задачи)
    И кстати, исправьте это-же в итоговой конфигурации.

    17 июля 2015, 21:44
  • Наташа Самойленко

    Спасибо! Исправим

    23 сентября 2013, 11:23

Ещё статьи

linkmeup ⑤ лет
Меж тем при температуре -34 за окном незаметно протекает пятилетие linkmeup. За это время набралось 4,6 млн просмотров 600к посетителей790к скачиваний подкастов6 млн минут просмотров видео на youtube.3к подписчиков вкМнохамноха ...
like 0 6182 4
22 декабря 2016
Анонс подкаста. Выпуск 53 ///UPD: Эфир состоялся
Вы знаете, что с Синистером скучно не бывает. Все подкасты с участием АлександраВыпуск №6. Информационная безопасность и эпические атаки Выпуск №8. ИБ — Best Practices и лаборатории пентестинга Выпуск №16, ...
like 293 4841 0
4 июля 2017
Анонс подкаста. Выпуск 55 \\\\\24.09.2017
Дилетантские рассуждения о квантовых коммуникациях и запутанности до добра не доводят. В 55-й выпуск к нам идёт физик-теоретик, научный сотрудник Российского Квантового Центра — Алексей Фёдоров, чтобы вывести linkmeup на ...
like 0 4257 0
21 сентября 2017