Протокол IP : Протокол BGP

Использование BGP-community Values для управления политикой маршрутизации в Upstream Provider Network

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (22 сентября 2010) | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Этот документ демонстрирует, как атрибут сообщества Протокола BGP может использоваться для управления маршрутизацией policy�in ее поставщик сетевых услуг восходящего сервиса.

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

Требования

Для понимания этого документа необходимо знать принципы работы протокола маршрутизации BGP. Дополнительные сведения см. в разделе Практические примеры BGP.

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

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования. Однако сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:

  • Cisco выпуск ПО IOS� 12.2 (27)

  • Маршрутизаторы Cisco серии 2500

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

Теоретические сведения

Маршрутизаторы поставщика Пока сами сообщества не изменяют процесс принятия решений по BGP, сообщества можно использовать как флаги для пометки набора маршрутов. Upstream₩½service могут тогда использовать эти флаги для применения определенных полицейских маршрутизации (например, локальный параметр) �within их сеть.

Поставщики услуг устанавливают соответствие между настраиваемыми значениями сообщества и значениями локального предпочтения в сети поставщика услуг. Идея в том, чтобы клиенты с определенными политиками, которые требуют изменения LOCAL_PREF в сети поставщика услуг, задавали соответствующие значения сообщества при обновлении маршрутов.

Сообщество – это группа префиксов, которые используют общее свойство и могут быть настроены с помощью атрибута сообщества BGP. Атрибут сообщества протокола BGP является дополнительным транзитивным атрибутом переменной длины. Этот атрибут состоит из четырех восьмиразрядных значений (октетов), которые определяют сообщество. Значения атрибута сообщества кодируются номером автономной системы (Autonomous System, AS) в двух первых восьмиразрядных значениях (октетах), а остальные два октета определяются автономной системой. Префикс может иметь несколько атрибутов сообщества. Спикер BGP, который видит множество атрибутов сообщества в префиксе, может действовать на основании одного, нескольких или всех атрибутов. Маршрутизатор может добавить или изменить атрибут сообщества, прежде чем передать атрибут другим точкам. Дополнительные сведения об атрибуте сообщества см. в разделе Практические примеры BGP.

Атрибут локального предпочтения показывает автономной системе, какой путь является предпочтительным для выхода в определенную сеть. Когда существуют разнообразные пути к тому же назначению, путь �the с более высоким приоритетом предпочтен (значение по умолчанию атрибутов локального параметра равняется 100). Дополнительные сведения см. в разделе Атрибут локального предпочтения.

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

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

Настройка

Управление политикой маршрутизации

В этом разделе содержатся сведения о настройке функций, описанных в этом документе.

Примечание: Дополнительные сведения о командах, используемых в данном документе, можно получить с помощью средства поиска команд (только для зарегистрированных клиентов).

Для упрощения предполагается, что соответствие между атрибутом сообщества и атрибутом локального предпочтения установлено между основным поставщиком услуг (AS 100) и клиентом (AS 30).

Локальное предпочтение Значения сообщества
130 100:300
125 100:250

Если пользователь объявляет префиксы с атрибутом сообщества равными 100:300, тогда основной поставщик услуг настраивает локальное предпочтение этих маршрутизаторов на 130 и 125, если атрибут сообщества равен 100:250.

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

На схема сети клиенту AS 30 требуется такая политика маршрутизации с атрибутами сообщества.

  • Трафик от поставщика AS 100 в направлении сети 6.6.6.0/24 идет по каналу R1-R3. В случае отказа канала R1-R3 весь трафик идет по каналу R2-R3.

  • Трафик от поставщика AS 100 в направлении сети 7.7.7.0/24 идет по каналу R2-R3. В случае отказа канала R2-R3 весь трафик идет по каналу R1-R3.

Чтобы применить эту политику маршрутизации, R3 объявляет свои префиксы:

Для R1:

  • 6.6.6.0/24 с атрибутом сообщества 100:300

  • 7.7.7.0/24 с атрибутом сообщества 100:250

На R2:

  • 6.6.6.0/24 с атрибутом community 100:250

  • 7.7.7.0/24 с атрибутом сообщества 100:300

Когда соседи R1 и R2 (протокол BGP) получат от R3 эти префиксы, R1 и R2 применяют предварительно настроенную политику на основе соответствия между атрибутами сообщества и атрибутами локального предпочтения (см. таблицу). Таким способом соблюдается нужная клиенту (AS 30) политика маршрутизации. R1 устанавливает префиксы в таблице BGP.

  • 6.6.6.0/24 с локальным предпочтением 130

  • 7.7.7.0/24 с локальным предпочтением 125

R2 устанавливает префикс в своей таблице BGP:

  • 6.6.6.0/24 с локальным параметром 125

  • 7.7.7.0/24 с локальным параметром 130

Поскольку критерии отбора пути BGP отдают предпочтение более высокому локальному приоритету, путь с локальным предпочтением 130 (130 больше, чем 125) выбирается как лучший путь в AS 100 и устанавливается в таблице IP-маршрутизации R1 и R2. Дополнительные сведения о критериях выбора пути BGP см. раздел Алгоритм выбора наилучшего пути BGP.

Схема сети

В этом документе используются настройки сети, показанные на данной диаграмме:

http://www.cisco.com/c/dam/en/us/support/docs/ip/border-gateway-protocol-bgp/28784-bgp-community.gif

Конфигурации

Эти конфигурации используются в данном документе:

R3
Current configuration : 2037 bytes
!
version 12.2
!
hostname R3
!
interface Loopback0
�ip address 6.6.6.1 255.255.255.0
!
interface Ethernet0/0
�ip address 7.7.7.1 255.255.255.0
!
interface Serial8/0
�ip address 10.10.13.3 255.255.255.0

!--- Interface connected to R1.

 !�
interface Serial9/0
�ip address 10.10.23.3 255.255.255.0

!--- Interface connected to R2.

!
router bgp 30
�network 6.6.6.0 mask 255.255.255.0
�network 7.7.7.0 mask 255.255.255.0

!--- Network commands announce prefix 6.6.6.0/24


!--- and 7.7.7.0/24.

�neighbor 10.10.13.1 remote-as 100

!--- Establishes peering with R1.

�neighbor 10.10.13.1 send-community

-
!--- Without this command, the community attributes
!--- are not sent to the neighbor.

�neighbor 10.10.13.1 route-map Peer-R1 out

!--- Configures outbound policy as defined by


!--- route-map "Peer-R1" when peering with R1.

�neighbor 10.10.23.2 remote-as 100

!--- Establishes peering with R2.

�neighbor 10.10.23.2 send-community

!--- Configures to send community attribute to R2.

�neighbor 10.10.23.2 route-map Peer-R2 out

!--- Configures outbound policy as defined by


!--- route-map "Peer-R2" when peering with R2.

�no auto-summary
!
ip classless
ip bgp-community new-format

!--- Allows you to configure the BGP community


!--- attribute in AA:NN format.

!
access-list 101 permit ip host 6.6.6.0 host 255.255.255.0
access-list 102 permit ip host 7.7.7.0 host 255.255.255.0
!
!
route-map Peer-R1 permit 10
�match ip address 101
�set community 100:300

!--- Sets community 100:300 for routes matching access-list 101.

!
route-map Peer-R1 permit 20
�match ip address 102
�set community 100:250

!--- Sets community 100:250 for routes matching access-list 102.

!
route-map Peer-R2 permit 10
�match ip address 101
�set community 100:250

!--- Sets community 100:250 for routes matching access-list 101.

!
route-map Peer-R2 permit 20
�match ip address 102
�set community 100:300

!--- Sets community 100:300 for routes matching access-list 102.

!
end

_________________________ М1
Version 12.2
!
hostname R1
!
interface Loopback0
�ip address 200.200.200.1 255.255.255.0
!���������
interface Serial8/0
�ip address 10.10.13.1 255.255.255.0

!--- Connected to R3.
�
!���������
interface Serial10/0
�ip address 10.10.12.1 255.255.255.0

!--- Connected to R2.

!���������
router bgp 100
�no synchronization
�bgp log-neighbor-changes
�neighbor 10.10.12.2 remote-as 100

!--- Establishes peering with R2.

�neighbor 10.10.12.2 next-hop-self
�neighbor 10.10.13.3 remote-as 30

!--- Establishes peering with R3.

�neighbor 10.10.13.3 route-map Peer-R3 in

!--- Configures the inbound policy as defined by


!--- route-map "Peer-R3" when peering with R3.

�no auto-summary
!���������
ip bgp-community new-format

!--- Allows you to configure the BGP community


!--- attribute in AA:NN format.

ip community-list 1 permit 100:300
ip community-list 2 permit 100:250

!--- Defines community list 1 and 2.

!���������
route-map Peer-R3 permit 10
�match community 1
�set local-preference 130

!--- Sets local preference 130 for all routes


!--- matching community list 1.

!���������
route-map Peer-R3 permit 20
�match community 2
�set local-preference 125

!--- Sets local preference 125 for all routes


!--- matching community list 2.

!���������
route-map Peer-R3 permit 30


!--- Without this permit 30 statement, updates that do not 


!--- match the permit 10 or permit 20 statements are dropped.


!
end

_________________________ М2
Version 12.2
!
hostname R2
!
interface Loopback0
ip address 192.168.50.1 255.255.255.0
!
interface Serial9/0
ip address 10.10.23.2 255.255.255.0

!--- Connected to R3.

!
interface Serial10/0
ip address 10.10.12.2 255.255.255.0

!--- Connected to R1.

!
router bgp 100
�no synchronization
�bgp log-neighbor-changes
�neighbor 10.10.12.1 remote-as 100

!--- Establishes iBGP peering with R1.

�neighbor 10.10.12.1 next-hop-self
�neighbor 10.10.23.3 remote-as 30

!--- Establishes peering with R3.

�neighbor 10.10.23.3 route-map Peer-R3 in

!--- Configures inbound policy as defined by


!--- route-map "Peer-R3" when peering with R3.

�no auto-summary
!
ip bgp-community new-format

!--- Allows you to configure the BGP community


!--- attribute in AA:NN format.

!
ip community-list 1 permit 100:300
ip community-list 2 permit 100:250

!--- Defines community list 1 and 2.

!
route-map Peer-R3 permit 10
�match community 1
�set local-preference 130

!--- Sets local preference 130 for all routes


!--- matching community list 1.

!�
route-map Peer-R3 permit 20
�match community 2
�set local-preference 125

!--- Sets local preference 125 for all routes


!--- matching community list 2.

!
route-map Peer-R3 permit 30


!--- Without this permit 30 statement, updates that do not 


!--- match the permit 10 or permit 20 statements are dropped.

!

end

Проверка.

R1 получает префиксы 6.6.6.0/24 и 7.7.7.0/24 с атрибутами сообщества 100:300 и 100:250, как показано жирным шрифтом в выводе команды show ip bgp в этом разделе.

Примечание: Как только эти маршруты установлены в таблицу BGP на основе настроенной политики, префиксы с сообществом 100:300 являются назначенным локальным параметром 130, и префиксы с сообществом 100:250 являются назначенным локальным параметром 125.

R1# show ip bgp 6.6.6.0 
BGP routing table entry for 6.6.6.0/24, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
� Advertised to non peer-group peers:
� 10.10.12.2�
� 30
��� 10.10.13.3 from 10.10.13.3 (6.6.6.1)
����� Origin IGP, metric 0, localpref 130, valid, external, best
����� Community: 100:300

!--- Prefix 6.6.6.0/24 with community 100:300 received from


!--- 10.10.13.3 (R3) is assigned local preference 130.

R1# show ip bgp 7.7.7.0 
BGP routing table entry for 7.7.7.0/24, version 4
Paths: (2 available, best #1, table Default-IP-Routing-Table)
� Advertised to non peer-group peers:
� 10.10.13.3�
� 30
��� 10.10.12.2 from 10.10.12.2 (192.168.50.1)
����� Origin IGP, metric 0, localpref 130, valid, internal, best

!--- Received prefix 7.7.7.0/24 over iBGP from 10.10.12.2


!--- (R2) with local preference 130.

� 30
��� 10.10.13.3 from 10.10.13.3 (6.6.6.1)
����� Origin IGP, metric 0, localpref 125, valid, external
����� Community: 100:250

!--- Prefix 7.7.7.0/24 with community 100:250 received from


!--- 10.10.13.3 (R3) is assigned local preference 125.

R1# show ip bgp
BGP table version is 4, local router ID is 200.200.200.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

�� Network��������� Next Hop����������� Metric LocPrf Weight Path
*> 6.6.6.0/24������ 10.10.13.3�������������� 0��� 130����� 0 30 i
*>i7.7.7.0/24������ 10.10.12.2�������������� 0��� 130����� 0 30 i
*������������������ 10.10.13.3�������������� 0��� 125����� 0 30 i

Команда show ip bgp в R1 подтверждает, что наилучший путь, выбранный в R1, имеет локальное предпочтение (LoclPrf) = 130.

Точно так же R2 получает префиксы 6.6.6.0/24 и 7.7.7.0/24 с атрибутами сообщества 100:250 и 100:300, как показано жирным шрифтом на выходе команды show ip bgp в этом разделе.

Примечание: Как только эти маршруты установлены в таблицу BGP, на основе настроенной политики, префиксы с сообществом 100:300 являются назначенным локальным параметром 130, и префиксы с сообществом 100:250 являются назначенным локальным параметром 125.

R2# show ip bgp 6.6.6.0
BGP routing table entry for 6.6.6.0/24, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
� Advertised to non peer-group peers:
� 10.10.23.3�
� 30
��� 10.10.23.3 from 10.10.23.3 (6.6.6.1)
����� Origin IGP, metric 0, localpref 125, valid, external
����� Community: 100:250

!--- Prefix 6.6.6.0/24 with community 100:250 received from


!--- 10.10.23.3 (R3) is assigned local preference 125.

� 30
��� 10.10.12.1 from 10.10.12.1 (200.200.200.1)
����� Origin IGP, metric 0, localpref 130, valid, internal, best

!--- Received prefix 6.6.6.0/24 over iBGP from 10.10.12.1


!--- (R1) with local preference 130.

R2# show ip bgp 7.7.7.0
BGP routing table entry for 7.7.7.0/24, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table)
� Advertised to non peer-group peers:
� 10.10.12.1�
� 30
��� 10.10.23.3 from 10.10.23.3 (6.6.6.1)
����� Origin IGP, metric 0, localpref 130, valid, external, best
����� Community: 100:300

!--- Prefix 7.7.7.0/24 with community 100:300 received from


!--- 10.10.23.3 (R3) is assigned local preference 130.

R2# show ip bgp
BGP table version is 3, local router ID is 192.168.50.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

�� Network��������� Next Hop����������� Metric LocPrf Weight Path
*� 6.6.6.0/24������ 10.10.23.3�������������� 0��� 125����� 0 30 i
*>i���������������� 10.10.12.1�������������� 0��� 130����� 0 30 i
*> 7.7.7.0/24������ 10.10.23.3�������������� 0��� 130����� 0 30 i

Вывод команды show ip bgp в R2 подтверждает, что наилучший путь, выбранный в R2, имеет локальное предпочтение (LoclPrf) = 130.

IP route к prefix� 6.6.6.0/24 предпочитает ссылку R1-R3, выходящую из AS 100 к AS 30. Команда show ip route на R1 и R2 подтверждает это.

R1# show ip route 6.6.6.0
Routing entry for 6.6.6.0/24
� Known via "bgp 100", distance 20, metric 0
� Tag 30, type external
� Last update from 10.10.13.3 3d21h ago
� Routing Descriptor Blocks:
� * 10.10.13.3, from 10.10.13.3, 3d21h ago
����� Route metric is 0, traffic share count is 1
����� AS Hops 1

!--- On R1, the IP route to prefix 6.6.6.0/24 points


!--- to next hop 10.10.13.3 which is R3 serial 8/0


!--- interface on the R1-R3 link.

R2# show ip route 6.6.6.0
Routing entry for 6.6.6.0/24
� Known via "bgp 100", distance 200, metric 0
� Tag 30, type internal
� Last update from 10.10.12.1 3d21h ago
� Routing Descriptor Blocks:
� * 10.10.12.1, from 10.10.12.1, 3d21h ago
����� Route metric is 0, traffic share count is 1
����� AS Hops 1

!--- On R2, IP route to prefix 6.6.6.0/24 points


!--- to next hop R1 (10.10.12.1) on its iBGP link.


!--- Thus traffic to network 6.6.6.0/24 from R2


!--- exits through R2-R1 and then�R1-R3 link from


!--- AS 100 towards AS 30.

IP route к prefix�7.7.7.0/24 предпочитает ссылку R2-R3, выходящую из AS 100 к AS 30. Команда show ip route на R1 и R2 подтверждает это.

R2# show ip route 7.7.7.0�
Routing entry for 7.7.7.0/24
� Known via "bgp 100", distance 20, metric 0
� Tag 30, type external
� Last update from 10.10.23.3 3d22h ago
� Routing Descriptor Blocks:
� * 10.10.23.3, from 10.10.23.3, 3d22h ago
����� Route metric is 0, traffic share count is 1
����� AS Hops 1

!--- On R2, IP route to prefix 7.7.7.0/24 points


!--- to next hop 10.10.23.3 which is R3 serial 9/0


!--- interface on R2-R3 link.

R1# show ip route 7.7.7.0
Routing entry for 7.7.7.0/24
� Known via "bgp 100", distance 200, metric 0
� Tag 30, type internal
� Last update from 10.10.12.2 3d22h ago
� Routing Descriptor Blocks:
� * 10.10.12.2, from 10.10.12.2, 3d22h ago
����� Route metric is 0, traffic share count is 1
����� AS Hops 1


!--- On R1, IP route to prefix 7.7.7.0/24 points


!--- to next hop R2 (10.10.12.2) on its iBGP link.


!--- Thus traffic to network 7.7.7.0/24�from�R1


!--- exits through R1-R2 and then�R2-R3 link


!--- from AS 100 towards AS 30.

В случае отказа одного канала, например, канала R1-R3, весь трафик должен идти по каналу R2-R3. Вы сможете смоделировать это, если закроете канал между R1-R3.

R1# conf t
Enter configuration commands, one per line.�End with CNTL/Z.
R1(config)#int s8/0
R1(config-if)#shut
R1(config-if)#
3d22h: %BGP-5-ADJCHANGE: neighbor 10.10.13.3 Down Interface flap
3d22h: %LINK-5-CHANGED: Interface Serial8/0, changed state to
  administratively down
3d22h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial8/0,
  changed state to down

Обратите внимание на таблицу IP-маршрутизации для префиксов 6.6.6.0/24 и 7.7.7.0/24 в маршрутизаторах R1 и R2. Используйте канал R2-R3 для выхода из AS 100.

R1# show ip route 6.6.6.0
Routing entry for 6.6.6.0/24
� Known via "bgp 100", distance 200, metric 0
� Tag 30, type internal
� Last update from 10.10.12.2 00:01:47 ago
� Routing Descriptor Blocks:
� * 10.10.12.2, from 10.10.12.2, 00:01:47 ago
����� Route metric is 0, traffic share count is 1
����� AS Hops 1
R1# show ip route 7.7.7.0
Routing entry for 7.7.7.0/24
� Known via "bgp 100", distance 200, metric 0
� Tag 30, type internal
� Last update from 10.10.12.2 3d22h ago
� Routing Descriptor Blocks:
� * 10.10.12.2, from 10.10.12.2, 3d22h ago
����� Route metric is 0, traffic share count is 1
����� AS Hops 1

Этот вывод команды show показывает, что маршрут для префиксов 6.6.6.0/24 и 7.7.7.0/24 указывает на следующий ожидаемый сегмент 10.10.12.2 (R2). Теперь посмотрим на таблицу IP-маршрутизации в R2, чтобы проверить следующий участок для префиксов 6.6.6.0/24 и 7.7.7.0/24. Для успешной работы следующим должен быть R3 в соответствии с настроенной политикой.

R2# show ip route 6.6.6.0
Routing entry for 6.6.6.0/24
� Known via "bgp 100", distance 20, metric 0
� Tag 30, type external
� Last update from 10.10.23.3 00:04:10 ago
� Routing Descriptor Blocks:
� * 10.10.23.3, from 10.10.23.3, 00:04:10 ago
����� Route metric is 0, traffic share count is 1
����� AS Hops 1
R2# show ip route 7.7.7.0
Routing entry for 7.7.7.0/24
� Known via "bgp 100", distance 20, metric 0
� Tag 30, type external
� Last update from 10.10.23.3 3d22h ago
� Routing Descriptor Blocks:
� * 10.10.23.3, from 10.10.23.3, 3d22h ago
����� Route metric is 0, traffic share count is 1
����� AS Hops 1

Следующий сегмент 10.10.23.3 – это последовательный интерфейс 9/0 в R3 канала R2-R3. � Это подтверждает настроенную политику, работает как ожидалось.

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

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


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


Document ID: 28784