Применение AIGP Metric Attribute

Блог

пт, 03/03/2017 - 04:40
Мар 3rd, 2017
User Badges:

Довольно часто возникает ситуация, когда две или более разных автономных систем (AS) находятся под одним административным управлением. Очевидно, что для маршрутизации между AS используется BGP, тогда как для маршрутизации внутри AS – IGP, чаще всего это OSPF, либо IS-IS. Соответственно, BGP ничего «не знает» об устройстве другой AS, что может привести к неоптимальной маршрутизации.

Для решения данной проблемы был создан новый атрибут BGP – AIGP (Accumulated IGP Metric Attribute). 

Рассмотрим применение данного атрибута на практике в лабораторной сети.

Предварительно приведу краткий обзор данного атрибута


  • Опциональный (необязательный), не транзитивный (настраивается и работает только между двумя соседями)
  • Позволяет BGP принимать решение о построении кратчайшего маршрута на основании метрик IGP между двумя роутерами в разных AS

  • Основная причина появления атрибута – устранение существующих проблем с масштабированием IGP

  • Основное предназначение атрибута - передавать nexthop префиксы/метки через разные AS находящиеся под одним административным управлением

  • Удаленный PE маршрутизатор принимает решение о выборе оптимального маршрута, используя модифицированный, с учетом AIGP, процесс выбора наилучшего маршрута

  • Отправка/получение атрибута
    • конфигурируется для определенного соседа
    • по умолчанию включен для iBGP
    • по умолчанию выключен для eBGP
    • AIGP атрибут, принимаемый BGP соседом, на котором AIGP не настроен, игнорируется.

  • Способы формирования метрики AIGP
    • путем явной конфигурации
    • редистрибьюция из IGP
    • с помощью политик маршрутизации
    • изменение AIGP запускает перерасчет AIGP для маршрута
    • AIGP передаваемый между несколькими разными IGP доменами может принимать бессмысленные значения. Например, если попытаться использовать AIGP между RIP и EIGRP доменами, используя редистрибьюцию IGP метрики в AIGP, то польза от такого мероприятия будет сомнительна. Делать так не рекомендуется.

  • Модифицированная процедура выбора наилучшего маршрута
    • изменение в способе принятия решения
    • выбор происходит после сравнения local preference
    • Если у префикса присутствует атрибут AIGP
      1. Маршруты без атрибута AIGP удаляются из рассмотрения
      2. Маршруты сравниваются по кумулятивной AIGP метрике

  • Генерация обновлений
    • для соседей с настроенной передачей AIGP и не настроенной передачей AIGP формируются разные update-groups
    • обновление BGP генерируется в случае изменения значения AIGP

  • Существуют следующие возможности передачи AIGP атрибута BGP соседу, который не «понимает» AIGP
    • конвертация AIGP в атрибут cost-community
    • поддерживаются 2 POI (points-of-insertion) перед атрибутом pre-best-path и перед igp-cost. Это дает возможность использовать атрибут cost-community самым первым для вычисления лучшего маршрута до запуска основной процедуры, либо анализировать cost-community прежде igp-cost при выборе маршрута.
    • настройка атрибута cost-community транзитивным, то есть обеспечение возможности его передачи далее  по сети, другим BGP пирам, но только соседу.
    • редистрибьюция BGP (с атрибутом AIGP) в IGP
    • конвертация значения AIGP в BGP метрику (MED)
  •  Рекомендуется использовать опции BGP best-external и additional-path совместно с AIGP для обеспечения оптимальной маршрутизации

Следует отметить, что AIGP не является параметром BGP, согласуемым во время установления сессии, это дополнительный атрибут.

Давайте посмотрим, как это выглядит в дампе Wireshark.

В списке параметров BGP протокола AIGP отсутствует. ( см. рис.1 )



Рис.1

Но присутствует в списке атрибутов.  ( см. рис.2 )


Рис.2

 

Рассмотрим применение AIGP на примере следующей сети.  ( см. рис.3 )


Рис. 3


Приведу конфигурацию маршрутизаторов в нашей сети, попутно комментируя некоторые особенности конфигурации.

R1

router bgp 23

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor IBGP peer-group

 neighbor IBGP remote-as 23

 neighbor IBGP update-source Loopback0

 neighbor 2.2.2.2 peer-group IBGP

 neighbor 3.3.3.3 peer-group IBGP

 !

 address-family ipv4

  neighbor IBGP aigp

# Опция aigp включает передачу атрибута AIGP между соседями.

  neighbor IBGP soft-reconfiguration inbound

  neighbor 2.2.2.2 activate

  neighbor 3.3.3.3 activate

 exit-address-family

!

 

R2

 router bgp 23

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor 1.1.1.1 remote-as 23

 neighbor 1.1.1.1 update-source Loopback0

 neighbor 10.2.12.12 remote-as 1213

 !

 address-family ipv4

  network 100.1.1.1 mask 255.255.255.255 route-map AIGP_METRIC

# маршрут анонсируется с использованием route-map, назначается метрика

# AIGP

  neighbor 1.1.1.1 activate

  neighbor 1.1.1.1 aigp

  neighbor 1.1.1.1 next-hop-self

  neighbor 1.1.1.1 soft-reconfiguration inbound

  neighbor 10.2.12.12 activate

  neighbor 10.2.12.12 aigp

 exit-address-family

route-map AIGP_METRIC permit 10

 set aigp-metric igp-metric

# метрика AIGP копируется из IGP

 

R3

router bgp 23

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor 1.1.1.1 remote-as 23

 neighbor 1.1.1.1 update-source Loopback0

 neighbor 10.3.13.13 remote-as 1213

 !

 address-family ipv4

  network 100.1.1.1 mask 255.255.255.255 route-map AIGP_METRIC

  neighbor 1.1.1.1 activate

  neighbor 1.1.1.1 aigp

  neighbor 1.1.1.1 next-hop-self

  neighbor 1.1.1.1 soft-reconfiguration inbound

  neighbor 10.3.13.13 activate

  neighbor 10.3.13.13 aigp

 exit-address-family

 

route-map AIGP_METRIC permit 10

 set aigp-metric igp-metric

 

 

XR12

router bgp 1213

 address-family ipv4 unicast

  network 100.4.4.4/32 route-policy SET_AIGP

# маршрут анонсируется с использованием route-map, назначается метрика

# AIGP

 !

 neighbor 4.4.4.4

  remote-as 1213

  update-source Loopback0

  address-family ipv4 unicast

   aigp

# Опция aigp включает передачу атрибута AIGP между соседями.

 

   next-hop-self

   soft-reconfiguration inbound

  !

 neighbor 10.2.12.2

  remote-as 23

  address-family ipv4 unicast

   aigp

   route-policy ALLOW(Lo100_R1) in

# Используется RPL для того чтобы принимать только анонс префикса

# 100.1.1.1

   route-policy RPL_PASS out

prefix-set Lo100_R1

  100.1.1.1/32

end-set

!

route-policy ALLOW($PREFIX)

  if destination in $PREFIX then

    pass

  endif

end-policy

!

# Создание политики с помощью механизма параметризации позволяет

# динамически передавать в политику конкретные значения

 

route-policy RPL_PASS

  pass

end-policy

!

route-policy SET_AIGP

  set aigp-metric igp-cost

end-policy

!

 

 

XR13

router bgp 1213

 bgp unsafe-ebgp-policy

# Как известно, IOX-XR не устанавливает отношения соседства еBGP, если

# отсутствуют политики, привязанные к соседу.

# Использование команды bgp unsafe-ebgp-policy позволяет обойти это

# ограничение и настроить соседа eBGP без использования политик.

# Крайне НЕ РЕКОМЕНДУЕТСЯ использовать где-либо кроме лабораторной

# сети!

 

 address-family ipv4 unicast

  network 100.4.4.4/32 route-policy SET_AIGP

 !

 neighbor 4.4.4.4

  remote-as 1213

  update-source Loopback0

  address-family ipv4 unicast

   aigp

   next-hop-self

  !

 !

 neighbor 10.3.13.3

  remote-as 23

  address-family ipv4 unicast

   aigp

  !

route-policy SET_AIGP

  set aigp-metric igp-cost

end-policy

!

 

 

R4

router bgp 1213

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor IBGP peer-group

 neighbor IBGP remote-as 1213

 neighbor IBGP update-source Loopback0

 neighbor 12.12.12.12 peer-group IBGP

 neighbor 13.13.13.13 peer-group IBGP

 !

 address-family ipv4

  neighbor IBGP aigp

  neighbor 12.12.12.12 activate

  neighbor 13.13.13.13 activate

 exit-address-family

 

 

 

 

 

Посмотрим, как видят маршруты до друг друга R1 и R4.

 

 

 

R1#show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 32

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 1

  1213, (received & used)

    3.3.3.3 (metric 11) from 3.3.3.3 (3.3.3.3)

      Origin IGP, aigp-metric 20, metric 20, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 3

  1213, (received & used)

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, aigp-metric 10, metric 10, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

На R1 меньше стоимость и более предпочтительный маршрут до 100.4.4.4 через R3, что также подтверждается выводом traceroute.

 

 

 

R1#tra 100.4.4.4 so lo100

Type escape sequence to abort.

Tracing the route to 100.4.4.4

VRF info: (vrf in name/id, vrf out name/id)

  1 10.1.3.3 7 msec 11 msec 12 msec

  2 10.3.13.13 9 msec 9 msec 8 msec

  3 10.4.13.4 17 msec *  12 msec

 

 

R4#show bgp ipv4 unicast 100.1.1.1/32

BGP routing table entry for 100.1.1.1/32, version 38

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 1

  23

    13.13.13.13 (metric 20) from 13.13.13.13 (13.13.13.13)

      Origin IGP, aigp-metric 11, metric 11, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 1

  23

    12.12.12.12 (metric 10) from 12.12.12.12 (12.12.12.12)

      Origin IGP, aigp-metric 31, metric 31, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

На R4 маршрут до R1 лучше через R13, так как стоимость меньше.

 

 

 

R4#traceroute 100.1.1.1 source loopback 100

Type escape sequence to abort.

Tracing the route to 100.1.1.1

VRF info: (vrf in name/id, vrf out name/id)

  1 10.4.13.13 9 msec 6 msec 4 msec

  2 10.3.13.3 12 msec 13 msec 7 msec

  3 10.1.3.1 8 msec *  17 msec

 

 

 

Попробуем изменить стоимость IGP на линке между R1 и R3, чтобы трафик с R4 шел через R12. Настроим OSPF cost 50. Предварительно включим debug на R4, и проанализируем, какие обновления придут на роутер.

 

 

 

R4#deb ip bgp ipv4 unicast updates

 

 

 

Как и ожидалось, пришел апдейт, в котором содержится новое значение AIGP метрики.

 

 

 

R4#

*Mar  2 14:18:39.057: BGP(0): 13.13.13.13 rcvd UPDATE w/ attr: nexthop 13.13.13.13, origin i, localpref 100, metric 51, aigp-metric 51, merged path 23, AS_PATH

*Mar  2 14:18:39.057: BGP(0): 13.13.13.13 rcvd 100.1.1.1/32

*Mar  2 14:18:39.058: BGP(0): Revise route installing 1 of 1 routes for 100.1.1.1/32 -> 12.12.12.12(global) to main IP table

R4#

 

 

 

Также поменялся лучший маршрут до R1.

 

 

 

R4#show bgp ipv4 unicast 100.1.1.1/32

BGP routing table entry for 100.1.1.1/32, version 39

Paths: (2 available, best #2, table default)

  Not advertised to any peer

  Refresh Epoch 1

  23

    13.13.13.13 (metric 20) from 13.13.13.13 (13.13.13.13)

      Origin IGP, aigp-metric 51, metric 51, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

  Refresh Epoch 1

  23

    12.12.12.12 (metric 10) from 12.12.12.12 (12.12.12.12)

      Origin IGP, aigp-metric 31, metric 31, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

 

 

 

Посмотрим, что происходит, если один BGP сосед передает AIGP, в то время как другой сосед не «понимает» AIGP.

 

 

 

 

Отключим AIGP на R4 и перезапустим BGP сессию на R13, предварительно включив debug на R4

 

 

 

 

R4#deb ip bgp ipv4 unicast updates 13.13.13.13

*Mar  2 11:25:15.770: BGP: 13.13.13.13 Ignoring AIGP attribute because Address family doesn't support

 

 

 

Как ожидалось, R4 игнорирует AIGP.

 

 

 

 

Иногда может возникнуть ситуация когда нам требуется игнорировать атрибут AIGP, который передает нам соседний маршрутизатор. В этом случае, используется команда bgp bestpath aigp ignore. Если роутер получает два маршрута и при этом один из них имеет метрику AIGP, а другой нет, то метрика AIGP при вычислении лучшего маршрута игнорируется. Расмотрим работу этой опции на R1.

 

 

 

router bgp 23

 bgp log-neighbor-changes

 bgp bestpath aigp ignore

 

 

 

Сейчас лучший маршрут на 100.4.4.4 идет через R3, так как AIGP метрика ниже.

 

 

 

R1(config-router)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 43

BGP Bestpath: aigp-ignore

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 1

  1213, (received & used)

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, aigp-metric 30, metric 30, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 3

  1213, (received & used)

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, aigp-metric 60, metric 60, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

Отключим передачу AIGP между R1 и R3.

Проверим, согласно метрике IGP в AS23 лучшим маршрутом должен стать маршрут через R2.

 

 

 

R1(config-router-af)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 57

BGP Bestpath: aigp-ignore

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 3

  1213

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 30, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 2

  1213

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, aigp-metric 60, metric 60, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

Вопреки ожиданиям, лучшим маршрутом остался маршрут через R3. Похоже, что ожидания не вполне соответствуют описанному в документации.

В документации сказано следующее

 

 

 

If this knob is enabled, then the BGP does not use AIGP tie-breaking unless both of the paths have the AIGP metric attribute. This means that the AIGP attribute is not evaluated during the best path selection process between two paths when one path does not have the AIGP attribute.

 

 

 

То есть  AIGP не учитывается при вычислении маршрута, если один префикс не имеет атрибута.

В нашем случае, один маршрут приходит с  атрибутом AIGP, другой нет, тем не менее, маршрут с AIGP все равно «выигрывает».

 

 

 

Судя по всему, описанное в документации поведение, отличается от того, что происходит на практике,  так как при конфигурации маршрутизатор  показывает следующее

 

 

 

R1(config-router)#bgp bestpath ?

  aigp              if both paths doesn't have aigp ignore on bestpath

                    comparision

 

 

 

Маршрутизатор показывает,  что игнорирование AIGP произойдет, если оба маршрута не имеют AIGP, что в-общем логично, так как и нечего сравнивать. Попробуем отключить AIGP и между R1 и R2.

Проверяем.

 

 

 

R1(config-router)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 60

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 3

  1213

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 30, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 3

  1213

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, metric 60, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

Несмотря на то, что IGP метрика до R2 лучше, лучший маршрут до  R4 все равно идет через R3.

Это происходит потому что, BGP метрика через  R3 меньше. Но мы отключили использование AIGP метрики, попытаемся разобраться, почему меняется MED.

Между R2 и R1 AIGP не передается, но передается между XR12 и R2.

 

 

 

 

Посмотрим на дамп трафика между XR12 и R2.  ( см рис.4 )

Рис.4

 

 

 

 

XR12 отправляет MED=60, это значение IGP метрики настроенное между XR12 и R4. Судя по всему,

IOS  копирует значение метрики IGP в атрибут MED по умолчанию, хотя мы и не настраивали такое поведение. Дело в том, что при анонсировании префикса с помощью команды network, как сделано в нашем примере, метрика IGP автоматически копируется в атрибут BGP MED. Попытаемся изменить данное поведение, установив на XR12 значение метрики вручную, путем редактирования route-policy SET_AIGP

 

 

 

RP/0/0/CPU0:XR12(config)#route-policy SET_AIGP

Fri Mar  3 08:16:12.738 UTC

% WARNING: Policy object route-policy SET_AIGP' exists! Reconfiguring it via CLI will replace current definition. Use 'abort to cancel.

RP/0/0/CPU0:XR12(config-rpl)#

 

 

 

 

Ошибка.

 

 

 

 

Дело в том, что редактирование политик в IOS-XR производится несколько другим способом, путем запуска редактора

 

 

 

RP/0/0/CPU0:XR12#edit route-policy SET_AIGP

Fri Mar  3 08:18:29.049 UTC

[OK]

  GNU nano 2.0.2          File: /tmp/rpl_edit.1409188

 

route-policy SET_AIGP

  set aigp-metric igp-cost

  set med 0

end-policy

!

 

                               [ Wrote 5 lines ]

 

Proceed with commit (yes/no/cancel)? [cancel]: yes

Parsing.

74 bytes parsed in 1 sec (72)bytes/sec

Committing.

Prepared commit in 0 sec

 

1 items committed in 1 sec (0)items/sec

 

 

 

Также возможно изменять значение MED при входе в AS, и пожалуй, так даже правильнее, во избежание путаницы. Сделаем это на R3, для маршрутов, полученных с XR13.

 

 

 

 

route-map SET_MED permit 10

 set metric 0

 

router bgp 23

neighbor 10.3.13.13 remote-as 1213

 !

 address-family ipv4

  …

 neighbor 10.3.13.13 activate

  neighbor 10.3.13.13 aigp

  neighbor 10.3.13.13 soft-reconfiguration inbound

  neighbor 10.3.13.13 route-map SET_MED in

 

 

 

 

Проверим маршрут на R1

 

 

 

R1(config-router-af)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 68

Paths: (2 available, best #1, table default)

  Not advertised to any peer

  Refresh Epoch 9

  1213

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, metric 0, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 6

  1213

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 0, localpref 100, valid, internal

      rx pathid: 0, tx pathid: 0

 

 

 

Сейчас маршрутизируется, так как нам и требовалось, через R2, согласно IGP метрике.

 

 

 

 

Кратко рассмотрим использование атрибута Cost Community. Предположим, что R1 старый роутер, и не поддерживает AIGP, но есть потребность маршрутизировать трафик с учетом метрик IGP.

На R2 и R3 настроим передачу AIGP в атрибуте Cost Community

 

 

 

R2, R3

router bgp 23

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor 1.1.1.1 remote-as 23

 neighbor 1.1.1.1 update-source Loopback0

 neighbor 10.2.12.12 remote-as 1213

 !

 address-family ipv4

  network 100.1.1.1 mask 255.255.255.255 route-map AIGP_METRIC

  neighbor 1.1.1.1 activate

  neighbor 1.1.1.1 send-community both

  neighbor 1.1.1.1 aigp send cost-community 100 poi igp-cost transitive

 

 

 

Так как передача информации осуществляется в расширенной community, надо обратить внимание и не забыть передачу расширенной community соседу, при помощи команды send-community extended или send-community both, как в  нашем примере.

 

 

 

Проверим маршрутизацию на R1.

 

 

 

R1(config-router-af)#do show bgp ipv4 unicast 100.4.4.4/32

BGP routing table entry for 100.4.4.4/32, version 63

Paths: (2 available, best #2, table default)

  Not advertised to any peer

  Refresh Epoch 7

  1213

    2.2.2.2 (metric 31) from 2.2.2.2 (2.2.2.2)

      Origin IGP, metric 60, localpref 100, valid, internal

      Extended Community: Cost(transitive):igp:100:60

      rx pathid: 0, tx pathid: 0

  Refresh Epoch 3

  1213

    3.3.3.3 (metric 51) from 3.3.3.3 (3.3.3.3)

      Origin IGP, metric 30, localpref 100, valid, internal, best

      Extended Community: Cost(transitive):igp:100:30

      rx pathid: 0, tx pathid: 0x0

 

 

 

Значения AIGP копируются в Extended Community и позволяют осуществлять манипуляцию трафиком на основании значения AIGP атрибута.

 

 

Подведем итог –  использование дополнительных атрибутов AIGP и cost-community позволяет осуществлять более гибкое управление трафиком между автономными системами, так как позволяет передавать информацию об IGP метриках в BGP протоколе.

 

Loading.

Действия

Информация о блоге

Related Content