Ответ к задаче №8.8
0
12087
14
Создание тестов IP SLA для проверки доступности «google» и «yandex»:
ip sla 10
icmp-echo 103.0.0.10 source-interface FastEthernet0/0
threshold 200
timeout 200
frequency 3
ip sla schedule 10 life forever start-time now
ip sla 20
icmp-echo 103.0.0.20 source-interface FastEthernet0/0
threshold 200
timeout 200
frequency 3
ip sla schedule 20 life forever start-time now
Так как маршрут по умолчанию будет меняться, то надо явно прописать маршруты к тем ресурсам, доступность которых проверяется в тестах.
Маршруты должны быть через того провайдера, доступность которого будет зависеть от ответа тестов.
Статические маршруты для тестов (маршруты к «гугл» и «яндекс»):
ip route 103.0.0.10 255.255.255.255 101.0.0.1
ip route 103.0.0.20 255.255.255.255 101.0.0.1
Треки следящие за тестами:
track 110 ip sla 10 reachability
track 120 ip sla 20 reachability
Комбинированный трек, который будет в состоянии UP, если хотя бы один из внутренних треков (110 или 120) будет в состоянии UP:
track 12 list boolean or
object 110
object 120
delay down 5 up 5
Маршрут по умолчанию к Балаган Телеком с привязанным к нему треком:
ip route 0.0.0.0 0.0.0.0 101.0.0.1 track 12
Маршрут по умолчанию через Филькин Сертификат будет резервным, так как у него значение AD больше:
ip route 0.0.0.0 0.0.0.0 102.0.0.1 200
При переключении между провайдерами возникает проблема с «подвисаниями» сессий. Это связано с тем, что для сессий, которые были для переключения, остаются записи в таблице трансляций. Поэтому после переключения между провайдерами, необходимо очищать таблицу трансляций.
Для того чтобы делать это автоматически используется EEM (Embeded Event Manager).
Тут приведен простой пример, когда при смене состояния трека, каждый раз очищается таблица трансляций и генерируется сообщение (можно сделать два отдельных скрипта, для состояния UP и DOWN):
event manager applet TRACK_NAT
event track 12 state any
action 1 cli command "enable"
action 2 cli command "clear ip nat trans *"
action 3 syslog msg "Vse zarabotalo!!! Ura!"
Итоговая конфигурация:hostname msk-arbat-gw1
!
track 110 ip sla 10 reachability
!
track 120 ip sla 20 reachability
!
track 12 list boolean or
object 110
object 120
delay down 5 up 5
!
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 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
!
!
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
!
ip sla 10
icmp-echo 103.0.0.10 source-interface FastEthernet0/0
threshold 200
timeout 200
frequency 3
ip sla schedule 10 life forever start-time now
ip sla 20
icmp-echo 103.0.0.20 source-interface FastEthernet0/0
threshold 200
timeout 200
frequency 3
ip sla schedule 20 life forever start-time now
!
ip route 103.0.0.10 255.255.255.255 101.0.0.1
ip route 103.0.0.20 255.255.255.255 101.0.0.1
!
ip route 0.0.0.0 0.0.0.0 101.0.0.1 track 12
ip route 0.0.0.0 0.0.0.0 102.0.0.1 200
!
event manager applet TRACK_NAT
event track 12 state any
action 1 cli command "enable"
action 2 cli command "clear ip nat trans *"
action 3 syslog msg "Vse zarabotalo!!! Ura!"
!
0
12087
14
Ещё статьи
14 коментариев
Добрый день.
Если у вас ещё до конца не уложилось в голове, как настроить маршрутизацию между двумя узлами через коммутатор, то, лучше побольше попрактиковаться.
Я не стал подробно останавливаться на этой теме, потому что она была рассмотрена прежде.
К сожалению, сейчас не могу вернуться к деталям статьи, которой занимался 4 года назад.
Но насчёт маршрутизации комментарий дам:
Однозначно нет — для связности у вас обязательно должны быть адреса на обоих концах.
Подскажите, пожалуйста, в чём разница между threshold и timeout под ip sla 10. Если правильно понимаю, timeout — это сколько маршрутизатор ждёт echo reply (в миллисекундах), т.е. по истечении этого таймера пришедший echo reply не обрабатывается. А какой таймер задаётся командой threshold?
Вы уверены, что route-map нужно будет применить на интерфейс, ведь в данном случае правила PBR используются ПАТ`ом?
Может я что-то не так понял? Объясните, пожалуйста, тёмному.
Отлично. Я очень радуюсь, когда человек разбирается сам. Это барьер, после которого приходит новый уровень понимания вопроса.
Удачного изучения!
Разобрался. Увы, на работе не получается смотреть видео вначале урока, тогда как там Вами были описаны нужные детали по настройкам адресов на нашем роутере и роутере провайдера. За это прошу прощение. Но что бы эти роутеры увидели друг друга, мне недостаточно было создать vlan 6 на свиче-«облако» провайдера, как было у Вас в видео-уроке. Пришлось на fa0/0 этого свича разрешить trunk vlan 6 и на fa0/4, который идет к роутеру провайдера, разрешить trunk vlan 6. И только после этих действий наши свичи увидели друг друга.
Извините за беспокойство.
Спасибо большое за ответ.
Вы имеете ввиду, порт, который смотрит в мир должен иметь 198.51.100.1, а тот что смотрит внутрь сети провайдера, будет 198.0.2.1, или я опять что-то не правильно уловил?
Threshold
Параметр threshold используется для указания верхнего порогового значения времени.
Значение по умолчанию 5000ms. Значение threshold не должно превышать значение параметра timeout.
Значение параметра threshold для операции:
IP SLA UDP jitter:
— устанавливает верхнее пороговое значение для среднего значения jitter
для других операций:
— устанавливает верхнее пороговое значение для измерения RTT (round-trip time)
IP SLA, соответственно, высчитывает количество раз, когда среднее значение jitter или RTT превышало указанное значение threshold.
Плюс на threshold может реагировать track:
При настройке связки IP SLA и Track, есть два варианта: state и reachability.
Настройка с параметром state:
или с параметром reachability:
Отличия этих вариантов настройки в том, как они работают с кодом OverThreshold:
state:
— Up — код OK
— Down — другие коды
reachability:
— Up — код OK или код OverThreshold
— Down — другие коды
route-map это объект, который может использоваться:
1. PBR
Тогда route-map применяется к интерфейсу, в которых входит трафик. И там используются критерии match с описанием трафика, который надо перенаправить по правилам, и set, где, как правило, указан next-hop маршрутизатор (но может быть и исходящий интерфейс).
2. NAT
Как правило, как в этой задаче, для указания интерфейса. То есть в такой route-map у нас только условие match.
3. redistribute. перераспределение маршрутов между разными процессами
Тогда route-map используется как фильтр, где можно указать какие маршруты помещать, например, из OSPF в EIGRP. Кроме того, внутри route-map, с помощью set можно менять параметры маршрутов: метрику, тип, тег.
4. BGP
Для BGP это основной инструмент с помощью которого описываются политики.
route-map работает и как фильтр, и, опять-таки, с помощью set можно менять параметры маршрутов. В BGP их достаточно много, они называются атрибуты пути.
И, наконец, по поводу статьи и лабораторной 1. Это просто опечатка 🙂
Спасибо большое, что заметили!
Я сейчас исправлю ее
Понял. Если в route-map есть set, т.е. происходит действие над пакетом, тогда это PBR. Просто я инструмент route-map сразу относил к PBR.
Теперь с Лабораторной 1.
Для чего на ин-ах FastEthernet0/0 и 1/0 применён route-map, если он для NAT?
Так там тоже не применяется.
Подождите. давайте по порядку.
В данной задаче и в Лабораторной 1 из статьи на xgu.ru не используется PBR.
Трафик маршрутизируется по статическим маршрутам. Для отслеживания работоспособности провайдера, используются тесты IP SLA, которые через track привязаны к маршрутам.
route-map используется для правил трансляции (для PAT), так как в циско так сложилось, что эти правила трансляции срабатывают в порядке написания. То есть PAT сам по себе не мониторит на какой интерфейс смаршрутизировался трафик.
Для того чтобы PAT реагировал на это, мы и создаем route-map. В которой запись «match interface FastEthernet0/x» позволяет указать, что:
если трафик «выходит» через интерфейс f0/0 (match interface FastEthernet0/0), то применяется одно правило:
ip nat inside source route-map BALAGAN interface Fa0/0 overload
Если трафик «выходит» через интерфейс f0/1 (match interface FastEthernet0/1), то применяется другое правило:
ip nat inside source route-map PH_CERT interface Fa0/1 overload
То есть, эти route-map используются PAT, а не PBR. И они применяются, но в правиле NAT, а не на интерфейсе.
К интерфейсу route-map применяется, когда она описывает правила PBR.
Например, в лабораторной 2 есть раздел по балансировке. И один из вариантов балансировки — это использование PBR:
Политика PBR:
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 even
set ip next-hop verify-availability 192.168.2.6 2 track 2
Применение:
interface FastEthernet0/0
ip policy route-map POLICY
xgu.ru/wiki/%D0%A0%D0%B5%D0%B7%D0%B5%D1%80%D0%B2%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82-%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB%D0%BE%D0%B2_%D0%B1%D0%B5%D0%B7_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_BGP#.D0.91.D0.B0.D0.BB.D0.B0.D0.BD.D1.81.D0.B8.D1.80.D0.BE.D0.B2.D0.BA.D0.B0_.D1.81_.D0.B8.D1.81.D0.BF.D0.BE.D0.BB.D1.8C.D0.B7.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5.D0.BC_Policy_routing_.28PBR.29
Тогда в вашей статье «Резервирование Интернет-каналов без использования BGP» на Xgu.ru в Лабораторной 1 для интерфейсов FastEthernet0/0 и 1/0 тоже ненужно применять route-map?
Если ошибаюсь, то заранее прошу прощения. И уж если ошибаюсь, то наставьте, пожалуйста, на путь истинный.
Ой…
Прошу прощения, я перепутала задачи.
Тут это примечание просто случайно затесалось из другой задачи.
Я просто невнимательно посмотрела, немного сбилась из-за слов, что тут «правила PBR используются PAT» и понеслась не в ту сторону. Тут вообще не PBR, просто route-map. Которые нужны для NAT.
То есть, Вы все правильно понимаете, это примечание тут просто по ошибке оказалось.
я понимаю, что NAT работает после маршрутизации
я понимаю, что PBR нужно работает на входящий трафик
Просто под решением написано:
Но локально правила PBR должны применяться командой ip local policy route-map NAME_MAP, или я ошибаюсь?
Если в конфиге выше заменить L1 и L2 на, например, FastEthernet1/0 и FastEthernet1/1 (пусть они смотрят в LAN), то всё будет работать. Ничего к этим (F1/0, F1/1) интерфейсам применять не нужно.
Речь идёт о конфигурации выше.
Или я неправ?
Уверена 🙂
Дело в том, что NAT срабатывает после маршрутизации (стандартной). То есть, не важно NAT или PAT, это будет происходить позже.
То есть, если представить маршрутизатор с f0/0 внутренним интерфейсом и f0/1 внешним, то когда трафик идет из внутренне сети наружу, то порядок такой:
LAN—f0/0—> |routing —> NAT| —f0/1—> Internet
А с PBR нам надо «перехватить» трафик до маршрутизации и завернуть его туда, куда надо нам.
Поэтому правила PBR должны применяться при «входе» в маршрутизатор, то есть, в нашем случае, на интерфейсе f0/0. Чтобы они сработали раньше, чем стандартная маршрутизация.
Всегда, когда Вам нужно будет перенаправить сквозной трафик (тот который идет через маршрутизатор) с помощью PBR, надо применять route-map ко входящему интерфейсу. Если надо перенаправить то, что генерирует маршрутизатор, применяется локально