Протокол IP : IP-маршрутизация

Использование маршрутизаторами BGP атрибута Multi-Exit Discriminator для выбора оптимального пути

29 июля 2008 - Перевод, выполненный профессиональным переводчиком
Другие версии: PDF-версия:pdf | Машинный перевод (28 июля 2013) | Английский (23 марта 2012) | Отзыв

Содержание

Введение
Предварительные услуги
     Требования
     Используемые компоненты
     Условные обозначения
Атрибут MED
     Пример
Команда bgp deterministic-med
     Примеры
Связанные обсуждения сообщества поддержки Cisco
Дополнительная информация

Введение

В этом документе описано использование команды bgp deterministic-med и объясняется, как она воздействует на выбор пути на основе MED.

Предварительные условия

Требования

Для данного документа нет особых требований.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к устройству или какой-либо версии ПО.

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

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. в статье Условные обозначения, используемые в технической документации Cisco.

Атрибут MED

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

В этом разделе описан пример использования MED для влияния на решение маршрутизации, принятого соседней AS.

Топология:

37_01.gif

Пример

В этом сценарии AS 65502 является заказчиком ISP, имеющим AS 65501. R4 соединен с двумя разными маршрутизаторами на стороне ISP в целях резервирования и поддерживает объявления двух сетей ISP – 10.4.0.0/16 и 10.5.0.0/16. В этом разделе показана относительная конфигурация.

R4

!
version 12.3
!
hostname r4
!
ip cef
!
!
interface Loopback10
 ip address 10.4.0.1 255.255.0.0
!
interface Loopback11
 ip address 10.5.0.1 255.255.0.0
!
interface Serial0/0
 ip address 192.168.20.4 255.255.255.0
!
interface Serial1/0
 ip address 192.168.30.4 255.255.255.0
!
router bgp 65502
 no synchronization
 bgp log-neighbor-changes
 network 10.4.0.0 mask 255.255.0.0
 network 10.5.0.0 mask 255.255.0.0
 neighbor 192.168.20.2 remote-as 65501
 neighbor 192.168.30.3 remote-as 65501
 no auto-summary
!
ip classless
!
!
line con 0
 exec-timeout 0 0
line aux 0
line vty 0 4
 exec-timeout 0 0
 login
!
!
end

R2

!
version 12.3
!
hostname r2
!
ip cef
!
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Ethernet0/0
 ip address 172.16.0.2 255.255.255.0
!
interface Serial1/0
 ip address 192.168.1.2 255.255.255.0
 serial restart-delay 0
!
interface Serial2/0
 ip address 192.168.20.2 255.255.255.0
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 redistribute connected
 passive-interface Serial2/0
 network 2.2.2.2 0.0.0.0 area 0
 network 172.16.0.2 0.0.0.0 area 0
 network 192.168.1.2 0.0.0.0 area 0
 network 192.168.20.2 0.0.0.0 area 0
!
router bgp 65501
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 65501
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 65501
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 192.168.20.4 remote-as 65502
 no auto-summary
!
ip classless
!
!
line con 0
 exec-timeout 0 0
 transport preferred all
 transport output all
line aux 0
 transport preferred all
 transport output all
line vty 0 4
 exec-timeout 0 0
 login
 transport preferred all
 transport input all
 transport output all
!
end

Конфигурация R1 и R3 подобна конфигурации R2. R3 имеет eBGP, равноправный по отношению к R4, и iBGP, равноправный по отношению к R1.

R1 имеет iBGP, равноправный по отношению к R2, и iBGP, равноправный по отношению к R3. Посмотрим, что отображают таблицы R1, R2 и R3 BGP для двух сетей, объявляемых R4:

r2# show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 7
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  1.1.1.1 3.3.3.3 
  65502
    192.168.20.4 from 192.168.20.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best
  65502
    192.168.30.4 (metric 74) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal

r2# show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 6
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  1.1.1.1 3.3.3.3 
  65502
    192.168.30.4 (metric 74) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.20.4 from 192.168.20.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best

r3# show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 8
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  1.1.1.1 2.2.2.2 
  65502
    192.168.20.4 (metric 74) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.30.4 from 192.168.30.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best

r3# show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  1.1.1.1 2.2.2.2 
  65502
    192.168.30.4 from 192.168.30.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best
  65502
    192.168.20.4 (metric 74) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal

r1# show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  65502
    192.168.20.4 (metric 128) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
  65502
    192.168.30.4 (metric 128) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal

r1# show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Not advertised to any peer
  65502
    192.168.30.4 (metric 128) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.20.4 (metric 128) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

Как можно видеть, R2 и R3 выбирают в качестве оптимального пути внешний маршрут из R4, что и предполагается согласно алгоритму выбора оптимального пути BGP. Дополнительные сведения см. в статье Алгоритм выбора оптимального пути BGP.

Аналогично, R1 выбирает R2 для доступа к двум сетям, что сделано согласно правилу выбора оптимального пути BGP – выбор пути с наименьшим идентификатором маршрутизатора при всех прочих равных атрибутах. Так ID маршрутизатора R2 – 2.2.2.2 , а ID маршрутизатора R3 – 3.3.3.3, то выбран R2. В базовой конфигурации весь трафик двух сетей в AS 65502 проходит от R1 через R2, а затем по умолчанию к R4. Предположим, что R4 необходимо перераспределить трафик, полученный из AS 65501. Чтобы сделать это без запроса изменений со стороны R4 ISP, необходимо настроить R4 на использование MED для направления трафика одной сети по одному пути и трафика другой сети - по другому пути.

Вот какова конфигурация R4 после применения необходимых настроек.

R4

!
version 12.3
!
hostname r4
!
ip cef
!
!
!
interface Loopback10
 ip address 10.4.0.1 255.255.0.0
!
interface Loopback11
 ip address 10.5.0.1 255.255.0.0
!
interface Serial0/0
 ip address 192.168.20.4 255.255.255.0
!
interface Serial1/0
 ip address 192.168.30.4 255.255.255.0
!
router bgp 65502
 no synchronization
 bgp log-neighbor-changes
 network 10.4.0.0 mask 255.255.0.0
 network 10.5.0.0 mask 255.255.0.0
 neighbor 192.168.20.2 remote-as 65501
 neighbor 192.168.20.2 route-map setMED-R2 out
 neighbor 192.168.30.3 remote-as 65501
 neighbor 192.168.30.3 route-map setMED-R3 out
 no auto-summary
!
ip classless
no ip http server
!
!
access-list 1 permit 10.4.0.0 0.0.255.255
access-list 2 permit 10.5.0.0 0.0.255.255
!
route-map setMED-R3 permit 10
 match ip address 1
 set metric 200
!
route-map setMED-R3 permit 20
 match ip address 2
 set metric 100
!--- Схема маршрутов MED-R3 применяет MED 200 к сети 10.4.0.0/16 
!--- и MED 100 к сети 10.5.0.0/16.
!--- Схема маршрутов применяется в направлении внешнего R3.

!
route-map setMED-R2 permit 10
 match ip address 1
 set metric 100
!
route-map setMED-R2 permit 20
 match ip address 2
 set metric 200
!--- Схема маршрутов MED-R3 применяет MED 100 к сети 10.4.0.0/16 
!--- и MED 200 к сети 10.5.0.0/16.
!--- Схема маршрутов применяется в направлении внешнего R2.

!
!
!
line con 0
 exec-timeout 0 0
line aux 0
line vty 0 4
 exec-timeout 0 0
 login
!
!
end

Примечание. Необходимо сбросить сеанс BGP командой clear ip bgp * soft out, например, чтобы ввести конфигурацию в действие.

Сейчас R1 считает маршрут через R2 оптимальным путем для сети 10.4.0.0/16, так как обновление, полученное из R2, имеет MED 100, а не MED 200, который объявляется R3. Аналогично, R1 использует R3, а соединение R3 – R4 используется для доступа к 10.5.0.0/16.

r1# show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 14
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
  Not advertised to any peer
  65502
    192.168.20.4 (metric 128) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 100, localpref 100, valid, internal, best
r1#sh ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
  Not advertised to any peer
  65502
    192.168.30.4 (metric 128) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 100, localpref 100, valid, internal, best

Посмотрим на отображаемые данные R2:

r2# show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  1.1.1.1 3.3.3.3 
  65502
    192.168.20.4 from 192.168.20.4 (4.4.4.4)
      Origin IGP, metric 100, localpref 100, valid, external, best


r2# show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  192.168.20.4 
  65502
    192.168.30.4 (metric 74) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 100, localpref 100, valid, internal, best
  65502
    192.168.20.4 from 192.168.20.4 (4.4.4.4)
      Origin IGP, metric 200, localpref 100, valid, external

Причина, почему для R2 отображается только один путь для 10.4.0.0/16, состоит в том, что R3 отменяет обновления (отправляет обновление с метрикой "недостижим") для 10.4.0.0/16, как только замечает, что R3 использует R2 для доступа к 10.4.0.0/16 (после установки оптимального пути BGP на всех доступных путях).

r3# show ip bgp 10.4.0.0
BGP routing table entry for 10.4.0.0/16, version 20
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  192.168.30.4 
  65502
    192.168.20.4 (metric 74) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 100, localpref 100, valid, internal, best
  65502
    192.168.30.4 from 192.168.30.4 (4.4.4.4)
      Origin IGP, metric 200, localpref 100, valid, external

Это позволяет R2 экономить память, поскольку ему не требуется хранить бесполезную информацию. Если сеанс BGP между R2 и R4 прерывается, R2 отправляет обновление о недостижимости к R3 для 10.4.0.0/16. Это обновление инициирует R3 отправить обновление к другому маршруту R3 для 10.4.0.0/16 через R4 к R2. R2 начинает маршрутизацию через R3.

Команда bgp deterministic-med

Включение команды bgp deterministic-med снимает временную зависимость от решений выбора оптимального пути на базе MED. Это гарантирует точное сравнение MED для всех маршрутов, полученных из той же автономной системы (AS).

При выключении команды bgp deterministic-med порядок получения маршрутов может повлиять на решения выбора оптимального пути на базе MED. Данная ситуация происходит, если один и тот же маршрут принимается из множества систем AS или подсистем AS с одинаковой длиной пути, но различными MED.

Примеры

Например, рассмотрим следующие маршруты.

entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10
entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5
entry3: ASPATH 1, MED 200, external

Порядок, в котором приняты BGP- маршруты следующий: entry3, entry2 и entry3 (entry3 – самая старая в BGP-таблице,а entry1 – самая новая).

Маршрутизатор BGP с выключенной командой bgp deterministic-med

Маршрутизатор BGP с выключенной командой bgp deterministic-med выбирает entry2, а не entry1, благодаря атрибуту IGP более низкого уровня для достижения следующего участка NEXT_HOP (MED не используется в данном решении, так как entry1 и entry2 принадлежат двум разным AS). Запись entry3 предпочтительнее, чем entry2, так как она внешняя. Однако entry3 имеет большее значение MED по сравнению с entry1. Дополнительные сведения об условиях выбора пути BGP см. в разделе Алгоритм выбора оптимального пути BGP.

Маршрутизатор BGP с выключенной командой bgp deterministic-med

В этом случае маршруты одной и той же AS группируются вместе, и записи (entry) оптимального маршрута каждой группы сравниваются. В приведенном примере две AS: AS 1 и AS 2.

Group 1:  entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10
          entry3: ASPATH 1, MED 200, external
Group 2:  entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5

В группе 1 оптимальным путем является entry1 из-за меньшего значения (MED используется в этом решении, хотя пути исходят из одной и той же AS). В группе 2 существует только одна запись (entry2). Оптимальный путь в данном случае определяется сравнением победителей в каждой группе (MED не используется в этом сравнении по умолчанию, так как победители каждой группы принадлежат разным AS – включение команды bgp always-compare-med изменяет действие по умолчанию). При сравнении entry1 (победителя из группы 1) и entry2 (победителя из группы 2), "побеждает" entry2, так как он обладает атрибутом лучшей метрикой IGP для следующего участка тракта.

Если команда bgp always-compare-med все также выключена, тогда при сравнении запись 1 (победителя из группы 1) и запись 2(победителя из группы 2), побеждает запись 1 из-за MED более низкого уровня.

Cisco рекомендует включение команды bgp deterministic-med при развертывании всех новых сетей. Кроме того, если команда bgp always-compare-med включена, то решения BGP MED всегда являются детерминистическими.

Подробные сведения о командах bgp deterministic-med и bgp always-compare-med см. в статье Как команда bgp deterministic-med отличается от команды bgp always-compare-med.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 13759