Обычно пограничный интернет-маршрутизатор (Internet Edge router) подключен к двум разным поставщикам услуг. Это защищает офис от сбоев в работе одного из провайдеров. Топология может выглядеть следующим образом:
Два интернет-провайдера (ISP) используются в режимах активный/ожидания с помощью статических маршрутов. Обычно это реализуется с применением двух маршрутов по умолчанию, где один из них является плавающим статическим маршрутом. Это будет выглядеть примерно так:
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY
ip route 0.0.0.0 0.0.0.0 203.0.113.9 200 name SECONDARYПри такой конфигурации, если интерфейс к ISP1 выйдет из строя, будет установлен плавающий статический маршрут, который имеет административное расстояние (AD) 200, и трафик будет проходить через ISP2. Недостатком этой конфигурации является то, что она работает только в случае выхода из строя физического интерфейса. Что произойдет, если на оборудовании CPE провайдера ISP1 интерфейс для клиента работает, а для ядра нет? Что произойдет, если произойдет сбой в другой части сети провайдера? Что если все интерфейсы работают, но в сети возникли проблемы с протоколом BGP?
В подобных сценариях, поскольку интерфейс клиента для ISP1 все еще работает, трафик будет поступать к ISP1, но не достигнет конечного пункта назначения. Затем он будет заблокирован. Чтобы предотвратить такие сбои, можно использовать функцию IP SLA для отслеживания чего-то важного, например, услуги, предоставляемой провайдером, или же за пределами сети, чтобы статический маршрут был инсталлирован только в том случае, если услуга доступна. Как же выбрать, что отслеживать?
Выбор того, что отслеживать
Какие сервисы важны для интернет-провайдера? Обычно они предоставляют услугу резолвера. Когда резолверы не работают, люди не могут просматривать интернет, поэтому она так важна для провайдера. Что еще? У провайдера есть веб-страница, где вы заказываете продукты и взаимодействуете с ними, например verizon.com. Если сайт не работает - поставщик теряет деньги. Данная услуга играет для него существенную роль. Используя Verizon в качестве примера, давайте выясним, какие из IP-адресов интересно отслеживать. Мы можем сделать это с помощью dig на хосте Linux. Сначала посмотрим, что разрешается на verizon.com (резолвинг):
dig verizon.com
; <<>> DiG 9.16.1-Ubuntu <<>> verizon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52122
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;verizon.com. IN A
;; ANSWER SECTION:
verizon.com. 600 IN A 192.16.31.89
;; Query time: 40 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: sön aug 21 08:54:45 CEST 2022
;; MSG SIZE rcvd: 56Интересующий нас IP-адрес - 192.16.31.89. Что касается резолверов, то они, скорее всего, зависят от региона и сервиса, но с другой стороны, мы можем проверить, какие серверы имен использует Verizon для домена verizon.com. Они также будут важны.
daniel@devasc:~$ dig ns verizon.com
; <<>> DiG 9.16.1-Ubuntu <<>> ns verizon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55703
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;verizon.com. IN NS
;; ANSWER SECTION:
verizon.com. 3600 IN NS s1ns1.verizon.com.
verizon.com. 3600 IN NS ns2.edgecastdns.net.
verizon.com. 3600 IN NS s3ns3.verizon.com.
verizon.com. 3600 IN NS s2ns2.verizon.com.
verizon.com. 3600 IN NS ns1.edgecastdns.net.
verizon.com. 3600 IN NS s4ns4.verizon.com.
verizon.com. 3600 IN NS ns3.edgecastdns.net.
verizon.com. 3600 IN NS ns4.edgecastdns.net.
;; Query time: 624 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: sön aug 21 09:00:26 CEST 2022
;; MSG SIZE rcvd: 207Здесь находится несколько серверов. Обратите внимание, что, похоже, Verizon использует стороннюю службу DNS для обеспечения отказоустойчивости своих серверов имен. Выберите сервер и проверьте IP:
dig s1ns1.verizon.com
; <<>> DiG 9.16.1-Ubuntu <<>> s1ns1.verizon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12917
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;s1ns1.verizon.com. IN A
;; ANSWER SECTION:
s1ns1.verizon.com. 3573 IN A 192.16.16.5
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: sön aug 21 09:00:52 CEST 2022
;; MSG SIZE rcvd: 62IP-адрес 192.16.16.5 - это то, что мы ищем. Теперь у нас есть два IP-адреса, которые мы можем отслеживать. В общих чертах это выглядит следующим образом:
Это хорошее начало. Мы выяснили важные услуги для интернет-провайдера. Однако это не лучший способ для полного определения эксплуатационной пригодности вашего интернет-сервиса. Почему?
Наличие этих сервисов не гарантирует доступность по отношению к большому интернету.
Эти сервисы могут не реагировать на пакеты ICMP Echo или быть ограниченными по скорости.
Хотя мы смогли добиться измерения доступности за пределами CPE провайдера, необходимо убедиться, что можно получить доступ к услугам, которые не являются локальными для ISP. Обычно люди начинают отслеживать что-то вроде 8.8.8.8, который является хорошо известным сервисом Google резолвера. Это будет выглядеть следующим образом:
По сравнению с предыдущим сценарием, значение состояние “здоровья” 8.8.8.8 должно быть более релевантным, поскольку оно не является локальным для провайдера. Однако, поскольку это резолвер, ответ на ICMP Echo не входит в перечень его обязанностей, из этого следует, что ICMP может быть ограничен по скорости. Давайте реализуем отслеживание 8.8.8.8, а затем опишем некоторые проблемы/предостережения.
Базовая реализация и предостережения
Начнем со стандартной реализации отслеживания IP SLA, а затем я опишу некоторые проблемы/предостережения. Вот базовая конфигурация:
interface GigabitEthernet1
ip address 203.0.113.2 255.255.255.248
!
interface GigabitEthernet2
ip address 203.0.113.10 255.255.255.248
!
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 1
ip route 0.0.0.0 0.0.0.0 203.0.113.9 200 name SECONDARY
!
ip sla 1
icmp-echo 8.8.8.8 source-ip 203.0.113.2
ip sla schedule 1 life forever start-time now
!
track 1 ip sla 1 reachabilityИнтерфейс граничного роутера GigabitEthernet1 подключен ISP1, а GigabitEthernet2 - к ISP2. Для проверки настройки IP SLA можно использовать следующие команды:
Edge#show ip sla sum
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending
All Stats are in milliseconds. Stats with u are in microseconds
ID Type Destination Stats Return Last
Code Run
-----------------------------------------------------------------------
*1 icmp-echo 8.8.8.8 RTT=8 OK 44 seconds ag
o
Edge#show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest RTT: 7 milliseconds
Latest operation start time: 07:10:40 UTC Mon Aug 22 2022
Latest operation return code: OK
Number of successes: 14
Number of failures: 0
Operation time to live: Forever
Edge#show ip route track-table
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 1 state is [up]
Edge#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 1, metric 0, candidate default path
Routing Descriptor Blocks:
* 203.0.113.1
Route metric is 0, traffic share count is 1Все происходит так, как и ожидалось. IP SLA работает. Трекер запущен. Маршрут по умолчанию к ISP1 установлен. Теперь давайте смоделируем отказ провайдера ISP1. Я реализую это в фоновом режиме, используя ACL в моей лаборатории, фильтруя пакеты ICMP Echo. Давайте проверим журналы:
Aug 22 07:37:22.171: %TRACK-6-STATE: 1 ip sla 1 reachability Down -> Up
Aug 22 07:37:32.171: %TRACK-6-STATE: 1 ip sla 1 reachability Up -> Down
Aug 22 07:37:42.171: %TRACK-6-STATE: 1 ip sla 1 reachability Down -> Up
Aug 22 07:37:52.171: %TRACK-6-STATE: 1 ip sla 1 reachability Up -> Down
Aug 22 07:38:02.171: %TRACK-6-STATE: 1 ip sla 1 reachability Down -> UpЭто выглядит не очень хорошо. Почему происходит флапинг? Давайте проверим некоторые маршруты:
Edge#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 200, metric 0, candidate default path
Routing Descriptor Blocks:
* 203.0.113.9
Route metric is 0, traffic share count is 1
Edge#show ip cef 8.8.8.8
0.0.0.0/0
nexthop 203.0.113.9 GigabitEthernet2
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8
203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet2, addr 203.0.113.9Это выглядит вполне ожидаемо. Маршрут по умолчанию теперь указывает на 203.0.113.9. Обратите внимание, какой следующий переход (next-hop) для 8.8.8.8, хотя... Я еще вернусь к этому, но сначала давайте проверим маршрутизацию несколько секунд спустя:
Edge#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 1, metric 0, candidate default path
Routing Descriptor Blocks:
* 203.0.113.1
Route metric is 0, traffic share count is 1
Edge#show ip cef 8.8.8.8
0.0.0.0/0
nexthop 203.0.113.1 GigabitEthernet1
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8
203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1Происходит флапинг маршрутов между 203.0.113.1 и 203.0.113.9. Почему так? Потому что изначально пакеты SLA проходят через GigabitEthernet1. Затем этот путь дает сбой, поэтому пакеты SLA отправляются на GigabitEthernet2, поскольку маршрут по умолчанию к Gi1 удален. Когда пакеты SLA отправляются к Gi2, они достигают цели. Поскольку SLA выполнено успешно, отслеживаемый маршрут по умолчанию будет установлен снова. И процесс повторяется...
Чтобы этого не произошло, мы должны убедиться, что пакеты SLA отправляются только в направлении Gi1. Как мы можем это сделать? Что произойдет, если мы установим исходный интерфейс в конфигурации SLA?
Edge(config-ip-sla)#icmp-echo 8.8.8.8 ?
source-interface Source Interface (ingress icmp packet interface)
source-ip Source AddressК сожалению, результаты все те же. У нас все еще есть флапинг. При настройке SLA в нем говорится про интерфейс входа, а не выхода:
Edge(config-ip-sla)#icmp-echo 8.8.8.8 ?
source-interface Source Interface (ingress icmp packet interface)
source-ip Source AddressМы можем удостовериться, что пакеты используют GigabitEthernet2 в качестве next-hop:
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8
203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet2, addr 203.0.113.9К сожалению, мы не можем определить интерфейс выхода для пакетов SLA. Что же будем делать? У нас есть следующие варианты:
Создать статический маршрут для назначения пакетов SLA
Использовать маршрутизацию на основе правил для принудительного вывода SLA-пакетов через GigabitEthernet1.
Давайте сначала попробуем использовать метод статического маршрута. Добавлен статический маршрут для 8.8.8.8:
Edge(config)#ip route 8.8.8.8 255.255.255.255 203.0.113.1 name SLAТеперь пакеты на 8.8.8.8 должны идти только через 203.0.113.1, верно? Поначалу это выглядит многообещающе:
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8
203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8
203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8
203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8
203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1Пакеты отправляются только через GigabitEthernet1. Но не так быстро! В настоящее время для имитации сбоя используется фильтрация пакетов. Что произойдет, если Gi1 действительно выйдет из строя? Я отключу интерфейс, чтобы смоделировать сбой, когда интерфейс для ISP1 выйдет из строя. Я добавил несколько дебагов, чтобы показать, что происходит в фоновом режиме:
Aug 22 08:18:05.209: RT: interface GigabitEthernet1 removed from routing table
Aug 22 08:18:05.209: RT: del 203.0.113.0 via 0.0.0.0, connected metric [0/0]
Aug 22 08:18:05.209: RT: delete subnet route to 203.0.113.0/29
Aug 22 08:18:05.209: CONN: delete conn route, idb: GigabitEthernet1, addr: 203.0.113.2, mask: 255.255.255.248
Aug 22 08:18:05.210: CONN(multicast): connected_route: FALSE
Aug 22 08:18:05.210: RT: interface GigabitEthernet1 topo state DOWN, afi 0
Aug 22 08:18:05.210: IP-ST-EV(default): queued adjust on GigabitEthernet1
Aug 22 08:18:05.210: RT: del 203.0.113.2 via 0.0.0.0, connected metric [0/0]
Aug 22 08:18:05.210: RT: delete subnet route to 203.0.113.2/32
Aug 22 08:18:05.221: RT: del 8.8.8.8 via 203.0.113.1, static metric [1/0]
Aug 22 08:18:05.221: RT: delete subnet route to 8.8.8.8/32
Aug 22 08:18:06.108: %SYS-5-CONFIG_I: Configured from console by daniel on vty0 (10.254.255.2)
Aug 22 08:18:07.202: %LINK-5-CHANGED: Interface GigabitEthernet1, changed state to administratively down
Aug 22 08:18:07.208: CONN: connected_route: FALSE
Aug 22 08:18:07.208: is_up: GigabitEthernet1 0 state: 6 sub state: 1 line: 0
Aug 22 08:18:08.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1, changed state to down
Aug 22 08:18:08.204: CONN: connected_route: FALSE
Aug 22 08:18:08.204: is_up: GigabitEthernet1 0 state: 6 sub state: 1 line: 0Из приведенного выше дебага видно, что Gi1 выходит из строя, он удаляет подключенную подсеть 203.0.113.0/29, а также удаляется маршрут к 8.8.8.8. Это означает, что пакеты SLA теперь идут через Gi2:
Edge#show ip cef exact-route 8.8.8.8 203.0.113.2
8.8.8.8 -> 203.0.113.2 =>IP adj out of GigabitEthernet2, addr 203.0.113.9Маршрут по умолчанию через Gi1 не может быть установлен, так как интерфейс не работает, но если бы мы отслеживали статистику SLA, это исказило бы данные, так как эти пакеты проходят, несмотря на то, что ISP1 не работает.
Однако есть и более элегантное решение. Можно добавить постоянный статический маршрут с помощью ключевого слова permanent:
Edge(config)#ip route 8.8.8.8 255.255.255.255 203.0.113.1 permanent name SLAОбратите внимание на ключевое слово permanent в приведенном ниже выводе:
Edge#show ip route 8.8.8.8
Routing entry for 8.8.8.8/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 203.0.113.1, permanent
Route metric is 0, traffic share count is 1Когда интерфейс будет отключен, этот маршрут останется:
Edge(config)#int gi1
Edge(config-if)#sh
Edge(config-if)#^Z
Edge#show ip route 8.8.8.8
Routing entry for 8.8.8.8/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 203.0.113.1, permanent
Route metric is 0, traffic share count is 1Это гарантирует, что пакеты SLA могут использовать только Gi1. Все работает хорошо. Однако помните одну вещь. Настройка, которую мы только что выполнили, будет применяться ко ВСЕМ пакетам в направлении 8.8.8.8. Не только к пакетам SLA. Если люди используют 8.8.8.8 в качестве своего резолвера, а ISP1 не работает или имеет проблемы, пакеты на 8.8.8.8 НЕ смогут использовать ISP2. По сути, мы сделали наш вторичный канал недоступным для пакетов на 8.8.8.8. Это не очень хорошо. Что если бы мы могли изменить роутинг в направлении 8.8.8.8 только для пакетов, генерируемых самим маршрутизатором? Это возможно, но значит, что нам придется использовать нашего старого друга/врага - маршрутизацию на основе определенных правил (Policy-based Routing). Давайте настроим PBR:
ip access-list extended G1-ICMP-TO-GOOGLE-DNS
permit icmp host 203.0.113.2 host 8.8.8.8 echo
!
route-map LOCAL-POLICY permit 10
match ip address G1-ICMP-TO-GOOGLE-DNS
set ip next-hop 203.0.113.1
!
ip local policy route-map LOCAL-POLICYПрименяется политика:
Edge#show ip local policy
Local policy routing is enabled, using route map LOCAL-POLICY
route-map LOCAL-POLICY, permit, sequence 10
Match clauses:
ip address (access-lists): G1-ICMP-TO-GOOGLE-DNS
Set clauses:
ip next-hop 203.0.113.1
Policy routing matches: 2 packets, 128 bytes
Edge#show ip access-lists
Extended IP access list G1-ICMP-TO-GOOGLE-DNS
10 permit icmp host 203.0.113.2 host 8.8.8.8 echo (3 matches)Пакеты на 8.8.8.8 могут использовать вторичный путь:
Edge#show ip cef 8.8.8.8
0.0.0.0/0
nexthop 203.0.113.9 GigabitEthernet2Все выглядит отлично. Мы запинили пакеты SLA к Gi1, но пользовательский трафик на 8.8.8.8 все еще может использовать вторичный путь. До сих пор мы использовали только ICMP Echo, что не является лучшим способом определить, работоспособен ли путь. Давайте рассмотрим некоторые более продвинутые варианты.
IP SLA с использованием DNS
Что если вместо отправки пакетов ICMP Echo на серверы DNS просто отправим DNS-запросы? Разве это не было бы лучше? Действительно, так как задача DNS-сервера - отвечать на DNS-запросы, а не на пакеты ICMP Echo. Можно настроить IP SLA на отправку DNS-запросов. Определите имя для запроса и сервер имен в конфигурации IP SLA:
ip sla 1
dns google.com name-server 8.8.8.8
frequency 10
!
ip sla schedule 1 life forever start-time nowEdge#show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest RTT: 8 milliseconds
Latest operation start time: 13:08:24 SWE Mon Aug 22 2022
Latest operation return code: OK
Number of successes: 4
Number of failures: 0
Operation time to live: Forever
Edge#show ip sla
Edge#show ip route trac
Edge#show ip route track-table
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 1 state is [up]Теперь маршрут по умолчанию инсталлирован на основе того, что 8.8.8.8 отвечает на наш запрос имени google.com. Это намного лучше! Но задумайтесь вот о чем:
Что произойдет, если не будет ответа для google.com?
Что произойдет, если 8.8.8.8 вообще не ответит?
Какова длина пакета DNS-запроса?
Прежде чем ответить на первые два вопроса, объясните, почему нас должен волновать размер пакета? Что если DNS-запросы могут проходить, а другой пользовательский трафик - нет? Может быть, маршрут не пропускает пакеты размером 1500 байт из-за какой-то проблемы в апстриме... Во-первых, давайте проверим размер пакета SLA с помощью какой-нибудь магии по захвату пакетов:
Edge#debug platform condition ipv4 8.8.8.8/32 both
Edge#debug platform packet-trace packet 256
Please remember to turn on 'debug platform condition start' for packet-trace to work
Edge#debug platform condition start
Edge#show platform packet-trace sum
Pkt Input Output State Reason
0 INJ.2 Gi1 FWD
1 Gi1 internal0/0/rp:0 PUNT 11 (For-us data)
Edge#show platform packet-trace packet 0
Packet: 0 CBUG ID: 0
IOSd Path Flow:
Feature: UDP
Pkt Direction: OUTsrc=203.0.113.2(53883), dst=8.8.8.8(53), length=36
Feature: UDP
Pkt Direction: OUT
FORWARDED
UDP: Packet Handoff to IP
Source : 203.0.113.2(53883)
Destination : 8.8.8.8(53)
Feature: IP
Pkt Direction: OUTRoute out the generated packet.srcaddr: 203.0.113.2, dstaddr: 8.8.8.8
Summary
Input : INJ.2
Output : GigabitEthernet1
State : FWD
Timestamp
Start : 97239727399057 ns (08/22/2022 11:10:03.807558 UTC)
Stop : 97239727755013 ns (08/22/2022 11:10:03.807914 UTC)
Path Trace
Feature: IPV4(Input)
Input : internal0/0/rp:0
Output : <unknown>
Source : 203.0.113.2
Destination : 8.8.8.8
Protocol : 17 (UDP)
SrcPort : 53883
DstPort : 53Данный пакет совсем небольшой, всего 36 байт. Давайте вернемся к этому позже. Что касается нашей первой проблемы: как мы можем отслеживать еще что-то, кроме google.com, а также посылать запросы более чем одному DNS-серверу? Это можно реализовать с помощью нескольких утверждений IP SLA:
ip sla 1
dns google.com name-server 8.8.8.8
frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
dns amazon.com name-server 208.67.220.220
frequency 10
ip sla schedule 2 life forever start-time now
ip sla 3
dns microsoft.com name-server 1.1.1.1
frequency 10
ip sla schedule 3 life forever start-time now
!
track 2 ip sla 2 reachability
!
track 3 ip sla 3 reachabilityЗатем сконфигурируйте оператор отслеживания, который использует булеву логику для всех этих SLA-утверждений:
track 10 list boolean or
object 1
object 2
object 3Наконец, обновите маршрут по умолчанию, чтобы использовать новый трекер:
Edge(config)#no ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 1
Edge(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 10Давайте проверим:
Edge#show track 10
Track 10
List boolean or
Boolean OR is Up
2 changes, last change 00:02:25
object 1 Up
object 2 Up
object 3 Up
Tracked by:
Static IP Routing 0
Edge#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 1, metric 0, candidate default path
Routing Descriptor Blocks:
* 203.0.113.1
Route metric is 0, traffic share count is 1
Edge#show ip route track-table
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 10 state is [up]
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8
203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1Выглядит хорошо. Теперь у нас есть три SLA-утверждения, и сбой одного из них не переведет трафик на вторичный путь. Если отказало только одно из них, более вероятно, что возникла временная проблема с сервером DNS или зоной DNS.
Помните, я упоминал выше о размерах пакетов? Давайте обсудим это в следующем разделе.
IP SLA с использованием HTTP
Отслеживание соединения с помощью DNS определенно более эффективно, чем простой ICMP Echo. А что, если бы мы могли продвинуться еще дальше по стеку? Этого можно достичь с помощью HTTP-зондов. Вместо того чтобы просто проверять, получаем ли мы ответы на DNS-запросы, давайте попробуем действительно подключиться к веб-сайту. Синтаксис аналогичен синтаксису DNS:
ip sla 5
http secure get https://amazon.com name-server 8.8.8.8 source-interface GigabitEthernet1
!
ip sla schedule 5 life forever start-time now
!
track 5 ip sla 5 reachability
!
no ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 10
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 5 Затем проверим:
Edge#show ip sla statistics 5
IPSLAs Latest Operation Statistics
IPSLA operation id: 5
Latest RTT: 1175 milliseconds
Latest operation start time: 13:57:12 SWE Mon Aug 22 2022
Latest operation return code: OK
Latest DNS RTT: 7 ms
Latest HTTP Transaction RTT: 1168 ms
Number of successes: 2
Number of failures: 0
Operation time to live: Forever
Edge#show ip route track-table
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 5 state is [up]Теперь маршрутизатор отправляет HTTP GET для имени amazon.com, предварительно разрешая это имя (резолвинг) через DNS-запрос к 8.8.8.8.8. Это протестирует большую часть стека, чем DNS-запрос. Каков теперь размер наших пакетов SLA? Давайте проверим это с помощью другой утилиты для захвата пакетов:
ip access-list extended CAP-HTTP
10 permit tcp host 203.0.113.2 any
20 permit tcp any host 203.0.113.2
!
Edge#monitor capture CAP interface GigabitEthernet1 both
Edge#monitor capture CAP access-list CAP-HTTP
Edge#monitor capture CAP start
Started capture point : CAP
Edge#monitor capture CAP export flash:/CAP.pcap
Exported Successfully
Edge#copy flash:/CAP.pcap ftp://redacted:redacted@10.254.255.2Давайте посмотрим на PCAP:
Пакеты определенно больше, чем при использовании DNS. Мы видим, что их размер приближается к 600 байтам. Однако это не 1500 байт! Для продакшна мы, конечно, должны отслеживать более одного веб-сервера. Что еще мы можем сделать, когда речь идет об IP SLA? Пора включить воображение!
Включаем воображение, применяя IP SLA
Мы можем многое сделать с помощью IP SLA. Пора проявить фантазию! Давайте реализуем это:
Зарезолвить google.com через 8.8.8.8.8
Зарезолвить amazon.com через 208.67.220.220
HTTP GET к amazon.com
Запиним sdwan.measure.office.com (служба маяков O365) с помощью ICMP Echo размером 1500 байт.
Если все прошло успешно, схема функционирует, и мы можем отправлять ICMP, резолвить DNS и просматривать веб-сайты. Вот конфигурация:
track 1 ip sla 1 reachability
!
track 2 ip sla 2 reachability
!
track 5 ip sla 5 reachability
!
track 20 ip sla 20 reachability
!
track 100 list boolean and
object 1
object 2
object 5
object 20
!
ip sla 1
dns google.com name-server 8.8.8.8
frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
dns amazon.com name-server 208.67.220.220
frequency 10
ip sla schedule 2 life forever start-time now
ip sla 5
http secure get https://amazon.com name-server 8.8.8.8 source-interface GigabitEthernet1
ip sla schedule 5 life forever start-time now
ip sla 20
icmp-echo sdwan.measure.office.com source-interface GigabitEthernet1
request-data-size 1450
frequency 10
ip sla schedule 20 life forever start-time nowОбратите внимание, что размер данных запроса установлен на 1450, что приведет к генерации 1500 байтовых пакетов ICMP Echo. Я не уверен в правильности математических вычислений, но удостоверился в этом с помощью захвата пакетов. ICMP Echo SLA при использовании DNS-имени зарезолвится в IP при настройке и будет помещен в работающую конфигурацию. Давайте посмотрим, работает ли все это:
Edge#show track 100
Track 100
List boolean and
Boolean AND is Up
2 changes, last change 00:00:03
object 1 Up
object 2 Up
object 5 Up
object 20 Up
Tracked by:
Static IP Routing 0
Edge#show ip route track-table
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 100 state is [up]
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8
203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1Очень круто! Используя только статические маршруты и IP SLA, мы теперь имеем неплохой механизм для проверки соединения. Намного лучше, чем простые ICMP Echos, с которых мы начинали.
Заключение
Вы можете сделать его таким простым или сложным, как захотите, используя IP SLA. Все зависит от ваших требований. Имейте в виду следующее:
Подумайте, что вы хотите измерить.
Как вы убедитесь, что пакеты SLA направляются к нужному провайдеру?
Что вы хотите измерить, чтобы убедиться, что путь верен?
Я надеюсь, что эта статья была информативной, и вы узнали несколько новых приемов для IP SLA, а также несколько хороших команд дебаггинга и захвата пакетов.
Приглашаем на открытое занятие «Внедрение Firewall в фабрику». На этом занятии:
— Определим, зачем необходим Firewall и как он мешает работе сервиса.
— Рассмотрим дизайн построения сетевой фабрики.
— Разберем особенности и недостатки внедрения Firewall.
— Реализуем внедрение Firewall в сетевую фабрику.
Регистрация доступна по ссылке для всех желющих.
