Как настроить атрибут метрики AIGP в BGP

Рубрики:

Метки:

AS, BGP, blog, Cisco, Cisco CLI, Cisco IOS, Cisco IOS CLI, eBGP, iBGP, IP, IPV4, IPv6, OSPF, Routing, карьера, команды, сетевые технологии

Команды LINUX «от A до Z» — настольная книга с примерами

Функция BGP Accumulated Interior Gateway Protocol (AIGP) — это необязательный нетранзитивный атрибут BGP, который позволяет учитывать метрику IGP (например, OSPF, IS-IS, EIGRP) при выборе маршрута в BGP.
По умолчанию BGP не использует метрики IGP, поэтому не может выбирать маршрут на основе «коротчайшего пути» внутри автономной системы (AS). AIGP решает эту проблему.

Содержание:

Введение
Топология
BGP по умолчанию
1. От AS 1 к AS 2
2. От AS 2 к AS 1
BGP MED
AIGP
1. От AS 1 к AS 2
2. От AS 2 к AS 1
Изменения алгоритма выбора пути BGP
Выводы

Введение

В крупных сетях можно встретить архитектуры, в которых сеть находится под единственным административным управлением. В таких архитектурах сеть может быть разделена на несколько автономных систем (AS), каждый из которых использует собственный IGP:

Существуют несколько причин почему сети спроектированы таким образом:

Ограничения масштабируемости IGP в больших инфраструктурах;
Приобретение одной компанией другой, при этом их сети временно остаются в разных AS;
Необходимость реализации политики маршрутизации, невозможной средствами IGP;
Использование BGP-конфедераций;
Внедрение бесшовного MPLS (seamless MPLS);
Структура компании с независимыми филиалами, которые имеют собственные сети.

Использование сети, в которой между несколькими IGP-областями применяется BGP, вместо единого IGP, может привести к потенциальной проблеме — алгоритм выбора маршрута в BGP не основывается на наименьшей метрике, как это принято в IGP, а значит — маршрутизаторы могут выбирать неоптимальные пути внутри сети:

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

Решением этой проблемы является использование атрибута BGP Accumulated IGP Metric Attribute (AIGP). Атрибут AIGP описан в RFC 7311. Он позволяет маршрутизаторам BGP выбирать лучший путь на основе сквозной метрики IGP:

Курсы Git за час: руководство для начинающих DevOps / DevNet инженеров

Чтобы сделать это возможным, AIGP вносит некоторые изменения в алгоритм определения наилучшего пути BGP.

После активации AIGP, BGP будет проверять метрику AIGP сразу после шага №3 (originate). Это означает, что метрика AIGP будет использована для разрешения конфликтов перед другими важными атрибутами, такими как длина пути AS или MED. Больше о процессе выбора наилучшего маршрута в BGP можно узнать в этой статье.

Примечание: при использовании AIGP необходимо также использовать тот же IGP. Каждый IGP имеет свою метрику, поэтому при использовании разных IGP, метрика AIGP не будет иметь смысла.

при использовании AIGP важно, чтобы во всей сети применялся один и тот же протокол IGP, поскольку каждый IGP использует собственную метрик. Использование разных IGP в сегментах сети делает AIGP неэффективным, так как метрики этих протоколов не поддаются корректному сравнению.

В этой статье сначала рассмотрим сеть, которая не использует AIGP и выбирает неоптимальный путь. Также можно заметить, что другие решения, такие как настройка MED, не решат эту проблему. Этот пример поможет понять, зачем нужен AIGP. Далее настроим AIGP, который решит проблему неоптимальной маршрутизации.

Топология

Исследуемая топология состоит из шести маршрутизаторов (Cisco 1941 с образом Cisco IOS Release 15.4 IP Base). Допускается использование маршрутизаторов других моделей, а также других версий операционной системы Cisco IOS. В зависимости от модели устройства и версии Cisco IOS, доступные команды и результаты их выполнения могут отличаться от тех, которые показаны в этой статье.

Схема топологии следующая:

Настройки маршрутизатора R1

hostname R1
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0
exit

interface GigabitEthernet0/0
ip address 192.168.10.1 255.255.255.0
ip ospf cost 10
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.30.1 255.255.255.0
ip ospf cost 30
no shutdown
exit

interface Loopback0
ip address 1.1.1.1 255.255.255.0
ip ospf cost 10
no shutdown
exit

router ospf 1
network 1.1.1.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
network 192.168.30.0 0.0.0.255 area 0
exit

router bgp 1
network 1.1.1.0 mask 255.255.255.0
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 1
neighbor 3.3.3.3 update-source Loopback0
end

Настройки маршрутизатора R2

hostname R2
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0
exit

interface GigabitEthernet0/0
ip address 192.168.10.2 255.255.255.0
ip ospf cost 10
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.20.2 255.255.255.0
no shutdown
exit

interface Loopback0
ip address 2.2.2.2 255.255.255.0
ip ospf cost 10
no shutdown
exit

router ospf 1
network 2.2.2.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
exit

router bgp 1
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 next-hop-self
neighbor 3.3.3.3 remote-as 1
neighbor 3.3.3.3 update-source Loopback0
neighbor 3.3.3.3 next-hop-self
neighbor 192.168.20.4 remote-as 2
end

Настройки маршрутизатора R3

hostname R3
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0
exit

interface GigabitEthernet0/0
ip address 192.168.30.3 255.255.255.0
ip ospf cost 30
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.50.3 255.255.255.0
no shutdown
exit

interface Loopback0
ip address 3.3.3.3 255.255.255.0
ip ospf cost 10
no shutdown
exit

router ospf 1
network 3.3.3.0 0.0.0.255 area 0
network 192.168.30.0 0.0.0.255 area 0
exit

router bgp 1
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 next-hop-self
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0
neighbor 2.2.2.2 next-hop-self
neighbor 192.168.50.5 remote-as 2
end

Настройки маршрутизатора R4

hostname R4
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0
exit

interface GigabitEthernet0/0
ip address 192.168.20.4 255.255.255.0
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.40.4 255.255.255.0
ip ospf cost 20
no shutdown
exit

interface Loopback0
ip address 4.4.4.4 255.255.255.0
ip ospf cost 10
no shutdown
exit

router ospf 1
network 4.4.4.0 0.0.0.255 area 0
network 192.168.40.0 0.0.0.255 area 0
exit

router bgp 2
neighbor 5.5.5.5 remote-as 2
neighbor 5.5.5.5 update-source Loopback0
neighbor 5.5.5.5 next-hop-self
neighbor 6.6.6.6 remote-as 2
neighbor 6.6.6.6 update-source Loopback0
neighbor 6.6.6.6 next-hop-self
neighbor 192.168.20.2 remote-as 1
end

Настройки маршрутизатора R5

hostname R5
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0
exit

interface GigabitEthernet0/0
ip address 192.168.50.5 255.255.255.0
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.60.5 255.255.255.0
ip ospf cost 10
no shutdown
exit

interface Loopback0
ip address 5.5.5.5 255.255.255.0
ip ospf cost 10
no shutdown
exit

router ospf 1
network 5.5.5.0 0.0.0.255 area 0
network 192.168.60.0 0.0.0.255 area 0
exit

router bgp 2
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 update-source Loopback0
neighbor 4.4.4.4 next-hop-self
neighbor 6.6.6.6 remote-as 2
neighbor 6.6.6.6 update-source Loopback0
neighbor 6.6.6.6 next-hop-self
neighbor 192.168.50.3 remote-as 1
end

Настройки маршрутизатора R6

hostname R6
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0
exit

interface GigabitEthernet0/0
ip address 192.168.40.6 255.255.255.0
ip ospf cost 20
no shutdown
exit

interface GigabitEthernet0/1
ip address 192.168.60.6 255.255.255.0
ip ospf cost 10
no shutdown
exit

interface Loopback0
ip address 6.6.6.6 255.255.255.0
ip ospf cost 10
no shutdown
exit

router ospf 1
network 6.6.6.0 0.0.0.255 area 0
network 192.168.40.0 0.0.0.255 area 0
network 192.168.60.0 0.0.0.255 area 0
exit

router bgp 2
network 6.6.6.0 mask 255.255.255.0
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 update-source Loopback0
neighbor 5.5.5.5 remote-as 2
neighbor 5.5.5.5 update-source Loopback0
end

BGP по умолчанию

Начнем со сценария BGP по умолчанию, в котором отсутствуют карты маршрутов для направления трафика в другом направлении.

От AS 1 к AS 2

Посмотрим, как R1 может достичь 6.6.6.6:

show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.0/24, version 3
Paths: (2 available, best #2, table default)
Flag: 0x100
Not advertised to any peer
Refresh Epoch 1
2
3.3.3.3 (metric 40) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
2
2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

R1 использует R2 в качестве следующего перехода, поскольку у него самая низкая метрика IGP по сравнению со следующим переходом BGP. Трафик поступает в AS 2 через R4. Проверим метрику IGP на 6.6.6.6 на R4 и R5:

Маршрутизатор R4:

show ip route 6.6.6.6 | include metric
Known via "ospf 1", distance 110, metric 30, type intra area
Route metric is 30, traffic share count is 1

Маршрутизатор R5:

show ip route 6.6.6.6 | include metric
Known via "ospf 1", distance 110, metric 20, type intra area
Route metric is 20, traffic share count is 1

С точки зрения AS 2, у R5 самая низкая метрика IGP для достижения 6.6.6.6. Однако, если смотреть на общую картину показателей, лучшим вариантом является использование R4:

Путь через R2 = 10 + 20 + 10 = 40
Путь через R3 = 30 + 10 + 10 = 50

Итак, трафик от R1 до R6 идет по наилучшему пути.

От AS 2 к AS 1

Давайте рассмотрим путь от R6 до R1. Проверим таблицу BGP на R6:

show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.0/24, version 2
Paths: (2 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
1
5.5.5.5 (metric 20) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
1
4.4.4.4 (metric 30) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0

R6 выбирает R5, потому что у него самая низкая метрика IGP для следующего перехода. Давайте проверим это с точки зрения AS 1:

Маршрутизатор R2:

show ip route 1.1.1.1 | include metric
Known via "ospf 1", distance 110, metric 20, type intra area
Route metric is 20, traffic share count is 1

Маршрутизатор R3:

show ip route 1.1.1.1 | include metric
Known via "ospf 1", distance 110, metric 40, type intra area
Route metric is 40, traffic share count is 1

Когда трафик заходит в AS 1 через R3, приходится использовать «медленный» канал с более высокой метрикой. Общая метрика путей выглядит так:

Путь через R4 = 20 + 10 + 10 = 40
Путь через R5 = 10 + 30 + 10 = 50

Путь через R4 был бы лучшим вариантом, но AS 2 не может этого знать, поскольку не знает об AS 1.

BGP MED

Рассмотрим следующий пример с использованием MED.

Настройка MED

Для начала настроим карты маршрутов так, чтобы R2, R3, R4 и R5 устанавливали MED на основе своей метрики IGP для достижения интерфейса loopback в своей AS:

AS 1

Маршрутизатор R2:

ip access-list standard R1_L0
permit host 1.1.1.0
exit

route-map R1_METRIC
match ip address R1_L0
set metric 20
exit

router bgp 1
neighbor 192.168.20.4 route-map R1_METRIC out
exit

Маршрутизатор R3:

ip access-list standard R1_L0
permit host 1.1.1.0
exit

route-map R1_METRIC
match ip address R1_L0
set metric 40
exit

router bgp 1
neighbor 192.168.50.5 route-map R1_METRIC out
exit

AS 2

Маршрутизатор R4:

ip access-list standard R6_L0
permit host 6.6.6.0
exit

route-map R6_METRIC
match ip address R6_L0
set metric 30

router bgp 2
neighbor 192.168.20.2 route-map R6_METRIC out
exit

Маршрутизатор R5:

ip access-list standard R6_L0
permit host 6.6.6.0
exit

route-map R6_METRIC
match ip address R6_L0
set metric 20
exit

router bgp 2
neighbor 192.168.50.3 route-map R6_METRIC out
exit

Это все, что нужно настроить для MED.

От AS 1 к AS 2

Снова проверим, как трафик от R1 доходит до R6:

show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.0/24, version 6
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
2
3.3.3.3 (metric 40) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 20, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

У R1 есть только один путь потому, что R2 предпочитает путь через R3 своему собственному пути eBGP:

Маршрутизатор R2:

show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.0/24, version 6
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 2
2
192.168.20.4 from 192.168.20.4 (4.4.4.4)
Origin IGP, metric 30, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
2
3.3.3.3 (metric 50) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 20, localpref 100, valid, <strong>internal, best</strong>
rx pathid: 0, tx pathid: 0x0

Маршрутизатор R3:

show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.0/24, version 6
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 2
2
192.168.50.5 from 192.168.50.5 (5.5.5.5)
Origin IGP, metric 20, localpref 100, valid, <strong>external, best</strong>
rx pathid: 0, tx pathid: 0x0

BGP предпочитает путь с наименьшим MED.

Это не хорошо. AS 1 теперь использует R3 для достижения AS 2, но это путь не с самой низкой общей метрикой.

От AS 2 к AS 1

Давайте проверим наоборот трафик от R6 до R1:

show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.0/24, version 5
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
1
4.4.4.4 (metric 30) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 20, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

R6 видит только R4 как возможный путь. Это связано с тем, что R5 предпочитает использовать R4 по своему пути eBGP:

Маршрутизатор R5:

show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.0/24, version 5
Paths: (2 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
1
4.4.4.4 (metric 40) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 20, localpref 100, valid, <strong>internal, best</strong>
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
1
192.168.50.3 from 192.168.50.3 (3.3.3.3)
Origin IGP, metric 40, localpref 100, valid, external
rx pathid: 0, tx pathid: 0

Маршрутизатор R4:

show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.0/24, version 5
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
1
192.168.20.2 from 192.168.20.2 (2.2.2.2)
Origin IGP, metric 20, localpref 100, valid, <strong>external, best</strong>
rx pathid: 0, tx pathid: 0x0

AS 2 теперь использует наиболее оптимальный путь. Однако AS 1 — нет.

AIGP

Давайте удостоверимся, что и AS 1, и AS 2 будут использовать наиболее оптимальный путь. Снова начнем с исходной конфигурации BGP, которая была вначале, без конфигурации MED. Активируем AIGP на всех маршрутизаторах для всех соседей:

Маршрутизатор R1:

router bgp 1
neighbor 2.2.2.2 aigp
neighbor 3.3.3.3 aigp
exit

Маршрутизатор R2:

router bgp 1
neighbor 1.1.1.1 aigp
neighbor 3.3.3.3 aigp
neighbor 192.168.20.4 aigp
exit

Маршрутизатор R3:

router bgp 1
neighbor 1.1.1.1 aigp
neighbor 2.2.2.2 aigp
neighbor 192.168.50.5 aigp
exit

Маршрутизатор R4:

router bgp 2
neighbor 5.5.5.5 aigp
neighbor 6.6.6.6 aigp
neighbor 192.168.20.2 aigp
exit

Маршрутизатор R5:

router bgp 2
neighbor 4.4.4.4 aigp
neighbor 6.6.6.6 aigp
neighbor 192.168.50.3 aigp
exit

Маршрутизатор R6:

router bgp 2
neighbor 4.4.4.4 aigp
neighbor 5.5.5.5 aigp
exit

Активации AIGP недостаточно. Необходимо указать для каких маршрутов необходимо установить атрибут AIGP. Настроим R1 и R6 так, чтобы метрика AIGP соответствовала метрике IGP их loopback интерфейсов.

Повторно используем списки доступа R1_L0 и R6_L0 для R1 и R6 сооответственно. R1 и R6 будут объявлять метрику AIGP своим соседям iBGP:

Маршрутизатор R1:

ip access-list standard R1_L0
permit host 1.1.1.0
exit

route-map AIGP permit 10
match ip address R1_L0
set aigp-metric igp-metric
exit

router bgp 1
neighbor 2.2.2.2 route-map AIGP out
neighbor 3.3.3.3 route-map AIGP out
end

Маршрутизатор R6:

ip access-list standard R6_L0
permit host 6.6.6.0
exit

route-map AIGP permit 10
match ip address R6_L0
set aigp-metric igp-metric
exit

router bgp 2
neighbor 4.4.4.4 route-map AIGP out
neighbor 5.5.5.5 route-map AIGP out
end

А на маршрутизаторах R2, R3, R4 и R5 пропишем универсальный route-map, который не зависит от ACL, чтобы передавалась метрика AIGP:

route-map AIGP permit 10
set aigp-metric igp-metric
end

Убедимся, что AIGP активирован на R1:

show bgp ipv4 unicast neighbors 2.2.2.2 | include AIGP
AIGP is enabled
Route map for outgoing advertisements is AIGP

Это также следует проверить на всех маршрутизаторах.

От AS 1 к AS 2

Посмотрим как выглядит трафик. Начнем с R1:

show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.0/24, version 7
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
2
3.3.3.3 (metric 40) from 3.3.3.3 (3.3.3.3)
Origin IGP, aigp-metric 20, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
2
2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)
Origin IGP, aigp-metric 30, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

Обратите внимание, как R1 использует 2.2.2.2 и имеет метрику AIGP. Это метрика IGP, которую R4 и R5 объявляют AS 1:

Маршрутизатор R4:

show ip route 6.6.6.6 | include metric
Known via "ospf 1", distance 110, metric 30, type intra area
Route metric is 30, traffic share count is 1

Маршрутизатор R5:

show ip route 6.6.6.6 | include metric
Known via "ospf 1", distance 110, metric 20, type intra area
Route metric is 20, traffic share count is 1

Прекрасно. Однако маршрутизатор R1 уже выбрал лучший путь в сценарии BGP «по умолчанию».

От AS 2 к AS 1

Что насчет R6? Трафик от AS 2 к AS 1 выбрал неправильный путь в сценарии BGP «по умолчанию». Давайте посмотрим:

show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.0/24, version 7
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
1
5.5.5.5 (metric 20) from 5.5.5.5 (5.5.5.5)
Origin IGP, aigp-metric 40, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
1
4.4.4.4 (metric 30) from 4.4.4.4 (4.4.4.4)
Origin IGP, aigp-metric 20, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

R6 теперь использует R4 для входа в AS 1. Метрики AIGP, приведенные выше, — это метрики IGP, полученные от AS 1:

Маршрутизатор R2:

show ip route 1.1.1.1 | include Route metric
Route metric is 20, traffic share count is 1

Маршрутизатор R3:

show ip route 1.1.1.1 | include Route metric
Route metric is 40, traffic share count is 1

Благодаря AIGP обе AS теперь выбирают лучший сквозной путь.

Изменения алгоритма выбора пути BGP

Ранее было указано, что AIGP меняет алгоритм определения наилучшего пути BGP. Давайте это проверим.

Четвертый шаг в выборе пути BGP заключается в том, что BGP отдает предпочтение пути с кратчайшим путем AS. После активации AIGP BGP сначала отдает предпочтение самой низкой метрике AIGP.

Настроим R4 так, чтобы он добавлял путь AS несколько раз:

route-map AS_PATH_PREPEND permit 10
set as-path prepend 2 2 2
exit

router bgp 2
neighbor 192.168.20.2 route-map AS_PATH_PREPEND out
end

Проверим R1:

show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.0/24, version 8
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
2
3.3.3.3 (metric 40) from 3.3.3.3 (3.3.3.3)
Origin IGP, aigp-metric 20, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
2 2 2 2
2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)
Origin IGP, aigp-metric 30, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0

Обратите внимание, что R1 по-прежнему предпочитает путь через R2, хотя путь AS длиннее, чем через R3. Это доказывает, что BGP проверяет метрику AIGP, прежде чем проверять длину пути AS.

Выводы

Спасибо за уделенное время на прочтение статьи. Теперь Вы знаете как настроить атрибут метрики AIGP на маршрутизаторах Cisco.

Если возникли вопросы, задавайте их в комментариях.

Подписывайтесь на обновления нашего блога и оставайтесь в курсе новостей мира инфокоммуникаций!

Чтобы знать больше и выделяться знаниями среди толпы IT-шников, записывайтесь на курсы Cisco, курсы по кибербезопасности, полный курс по кибербезопасности, курсы DevNet / DevOps (программируемые системы) от Академии Cisco, курсы Linux от Linux Professional Institute на платформе SEDICOMM University (Университет СЭДИКОММ).

Курсы Cisco, Linux, кибербезопасность, DevOps / DevNet, Python с трудоустройством!

Спешите подать заявку! Группы стартуют 25 января, 26 февраля, 22 марта, 26 апреля, 24 мая, 21 июня, 26 июля, 23 августа, 20 сентября, 25 октября, 22 ноября, 20 декабря.

Что Вы получите?

Поможем стать экспертом по сетевой инженерии, кибербезопасности, программируемым сетям и системам и получить международные сертификаты Cisco, Linux LPI, Python Institute.
Предлагаем проверенную программу с лучшими учебниками от экспертов из Cisco Networking Academy, Linux Professional Institute и Python Institute, помощь сертифицированных инструкторов и личного куратора.
Поможем с трудоустройством и стартом карьеры в сфере IT — 100% наших выпускников трудоустраиваются.

Как проходит обучение?

Проведем вечерние онлайн-лекции на нашей платформе.
Согласуем с вами удобное время для практик.
Если хотите индивидуальный график — обсудим и реализуем.
Личный куратор будет на связи, чтобы ответить на вопросы, проконсультировать и мотивировать придерживаться сроков сдачи экзаменов.
Всем, кто боится потерять мотивацию и не закончить обучение, предложим общение с профессиональным коучем.

А еще поможем Вам:

отредактировать или создать с нуля резюме;
подготовиться к техническим интервью;
подготовиться к конкурсу на понравившуюся вакансию;
устроиться на работу в Cisco по специальной программе. Наши студенты, которые уже работают там: жмите на #НашиВCisco Вконтакте, #НашиВCisco Facebook.

Чтобы учиться на курсах Cisco, Linux LPI, кибербезопасность, DevOps / DevNet, Python, подайте заявку или получите бесплатную консультацию.