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

Реализация IOS Функции PE-CE iBGP

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

Введение

Этот документ описывает, как Внутренний протокол граничного шлюза (iBGP) между функцией Границы провайдера (PE) и Порта заказчика Customer Edge (CE) внедрен в Cisco IOS®.

Внесенный Люком Де Гееном, специалистом службы технической поддержки Cisco.

Общие сведения

До новой функции PE-CE iBGP, iBGP между PE и CE (следовательно на Виртуальной маршрутизации и Передаче (VRF) интерфейс на Периферийном маршрутизаторе) официально не поддерживался. Одно исключение является iBGP на интерфейсах VRF в CE Мульти-VRF (Облегченная VRF) настройка. Мотивация для развертывания этой функции:

  • Клиент хочет иметь один одиночный Номер автономной системы (ASN) на множественных сайтах VRF без развертываний Внешнего протокола пограничного шлюза (eBGP) с as-override.

  • Клиент хочет предоставить отражение внутреннего маршрута к Маршрутизаторам CE, действуя, как будто ядро Поставщика услуг (SP) является одним прозрачным рефлектором маршрута (RR).

С этой функцией сайты VRF могут иметь тот же ASN как ядро SP. Однако в случае, если ASN сайтов VRF является другим, чем ASN ядра SP, это может быть сделано появиться то же с использованием Локальной Автономной системы (AS) функции.

PE-CE iBGP внедрения

Вот две главных части, чтобы заставить эту функцию работать:

  • Новый ATTR_SET атрибута был добавлен к протоколу BGP для переноса атрибутов BGP VPN по ядру SP прозрачным способом.
  • Сделайте Периферийный маршрутизатор RR для сеансов IBGP к Маршрутизаторам CE в VRF и как RR к соседним узлам VPNv4 (другие Периферийные маршрутизаторы или RRs).


Новый атрибут ATTR_SET позволяет SP переносить все атрибуты BGP клиента прозрачным способом и не вмешивается в атрибуты SP и политику BGP. Такие атрибуты являются кластерным списком, локальным параметром, сообществами, и т.д.

Атрибут маршрута клиента BGP

ATTR_SET является новым атрибутом BGP, используемым для переноса атрибутов BGP VPN клиента SP. Это - дополнительный транзитивный атрибут. В этом атрибуте можно перенести все атрибуты BGP клиента из сообщения Обновления BGP, за исключением MP_REACH и атрибутов MP_UNREACH.

Атрибут ATTR_SET имеет этот формат:

 
                     +------------------------------+
                     | Attr Flags (O|T) Code = 128 |
                     +------------------------------+
                     | Attr. Length (1 or 2 octets) |
                     +------------------------------+
                     | Origin AS (4 octets)        |
                     +------------------------------+
                     | Path Attributes (variable)  |
                     +------------------------------+

Флаги атрибута являются обычными флагами атрибута BGP (обратитесь к RFC 4271). Длина атрибута указывает, является ли длина атрибута одним или двумя октетами. Цель поля Origin AS состоит в том, чтобы предотвратить утечку одного маршрута, инициируемого в одном AS, который будет пропущен к другому AS без надлежащего манипулирования AS_PATH. Поле Path Attributes переменной длины переносит атрибуты BGP VPN, которые нужно перенести по ядру SP.

На выходном Периферийном маршрутизаторе атрибуты BGP VPN выдвинуты в этот атрибут. На входном Периферийном маршрутизаторе эти атрибуты суются от атрибута, прежде чем префикс BGP будет передан Маршрутизатору CE. Этот атрибут предоставляет изоляцию атрибутов BGP между сетью провайдеров услуг и VPN клиента и наоборот. Например, атрибут списка кластера Отражения маршрута SP не замечают и рассматривают в сети VPN., Но также и, атрибут списка кластера отражения маршрута VPN не замечают и рассматривают в сети провайдеров услуг.

Взгляд на рисунок 1, чтобы видеть, что распространение BGP клиента снабжает префиксом по сети провайдеров услуг.

                                                      Рис. 1

CE1 и CE2 находятся в том же AS как сеть провайдеров услуг: 65000. PE1 настроили iBGP к CE1. PE1 отражает путь для префикса 10.100.1.1/32 к RR в сети провайдеров услуг. RR отражает путь iBGP к Периферийным маршрутизаторам, как обычно. PE2 отражает путь к CE2.

Для этого для работы должным образом вы должны:

  • Имейте код на PE1 и PE2, который имеет поддержку характеристик PE-CE iBGP

  • Настройте PE1 и PE2 для выполнения Отражения маршрута на их сеансе BGP к их соответствующим Маршрутизаторам CE

  • Имейте next-hop-self на Периферийных маршрутизаторах для сеанса BGP к их Маршрутизаторам CE

  • Удостоверьтесь, что каждый сайт VPN использует другие Признаки маршрута (RD)

Настройка

Обратитесь к рисунку 1.

Вот необходимая конфигурация для PE1 и PE2:

PE1

vrf definition customer1
rd 65000:1
route-target export 1:1
route-target import 1:1
!
address-family ipv4
exit-address-family

router bgp 65000
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 65000
neighbor 192.168.100.3 update-source Loopback0
!
address-family vpnv4
 neighbor 192.168.100.3 activate
 neighbor 192.168.100.3 send-community extended
exit-address-family
!
address-family ipv4 vrf customer1
 neighbor 10.1.1.4 remote-as 65000
 neighbor 10.1.1.4 activate
 neighbor 10.1.1.4 internal-vpn-client
 neighbor 10.1.1.4 route-reflector-client
 neighbor 10.1.1.4 next-hop-self
exit-address-family
PE2

vrf definition customer1
 rd 65000:2
 route-target export 1:1
 route-target import 1:1
 !
 address-family ipv4
 exit-address-family

router bgp 65000
 bgp log-neighbor-changes
 neighbor 192.168.100.3 remote-as 65000
 neighbor 192.168.100.3 update-source Loopback0
 !
 address-family vpnv4
 neighbor 192.168.100.3 activate
 neighbor 192.168.100.3 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf customer1
 neighbor 10.1.2.5 remote-as 65000
 neighbor 10.1.2.5 activate
 neighbor 10.1.2.5 internal-vpn-client
 neighbor 10.1.2.5 route-reflector-client
 neighbor 10.1.2.5 next-hop-self
 exit-address-family

Примечание: Если PE не имеет соседнего узла <внутренний CE> команда внутреннего клиента VPN для соседнего узла CE, это не распространяется префиксы от CE к SP маршрутизаторы RRs/PE.

Примечание: Если PE не является RR в VRF, это не распространяется префиксы от маршрутизаторов RRs/PE к Маршрутизатору CE.

Новая команда

Существует новая команда, соседний узел <внутренний CE> внутренний клиент VPN, чтобы заставить этот feaure работать. Это должно быть настроенный на Периферийном маршрутизаторе только для сеанса IBGP к Маршрутизаторам CE.

Примечание: CE Мульти-VRF PE-CE iBGP (Облегченная VRF) функция все еще поддерживается без соседнего узла <внутренний CE> команда внутреннего клиента VPN.

Примечание:. Когда соседний узел <внутренний CE> в конфигурацию также, команда внутреннего клиента VPN настроена, соседний узел <внутренний CE> route-reflector-client и соседний узел <внутренний CE> команды next-hop-self автоматически помещен, когда или из соседнего узла <внутренний CE> route-reflector-client и соседний узел <внутренний CE> команды next-hop-self (или оба) удалены, и повторная загрузка выполнена, тогда они автоматически отложены в конфигурацию.

Подробный взгляд на ATTR_SET

Обратитесь к рисунку 1.

Это - префикс, объявленный CE1:

CE1#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 2
Paths: (1 available, best #1, table default)
 Advertised to update-groups:
    4        
 Refresh Epoch 1
 Local
   0.0.0.0 from 0.0.0.0 (10.100.1.1)
     Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
     rx pathid: 0, tx pathid: 0x0

Когда PE1 получает префикс BGP 10.100.1.1/32 от CE1, это хранит его дважды:

PE1#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 21
Paths: (2 available, best #1, table customer1)
 Advertised to update-groups:
    5        
 Refresh Epoch 1
 Local, (Received from ibgp-pece RR-client)
   10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
     Origin IGP, metric 0, localpref 200, valid, internal, best
     mpls labels in/out 18/nolabel
     rx pathid: 0, tx pathid: 0x0
 Refresh Epoch 1
 Local, (Received from ibgp-pece RR-client), (ibgp sourced)
   10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
     Origin IGP, localpref 100, valid, internal
     Extended Community: RT:1:1
     mpls labels in/out 18/nolabel
     rx pathid: 0, tx pathid: 0

Первый путь является фактическим путем на PE1, потому что это получено от CE1.

Второй путь является путем, который объявлен к маршрутизаторам RRs/PE. Это отмечено с полученным ibgp. Это содержит атрибут ATTR_SET. Заметьте, что этот путь имеет одну или более целей Маршрута (СИГНАЛ RTS), подключенный к нему.

PE1 объявляет префикс как показано здесь:

PE1#show bgp vpnv4 unicast all neighbors 192.168.100.3 advertised-routes 
BGP table version is 7, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
             x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

    Network         Next Hop           Metric LocPrf Weight Path
Route Distinguisher: 65000:1 (default for vrf customer1)
 *>i 10.100.1.1/32   10.1.1.4                0   200     0 i

Total number of prefixes 1

Это - то, как RR видит путь:

RR#show bgp vpnv4 un all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 10
Paths: (1 available, best #1, no table)
 Advertised to update-groups:
    3        
 Refresh Epoch 1
 Local, (Received from a RR-client)
   192.168.100.1 (metric 11) (via default) from 192.168.100.1 (192.168.100.1)
     Origin IGP, localpref 100, valid, internal, best
     Extended Community: RT:1:1
     Originator: 10.100.1.1, Cluster list: 192.168.100.1
     ATTR_SET Attribute:
       Originator AS 65000
       Origin IGP
       Aspath
       Med 0
       LocalPref 200
       Cluster list
       192.168.100.1,
       Originator 10.100.1.1
     mpls labels in/out nolabel/18
     rx pathid: 0, tx pathid: 0x0

Заметьте, что локальный параметр этого префикса индивидуальной рассылки VPNv4 в ядре равняется 100. В ATTR_SET сохранен исходный локальный параметр 200. Однако это прозрачно к RR в ядре SP.

На PE2 вы видите префикс как показано здесь:

PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 5
Paths: (1 available, best #1, no table)
 Not advertised to any peer
 Refresh Epoch 2
 Local
   192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
     Origin IGP, localpref 100, valid, internal, best
     Extended Community: RT:1:1
     Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
     ATTR_SET Attribute:
       Originator AS 65000
       Origin IGP
       Aspath
       Med 0
       LocalPref 200
       Cluster list
       192.168.100.1,
       Originator 10.100.1.1
     mpls labels in/out nolabel/18
     rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 6
Paths: (1 available, best #1, table customer1)
 Advertised to update-groups:
    1        
 Refresh Epoch 2
 Local, imported path from 65000:1:10.100.1.1/32 (global)
   192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
     Origin IGP, metric 0, localpref 200, valid, internal, best
     Originator AS(ibgp-pece): 65000
     Originator: 10.100.1.1, Cluster list: 192.168.100.1
     mpls labels in/out nolabel/18
     rx pathid:0, tx pathid: 0x0

Первый путь является тем, полученным от RR с ATTR_SET. Обратите внимание на то, что RD 65000:1, RD происхождения. Второй путь является импортированным путем от таблицы VRF с RD 65000:1. ATTR_SET был удален.

Это - путь, как замечено на CE2:

CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 10
Paths: (1 available, best #1, table default)
 Not advertised to any peer
 Refresh Epoch 1
 Local
   10.1.2.2 from 10.1.2.2 (192.168.100.2)
     Origin IGP, metric 0, localpref 200, valid, internal, best
     Originator: 10.100.1.1, Cluster list: 192.168.100.2, 192.168.100.1
     rx pathid: 0, tx pathid: 0x0

Заметьте, что следующий переход 10.1.2.2, который является PE2. Кластерный список содержит маршрутизаторы PE1 и PE2. Это RRs, которые имеют значение в VPN. RR SP (10.100.1.3) не находится в кластерном списке.

Локальный параметр 200 был сохранен в VPN по сети провайдеров услуг.

 Команда обновлений индивидуальной рассылки bgp vpnv4 отладки показывает обновление, распространившееся в сети провайдеров услуг:

PE1#
BGP(4): Revise route installing 1 of 1 routes for 10.100.1.1/32 -> 10.1.1.4
(customer1) to customer1 IP table
BGP(4): 192.168.100.3 NEXT_HOP changed SELF for ibgp rr-client pe-ce net
65000:1:10.100.1.1/32,
BGP(4): 192.168.100.3 Net 65000:1:10.100.1.1/32 from ibgp-pece 10.1.1.4 format
ATTR_SET
BGP(4): (base) 192.168.100.3 send UPDATE (format) 65000:1:10.100.1.1/32, next
192.168.100.1, label 16, metric 0, path Local, extended community RT:1:1
BGP: 192.168.100.3 Next hop is our own address 192.168.100.1
BGP: 192.168.100.3 Route Reflector cluster loop; Received cluster-id 192.168.100.1
BGP: 192.168.100.3 RR in same cluster. Reflected update dropped

RR#
BGP(4): 192.168.100.1 rcvd UPDATE w/ attr: nexthop 192.168.100.1, origin i, localpref
100, originator 10.100.1.1, clusterlist 192.168.100.1, extended community RT:1:1,
[ATTR_SET attribute: originator AS 65000, origin IGP, aspath , med 0, localpref 200,
cluster list 192.168.100.1 , originator 10.100.1.1]
BGP(4): 192.168.100.1 rcvd 65000:1:10.100.1.1/32, label 16
RT address family is not configured. Can't create RTC route 
BGP(4): (base) 192.168.100.1 send UPDATE (format) 65000:1:10.100.1.1/32, next
192.168.100.1, label 16, metric 0, path Local, extended community RT:1:1

PE2#
BGP(4): 192.168.100.3 rcvd UPDATE w/ attr: nexthop 192.168.100.1, origin i, localpref
100, originator 10.100.1.1, clusterlist 192.168.100.3 192.168.100.1, extended community
RT:1:1, [ATTR_SET attribute: originator AS 65000, origin IGP, aspath , med 0, localpref
200, cluster list 192.168.100.1 , originator 10.100.1.1]
BGP(4): 192.168.100.3 rcvd 65000:1:10.100.1.1/32, label 16
RT address family is not configured. Can't create RTC route 
BGP(4): Revise route installing 1 of 1 routes for 10.100.1.1/32 -> 192.168.100.1
(customer1) to customer1 IP table
BGP(4): 10.1.2.5 NEXT_HOP is set to self for net 65000:2:10.100.1.1/32,

Примечание: PE1 получил свое собственное обновление от RR и затем отбросил его. Это вызвано тем, что PE1 и PE2 находятся в той же группе обновления на RR.

Примечание: Если вы хотите формировать дамп завершенного Обновленного сообщения в шестнадцатеричном, используйте подробное ключевое слово для команды Обновлений BGP отладки.

PE2#  debug bgp vpnv4 unicast updates detail
BGP updates debugging is on with detail for address family: VPNv4 Unicast

PE2#
BGP(4): 192.168.100.3 rcvd UPDATE w/ attr: nexthop 192.168.100.1, origin i,
localpref 100, originator 10.100.1.1, clusterlist 192.168.100.3 192.168.100.1,
extended community RT:1:1, [ATTR_SET attribute: originator AS 65000, origin IGP,
aspath , med 0, localpref 200, cluster list 192.168.100.1 , originator 10.100.1.1]
BGP(4): 192.168.100.3 rcvd 65000:1:10.100.1.1/32, label 17
RT address family is not configured. Can't create RTC route 
BGP: 192.168.100.3 rcv update length 125
BGP: 192.168.100.3 rcv update dump: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
0090 0200 00
PE2#00 7980 0E21 0001 800C 0000 0000 0000 0000 C0A8 6401 0078 0001 1100 00FD E800
0000 010A 6401 0140 0101 0040 0200 4005 0400 0000 64C0 1008 0002 0001 0000 0001 800A
08C0 A864 03C0 A864 0180 0904 0A64 0101 C080 2700 00FD E840 0101 0040 0200 8004 0400
0000 0040 0504 0000 00C8 800A 04C0 A864 0180 0904 0A64 0101
BGP(4): Revise route installing 1 of 1 routes for 10.100.1.1/32 -> 192.168.100.1
(customer1) to customer1 IP table
BGP(4): 10.1.2.5 NEXT_HOP is set to self for net 65000:2:10.100.1.1/32,

Обработка следующего перехода

Next-hop-self должен быть настроен на Периферийных маршрутизаторах для этой функции. Причина для этого состоит в том, что обычно следующий переход транспортируется неизменный с iBGP. Однако здесь существует две отдельных сети: сеть VPN и сеть провайдеров услуг, которые выполняют отдельные Протоколы внутреннего шлюза (IGPs). Следовательно, метрика IGP не может легко сравниваться и использоваться для вычисления оптимального пути между этими двумя сетями. Подход, выбранный RFC 6368, должен иметь next-hop-self, обязательный для сеанса IBGP к CE, который избегает ранее описанной проблемы все вместе. Преимущество состоит в том, что сайты VRF могут выполнить другой IGPs с этим подходом.

RD

RFC 6368 упоминает, что рекомендуется, чтобы другие сайты VRF той же VPN использовали другой (уникальный) RDs. В Cisco IOS это является обязательным для этой функции.

Функция PE-CE iBGP с Local-AS

Обратитесь к рисунку 2. Customer1 VPN имеет ASN 65001.

                                                                                                          Рис. 2

CE1 находится в AS 65001. Для создания этого внутреннего BGP из точки зрения PE1 это требует характеристики local-as iBGP.

CE1

router bgp 65001
 bgp log-neighbor-changes
 network 10.100.1.1 mask 255.255.255.255
 neighbor 10.1.1.1 remote-as 65001

PE1

router bgp 65000
 bgp log-neighbor-changes
 neighbor 192.168.100.3 remote-as 65000
 neighbor 192.168.100.3 update-source Loopback0
 !
 address-family vpnv4
 neighbor 192.168.100.3 activate
 neighbor 192.168.100.3 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf customer1
 neighbor 10.1.1.4 remote-as 65001
 neighbor 10.1.1.4 local-as 65001
 neighbor 10.1.1.4 activate
 neighbor 10.1.1.4 internal-vpn-client
 neighbor 10.1.1.4 route-reflector-client
 neighbor 10.1.1.4 next-hop-self
 exit-address-family

PE2 и CE2 настроены так же.

PE1 видит префикс BGP как показано здесь:

PE1#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 41
Paths: (2 available, best #1, table customer1)
 Advertised to update-groups:
    5        
 Refresh Epoch 1
 Local, (Received from ibgp-pece RR-client)
   10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
     Origin IGP, metric 0, localpref 200, valid, internal, best
     mpls labels in/out 18/nolabel
     rx pathid: 0, tx pathid: 0x0
 Refresh Epoch 1
 Local, (Received from ibgp-pece RR-client), (ibgp sourced)
   10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
     Origin IGP, localpref 100, valid, internal
     Extended Community: RT:1:1
     mpls labels in/out 18/nolabel
     rx pathid: 0, tx pathid: 0

Префикс является внутренним BGP.

PE2 видит это:

PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 33
Paths: (1 available, best #1, no table)
 Not advertised to any peer
 Refresh Epoch 5
 Local
   192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
     Origin IGP, localpref 100, valid, internal, best
     Extended Community: RT:1:1
     Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
     ATTR_SET Attribute:
       Originator AS 65001
       Origin IGP
       Aspath
       Med 0
       LocalPref 200
       Cluster list
       192.168.100.1,
       Originator 10.100.1.1
     mpls labels in/out nolabel/18
     rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 34
Paths: (1 available, best #1, table customer1)
 Advertised to update-groups:
    5        
 Refresh Epoch 2
 Local, imported path from 65000:1:10.100.1.1/32 (global)
   192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
     Origin IGP, metric 0, localpref 200, valid, internal, best
     Originator AS(ibgp-pece): 65001
     Originator: 10.100.1.1, Cluster list: 192.168.100.1
     mpls labels in/out nolabel/18
     rx pathid: 0, tx pathid: 0x0

AS Инициатора 65001, который является AS, используемым, когда префикс передается от PE2 до CE2. Так, AS сохранен, и так является локальным параметром в данном примере.

CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 3
Paths: (1 available, best #1, table default)
 Not advertised to any peer
 Refresh Epoch 1
 Local
   10.1.2.2 from 10.1.2.2 (192.168.100.2)
     Origin IGP, metric 0, localpref 200, valid, internal, best
     Originator: 10.100.1.1, Cluster list: 192.168.100.2, 192.168.100.1
     rx pathid: 0, tx pathid: 0x0

Вы видите Локальный вместо Пути AS. Это означает, что это - внутренний маршрут BGP, инициируемый в AS 65001, который является также настроенным ASN маршрутизатора CE2. Все атрибуты BGP были взяты от атрибута ATTR_SET. Это придерживается правил для Случая 1 в следующем разделе.

Правила для обмена маршрутами между другими сайтами VRF

ATTR_SET содержит Инициатора С инициирующего VRF. Этот Инициирующий AS проверен удаленным PE, когда это удаляет ATTR_SET, прежде чем это передаст префикс к Маршрутизатору CE.

Пример 1: Если Инициирующий AS совпадает с настроенным Что касается Маршрутизатора CE, то атрибуты BGP взяты от атрибута ATTR_SET, когда PE импортирует путь в целевой VRF.

Случай 2: Если Инициирующий AS не совпадает с настроенным Что касается Маршрутизатора CE, то набор атрибутов для созданного пути взят как показано здесь:

  1. Атрибуты пути установлены в атрибуты, содержавшиеся в атрибуте ATTR_SET.

  2. От специфичных для iBGP атрибутов сбрасывают (LOCAL_PREF, ИНИЦИАТОР и CLUSTER_LIST).

  3. Количество AS Происхождения, содержавшееся в атрибуте ATTR_SET, предварительно ожидается к AS_PATH и придерживается правил, которые применяются к пирингу Внешнего BGP между источником и целевыми AS.

  4. Если автономная система, привязанная к VRF, совпадает с автономной системой поставщика VPN, и Атрибут as_path маршрута VPN не пуст, это, SHALL предварительно ожидается к Атрибуту as_path маршрута VRF.

    Обратитесь к рисунку 3. CE1 и PE1, имеют AS 65000 и настроены с функцией PE-CE iBGP. CE2 имеет ASN 65001. Это означает, что существует eBGP между PE2 и CE2.

    117567-technote-ibgp-03.jpg

                                                                                                        Рис. 3

PE2 видит маршрут следующим образом:

PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 43
Paths: (1 available, best #1, no table)
 Not advertised to any peer
 Refresh Epoch 6
 Local
   192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
     Origin IGP, localpref 100, valid, internal, best
     Extended Community: RT:1:1
     Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
     ATTR_SET Attribute:
       Originator AS 65000
       Origin IGP
       Aspath
       Med 0
       LocalPref 200
       Cluster list
       192.168.100.1,
       Originator 10.100.1.1
     mpls labels in/out nolabel/17
     rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 44
Paths: (1 available, best #1, table customer1)
 Advertised to update-groups:
    6        
 Refresh Epoch 6
 Local, imported path from 65000:1:10.100.1.1/32 (global)
   192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
     Origin IGP, metric 0, localpref 200, valid, internal, best
     Originator AS(ibgp-pece): 65000
     Originator: 10.100.1.1, Cluster list: 192.168.100.1
     mpls labels in/out nolabel/17
     rx pathid: 0, tx pathid: 0x0

Это - префикс, как замечено на CE2:

CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 5
Paths: (1 available, best #1, table default)
 Not advertised to any peer
 Refresh Epoch 1
 65000
   10.1.2.2 from 10.1.2.2 (192.168.100.2)
     Origin IGP, localpref 100, valid, external, best
     rx pathid: 0, tx pathid: 0x0

Это - Случай 2. Количество AS Происхождения, содержавшееся в атрибуте ATTR_SET, предварительно ожидается к AS_PATH PE2 и придерживается правил, которые применяются к равноправному информационному обмену eBGP между источником и целевым AS. Специфичные для iBGP атрибуты проигнорированы PE2, когда он создает маршрут, который будет объявлен к CE2. Так, локальный параметр равняется 100 а не 200 (как замечено в атрибуте ATTR_SET).

От CE к CE облегченное VRF отражение

Обратитесь к рисунку 4.

117567-technote-ibgp-04.jpg

                                                                                                      Рис. 4

Рисунок 4 показывает дополнительный Маршрутизатор CE, CE3, связанный с PE1. CE1 и CE3 оба связаны с PE1 на том же экземпляре VRF: заказчик 1. это означает, что CE1 и CE3 являются Маршрутизаторами CE Мульти-VRF (также известный как Облегченные VRF) PE1. PE1 помещает себя как следующий переход, когда это объявляет префиксы от CE1 до CE3. В случае, что это поведение не требуется, вы могли настроить соседний узел 10.1.3.6 неизменных следующим переходом на PE1. Для настройки этого необходимо удалить соседний узел 10.1.3.6 next-hop-self на PE1. Затем CE3 видит маршруты от CE1 с CE1, чтобы быть следующим переходом для тех префиксов BGP. Для создания этой работы вы требуете маршрутов для того Bgp next-hop в таблице маршрутизации CE3. Вы требуете протокола динамической маршрутизации (IGP) или статические маршруты на CE1, PE1 и CE3 для проверки, маршрутизаторы имеют маршрут для каждого IP - адреса следующего прыжка других. Однако существует проблема с этой конфигурацией.

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

router bgp 65000
 !
 address-family ipv4 vrf customer1
 neighbor 10.1.1.4 remote-as 65000
 neighbor 10.1.1.4 activate
 neighbor 10.1.1.4 internal-vpn-client
 neighbor 10.1.1.4 route-reflector-client
 neighbor 10.1.1.4 next-hop-self
 neighbor 10.1.3.6 remote-as 65000
 neighbor 10.1.3.6 activate
 neighbor 10.1.3.6 internal-vpn-client
 neighbor 10.1.3.6 route-reflector-client
 neighbor 10.1.3.6 next-hop-unchanged
 exit-address-family

Префикс от CE1 замечен прекрасный на CE3:

CE3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 9
Paths: (1 available, best #1, table default)
 Not advertised to any peer
 Refresh Epoch 1
 Local
   10.1.1.4 from 10.1.3.1 (192.168.100.1)
     Origin IGP, metric 0, localpref 200, valid, internal, best
     Originator: 10.100.1.1, Cluster list: 192.168.100.1
     rx pathid: 0, tx pathid: 0x0

Однако префикс от CE2 замечен на CE3 как показано здесь:

CE3#show bgp ipv4 unicast 10.100.1.2              
BGP routing table entry for 10.100.1.2/32, version 0
Paths: (1 available, no best path)
 Not advertised to any peer
 Refresh Epoch 1
 Local
   192.168.100.2 (inaccessible) from 10.1.3.1 (192.168.100.1)
     Origin IGP, metric 0, localpref 100, valid, internal
     Originator: 10.100.1.2, Cluster list: 192.168.100.1, 192.168.100.2
     rx pathid: 0, tx pathid: 0

BGP next-hop 192.168.100.2, IP - адрес обратной связи PE2. PE1 не переписывал BGP next-hop к себе, когда это объявило префикс 10.100.1.2/32 к CE3. Это делает этот префикс неприменимым на CE3.

Так, в случае соединения функции PE-CE iBGP по MPLS-VPN и Облегченному VRF iBGP, необходимо удостовериться, что у вас всегда есть next-hop-self на Периферийных маршрутизаторах.

Вы не можете сохранить следующий переход, когда Периферийный маршрутизатор является RR, который отражает, что маршруты IBGP от одного CE до другого CE по VRF взаимодействуют локально на PE. При выполнении PE-CE iBGP по сети MPLS VPN необходимо использовать внутреннего клиента VPN для сеансов IBGP к Маршрутизаторам CE. Когда у вас есть несколько локальных CE в VRF на Периферийном маршрутизаторе, тогда необходимо поддержать next-hop-self для тех Одноранговых соединений по протоколу BGP.

Вы могли посмотреть на route-map для установки следующего перехода в сам для префиксов, полученных от других Периферийных маршрутизаторов, но не для префиксов отражения от других локально связанных Маршрутизаторов CE. Однако это в настоящее время не поддерживается для установки следующего перехода в сам в исходящей карте маршрутов. Ту конфигурацию показывают здесь:

router bgp 65000

 address-family ipv4 vrf customer1
 neighbor 10.1.1.4 remote-as 65000
 neighbor 10.1.1.4 activate
 neighbor 10.1.1.4 internal-vpn-client
 neighbor 10.1.1.4 route-reflector-client
 neighbor 10.1.1.4 next-hop-self
 neighbor 10.1.3.6 remote-as 65000
 neighbor 10.1.3.6 activate
 neighbor 10.1.3.6 internal-vpn-client
 neighbor 10.1.3.6 route-reflector-client
 neighbor 10.1.3.6 route-map NH-setting out
 exit-address-family

ip prefix-list PE-loopbacks seq 10 permit 192.168.100.0/24 ge 32
!

route-map NH-setting permit 10
 description set next-hop to self for prefixes from other PE routers
 match ip route-source prefix-list PE-loopbacks
 set ip next-hop self
!

route-map NH-setting permit 20
 description advertise prefixes with next-hop other than the prefix-list in
route-map entry 10 above
!

Однако это не поддерживается:

PE1(config)#route-map NH-setting permit 10
PE1(config-route-map)# set ip next-hop self
% "NH-setting" used as BGP outbound route-map, set use own IP/IPv6 address for the nexthop not supported

Более старая Cisco IOS на периферийном маршрутизаторе

Если PE1 выполняет более старое программное обеспечение Cisco IOS, которое испытывает недостаток в PE-CE iBGP функции, то PE1 никогда не устанавливает себя как следующий переход для отраженных префиксов iBGP. Это означает, что отраженный префикс BGP (10.100.1.1/32) от CE1 (10.100.1.1) к CE2 - через PE1 - имел бы CE1 (10.1.1.4) как следующий переход.

CE3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 32
Paths: (1 available, best #1, table default)
 Not advertised to any peer
 Refresh Epoch 1
 Local
   10.1.1.4 from 10.1.3.1 (192.168.100.1)
     Origin IGP, metric 0, localpref 200, valid, internal, best
     Originator: 10.100.1.1, Cluster list: 192.168.100.1
     rx pathid: 0, tx pathid: 0x0

Префикс от CE2 (10.100.1.2/32) замечен с PE2 как следующий переход, потому что PE1 не делает next-hop-self для этого префикса также:

CE3#show bgp ipv4 unicast 10.100.1.2
BGP routing table entry for 10.100.1.2/32, version 0
Paths: (1 available, no best path)
 Not advertised to any peer
 Refresh Epoch 1
 Local
   192.168.100.2 (inaccessible) from 10.1.3.1 (192.168.100.1)
     Origin IGP, localpref 100, valid, internal
     Originator: 10.100.1.2, Cluster list: 192.168.100.1, 192.168.100.3, 192.168.100.2
     ATTR_SET Attribute:
       Originator AS 65000
       Origin IGP
       Aspath
       Med 0
       LocalPref 100
       Cluster list
       192.168.100.2,
       Originator 10.100.1.2
     rx pathid: 0, tx pathid: 0

Для функции PE-CE iBGP для работы должным образом все Периферийные маршрутизаторы для VPN, где опция активирована, должны иметь код, чтобы поддерживать функцию и включить функцию.

Next-hop-self для eBGP на VRF

Обратитесь к рисунку 5.

                                                                                                 Рис. 5

Рисунок 5 показывает Облегченную VRF настройку. Сеанс от PE1 к CE4 является eBGP. Сеанс от PE1 к CE3 является все еще iBGP.

Для префиксов eBGP следующий переход всегда установлен к сам, когда он объявляет префиксы к соседу iBGP на VRF. Если сеансу к соседу iBGP по VRF установили next-hop-self или нет, это независимо от факта.

На рисунке 5, CE3 видит префиксы от CE4 с PE1 как следующий переход.

CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 103
Paths: (1 available, best #1, table default)
 Not advertised to any peer
 Refresh Epoch 1
 65004
   10.1.3.1 from 10.1.3.1 (192.168.100.1)
     Origin IGP, metric 0, localpref 100, valid, internal, best
     rx pathid: 0, tx pathid: 0x0

Это происходит с next-hop-self на PE1 к CE3 или без.

Если интерфейсы на PE1 к CE3 и CE4 не находятся в VRF, а в глобальном контексте, next-hop-self к CE3 делает имеет значение.

Без next-hop-self на PE1 к CE3 вы видите:

PE1#show bgp vrf customer1 vpnv4 unicast neighbors 10.1.3.6
BGP neighbor is 10.1.3.6, vrf customer1, remote AS 65000, internal link
...
 For address family: VPNv4 Unicast
 Translates address family IPv4 Unicast for VRF customer1
 Session: 10.1.3.6
 BGP table version 1, neighbor version 1/0
 Output queue size : 0
 Index 12, Advertise bit 0
 Route-Reflector Client
 12 update-group member
 Slow-peer detection is disabled
 Slow-peer split-update-group dynamic is disabled
 Interface associated: (none)

Несмотря на то, что next-hop-self неявно включен, выходные данные не указывают на это. 

С next-hop-self на PE1 к CE3 вы видите:

PE1#show bgp vrf customer1 vpnv4 unicast neighbors 10.1.3.6 
BGP neighbor is 10.1.3.6, vrf customer1, remote AS 65000, internal link
..
 For address family: VPNv4 Unicast
...
 NEXT_HOP is always this router for eBGP paths

Принимая во внимание, что, если интерфейсы к CE3 и CE4 находятся в глобальном контексте, следующий переход для префиксов от CE4 является самим CE4, когда не настроен next-hop-self:

CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 124
Paths: (1 available, best #1, table default)
 Not advertised to any peer
 Refresh Epoch 1
 65004
   10.1.4.7 from 10.1.3.1 (192.168.100.1)
     Origin IGP, metric 0, localpref 100, valid, internal, best
     rx pathid: 0, tx pathid: 0x0

Для next-hop-self на PE1 к CE3:

CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 125
Paths: (1 available, best #1, table default)
 Not advertised to any peer
 Refresh Epoch 1
 65004
   10.1.3.1 from 10.1.3.1 (192.168.100.1)
     Origin IGP, metric 0, localpref 100, valid, internal, best
     rx pathid: 0, tx pathid: 0x0

Это было сделано на основе RFC 4364.

Если вы хотите к next-hop-self "not set" для префиксов eBGP к сеансу IBGP для интерфейса VRF, необходимо настроить неизменный следующим переходом. Поддержка этого только произошла с идентификатором ошибки Cisco CSCuj11720.

router bgp 65000
...
 address-family ipv4 vrf customer1
 neighbor 10.1.1.4 remote-as 65000
 neighbor 10.1.1.4 activate
 neighbor 10.1.1.4 route-reflector-client
 neighbor 10.1.3.6 remote-as 65000
 neighbor 10.1.3.6 activate
 neighbor 10.1.3.6 route-reflector-client
 neighbor 10.1.3.6 next-hop-unchanged
 neighbor 10.1.4.7 remote-as 65004
 neighbor 10.1.4.7 activate
 exit-address-family

Теперь, CE3 рассматривает CE4 как следующий переход для префиксов, объявленных CE4:

CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 130
Paths: (1 available, best #1, table default)
 Not advertised to any peer
 Refresh Epoch 3
 65004
   10.1.4.7 from 10.1.3.1 (192.168.100.1)
     Origin IGP, metric 0, localpref 100, valid, internal, best
     rx pathid: 0, tx pathid: 0x0

При попытке настроить неизменное следующим переходом ключевое слово для сеанса IBGP к CE3 на Коде Cisco IOS до идентификатора ошибки Cisco CSCuj11720, вы встречаетесь с этой ошибкой:

PE1(config-router-af)# neighbor 10.1.3.6 next-hop-unchanged 
%BGP: Can propagate the nexthop only to multi-hop EBGP neighbor

После идентификатора ошибки Cisco CSCuj11720 неизменное следующим переходом ключевое слово допустимо для соседей по протоколу EBGP мультиперехода и iBGP Облегченные VRF соседние узлы.


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

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


Document ID: 117567