отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 

Манипуляция относительным значением MED на iBGP и eBGP линках

Cisco Employee

[toc:faq]

В статье будет рассмотрен вопрос манипуляции значением MED относительно оригинального значения на iBGP и eBGP линках, в частности будет проиллюстрировано, что относительное изменение значения может выглядеть как абсолютное. Так же будет рассмотрен вопрос учёта IGP метрики до машрутизатора, который является next-hop для маршрута, при анонсе маршрута в соседнюю автономную систему.

Что такое MED?

Итак, что такое MED? Из RFC4451, MULTI_EXIT_DISC есть опциональный нетранзитивный атрибут, который предназначен для использования на внешних (inter-AS) линках, чтобы  информировать eBGP-соседей о том, какой путь в автономную систему более предпочтительный.

Топология.

MED на iBGP линках.

Рассмотрим сценарий распространения атрибута MED на iBGP линках. Согласно RFC4451 атрибут MED передается внутри автономной системы и относительное изменение значения MED с помощью route-map будет иметь ожидаемый результат.

 

Маршрутизатор R1 из AS100 анонсирует префикс 192.168.100.0/24 с относительным изменением MED (+111). Так как команда show ip bgp показывает префиксы до обработки route-map мы видим только оригинальное значение MED (22), установленное при редистрибуции.

Конфигурация BGP на R1:

router bgp 100
bgp router-id 11.11.11.11
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback0
!
address-family ipv4
  redistribute connected metric 22 route-map NET198
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 route-map SET_MED out
route-map NET198 permit 10
match ip address prefix-list NET198
route-map SET_MED permit 10
set metric +111
R1#show ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 4
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (11.11.11.11)
      Origin incomplete, metric 22, localpref 100, weight 32768, valid, sourced, best
      rx pathid: 0, tx pathid: 0x

Итоговое значение MED (22 + 111 = 133) видно уже на соседнем маршрутизаторе ASBR1:

ASBR1#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 6
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 2
  Local
    11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)
      Origin incomplete, metric 133, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

MED на eBGP линках.

Рассмотрим теперь сценарий с eBGP линком. Cогласно все тому же RFC4451, атрибут MED нетранзитивный и получен по iBGP линку, а значит должен быть отброшен при передаче маршрута в соседнюю автономную систему, что как мы видим и происходит:

ASBR2#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
*>  192.168.100.0    10.10.21.1                             0 100 ?

И в случае, если будет использована route-map с относительным изменением значения MED, то, фактически, это будет означать абсолютное измненение.

ASBR1:

route-map SET_MED permit 10
set metric +55

...
neighbor 10.10.21.2 route-map SET_MED out
...
ASBR2#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
*>  192.168.100.0    10.10.21.1              55             0 100 ?

С первого взгляда это может показаться очевидным, однако, иногда факт того, что все происходит на eBGP линке может ускользнуть от внимания и такое поведение может оказаться неожиданным.

Команда set metric-type internal

Если существует необходимость учесть IGP метрику до маршрутизатора, который является next-hop для заданного маршрута, то можно использовать команду `set metric-type internal`.

ASBR1#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 6
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     3
  Refresh Epoch 2
  Local
    11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)
      Origin incomplete, metric 133, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

Значение IGP метрики до NH маршрута 192.168.100.0/24 - 2 (не путать со значением MED маршрута - 133).

После обработки маршрута route-map с относительным изменением значения MED и командой `set metric-type internal`:

route-map SET_MED permit 10
set metric +55
set metric-type internal

ожидаемым значением, которое будет анонсировано соседу, будет значение 2 + 55 = 57:

ASBR2#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 6
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  100
    10.10.21.1 from 10.10.21.1 (1.1.1.1)
      Origin incomplete, metric 57, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

Это бывает полезным, если маршрут присутствует в IGP и на ASBR этот маршрут анонсируется командой network <prefix>. В этом случае MED берется из IGP метрики и относительное изменение MED будет очевидным и ожидаемым результатом:

ASBR1#sh run | sec bgp
router bgp 100
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 10.10.21.2 remote-as 200
neighbor 11.11.11.11 remote-as 100
neighbor 11.11.11.11 update-source Loopback0
!
address-family ipv4
  network 192.168.100.0
  neighbor 10.10.21.2 activate
  neighbor 10.10.21.2 next-hop-self
  neighbor 10.10.21.2 route-map SET_MED out
  neighbor 11.11.11.11 activate
ASBR1#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 5
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 1
  Local
    10.100.21.2 from 0.0.0.0 (1.1.1.1)
      Origin IGP, metric 2, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  Local
    11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)
      Origin incomplete, metric 133, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
ASBR1#show ip route  192.168.100.0
Routing entry for 192.168.100.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area
  Advertised by bgp 100
  Last update from 10.100.21.2 on GigabitEthernet0/2, 00:00:57 ago
  Routing Descriptor Blocks:
  * 10.100.21.2, from 11.11.11.11, 00:00:57 ago, via GigabitEthernet0/2
      Route metric is 2, traffic share count is 1
ASBR2#sh ip bgp 192.168.100.0
BGP routing table entry for 192.168.100.0/24, version 4
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  100
    10.10.21.1 from 10.10.21.1 (1.1.1.1)
      Origin IGP, metric 57, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

Ссылки по теме.

2 Комментарии
New Member

Добрый день.

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

"который предназначен для использования на внешних (inter-AS) линках, чтобы  информировать eBGP-соседей о том, какой путь в автономную систему более предпочтительный."

Хотелось, бы понять плюсы использование "слабого" атрибута MED?

В протоколе BGP знаю несколько способов управления обратным трафиком, но MED для этих целей очень ограничен. Мне не понятно, а зачем вообще эти манипуляции делаются в данном случае, какой выигрыш получаем?

С уважением, 

Нестеркин Алексей

Cisco Employee

Алексей, добрый день,

спасибо за ваш отклик на мою запись.

Эту заметку я написал, взяв за скобки выбор администратора в пользу того или иного способа влиять на входящий трафик, неявно подразумевая, что администратор уже выбрал MED. Основной целью я ставил себе проиллюстрировать то, как атрибут MED передаётся и то, как можно учитывать IGP метрику префикса при передачи атрибута MED.

Полностью согласен, что MED, являясь "слабым" атрибутом, не всегда подходит для задач по влиянию на входящий трафик, по сравнению с такими техниками как AS prepend или community. Однако, если у вас сеть имеет несколько линков к одному апстриму и ваш апстрим готов принимать MED, то данная техника влияния не лишена смысла.

С уважением,

Антон Комаров.

999
Просмотры
0
Полезный материал
2
Комментарии