BGP Best Path Selection

автором Codyв BGP, Cisco (IOS/IOS-XE/IOS-XR), Network- Опубликовано

Вступление

BGP, в отличии от других протоколов маршрутизации, выбирает лучший путь на основе критериев (атрибутов). Например, тот же OSPF (Open Shortest Path First) или IS-IS (Intermediate System to Intermediate System) делают выбор на основе cost, который в свою очередь основывается на пропускной способности линка (Bandwidth) – если не задать это вручную, RIP выбирает лучший маршрут на основе кол-ва хопов, EIGRP же рассчитывает лучший маршрут на основе пропускной способности (Bandwidth) и задержки (Delay). А вот BGP, как было упомянуто ранее, уже на основе целого списка атрибутов.

Теория

В свою очередь BGP атрибуты делятся на четыре группы (категории):
1) Well-know mandatory – Распознаются всеми BGP реализациями/роутерми и должны присутствовать во всех bgp update’ах.
2) Well-know discretionary – Распознаются всеми BGP реализациями/роутерми и их присутствие в BGP update’ах необязательное.
3) Optional transitive – Могут как распознаваться так и не распознаваться роутерами, если атрибут не распознался, то роутер помечает обновление как частичное (partial) и отправляет его остальным bgp соседям, сохраняя при этом не распознанный атрибут.
4) Optional nontransitive – Могут как распознаваться так и не распознаваться роутерами. BGP соседям не передается.

Список атрибутов

Непосредственно сам список:

  • Well-know mandatory:
    • As-path
    • Next-hop
    • Origin Code
  • Well-know discretionary:
    • Local preference
    • Atomic aggregate
  • Optional transitive:
    • Aggregator
    • Community
  • Optional nontransitive:
    • MED
    • Originator-id
    • Cluster list

Процесс выбора маршрута

Процесс выбора лучшего маршрута (сверху вниз):

  1. Проверка доступности next-hop’а
  2. Weight
  3. Local Preference
  4. Originate Locally
  5. AS-Path
  6. Origin Code
  7. MED
  8. Path Type
  9. Shortest IGP path to BGP next hop (only for iBGP)
  10. Oldest Path (only for eBGP)
  11. Router-ID
  12. Cluster Length Lists
  13. Neighbor Address

Под первым пунктом я явно указал доступность next-hop‘а, т.к. если у маршрута будет недоступен next-hop, то маршрут не попадет в таблицу маршрутизации и не будет анонсироваться (advertise) соседям.

Weight (вес) есть только в Cisco роутерах т.к. это проприетарный атрибут. Используется локально роутером и не передается соседям. Атрибут влияет на исходящий трафик. Возможное значение от 0 до 65535. По умолчанию значение 0, но если маршрут локальный (local), то значение будет 32768. Маршрут с наивысшим значением weigh является предпочтительным.

Local Preference как и weight влияет на исходящий трафик, но при этом этот атрибут передается внутри локальной AS, т.е. между iBGP соседями, если eBGP сосед получит update с LP, то он просто его проигнорирует. Чем выше значение тем предпочтительней маршрут. Возможное значение от 0 до 4294967295 (вроде как 232). По умолчанию значение 100.

Originate Locally – это маршрут, который оригинируется локально, т.е. в bgp таблице он будет с next-hop’ом 0.0.0.0, это либо маршрут который задан через network, либо агрегируется на роутере, либо редистрибьютиться. Соответственно такой будет предпочтительней.

AS-Path кол-во пройденных AS’ок, чем короче тем предпочтительней.

Origin Code всего их существует 3 варианта:
0 – IGP
1 – EGP
2 – Incomplete
Встречаются только 0 и 2, т.к. 1 это протокол EGP, предшественник BGP, более не используется. Если 0 то имеется ввиду маршрут, который задан через network, а 2 через редистрибьюцию. В cisco роутерах, в таблице BGP (столбец Path – Origin Code) IGP (0) представлен как i, а Incomplete (2) как ? . Чем ниже значение кода, тем предпочтительней путь. т.е. 0 лучше чем 2. Передается и в другие AS домены.

MED (Multi-Exit Discriminator) или metric влияет на входящий трафик в твою AS, т.е. если у другой AS, с которой ты имеешь пиринги, если несколько стыков в твою AS тогда с помощью MED ты можешь регулировать входящий трафик. Атрибут передается в AS, с которой у тебя пиринг, но за пределы её не выходит. Возможное значение от 0 до 4294967295. Стандартное значение 0.

Path Type – маршрут полученный от eBGP пира предпочтительней, чем от iBGP пира.

Shortest IGP path to BGP next hop (only for iBGP) – предпочтительней путь тот, который имеет внутри AS более низкую IGP метрику к BGP next-hop’у.

Oldest Path (only for eBGP) – если у роутера префикс виден от двух и более eBGP соседей, то бестовый путь будет тот, который более “старее” .

Router-ID чем меньше значение router-id, тем более предпочтительней маршрута.

Cluster Length Lists – в случае использования RR (Route Reflector), путь у которого наименьший Cluster Length Lists, предпочтительней.

Neighbor Address, чем ниже peer адрес, тем предпочтительней.

Практика

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

Из предварительной конфигурации тут BGP (с поддержкой add-path) и IGP внутри AS100 (ospf) и AS200 (is-is). В AS100 роутеры на базе IOS-XE, а в AS200 IOS-XR. Y-RR3 и B-RR3 настроены как рефлектора.

Next-hop

Начнём с самого первого же, недоступность next-hop’а. Вроде бы элементарно, но все же хочется показать.

В выхлопе show bgp на против маршрута мы не увидим значка “>” говорящем о том, что он лучший (best).
А если детально в bgp посмотреть префикс, то рядом с next-hop‘ом будет inaccessible – т.е. некстхоп – недосягаемый/недоступный и в таблице маршрутизации у вас не будет маршрута до него (некстхопа).

RP/0/0/CPU0:B-RR3#show bgp | b 96.4.44.0/24
* i96.4.44.0/24       96.4.44.4                0    100      0 100 ?
* i                   96.5.55.5                     100      0 100 ?


RP/0/0/CPU0:B-RR3#show bgp 96.4.44.0/24
Mon Mar 28 21:57:17.160 UTC
BGP routing table entry for 96.4.44.0/24
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker               1618        1618
Last Modified: Mar 28 21:54:38.652 for 00:02:38
Paths: (2 available, no best path)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  100, (Received from a RR-client)
    96.4.44.4 (inaccessible) from 44.44.44.44 (44.44.44.44)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Received Path ID 0, Local Path ID 0, version 0
  Path #2: Received by speaker 0
  Not advertised to any peer
  100, (Received from a RR-client)
    96.5.55.5 (inaccessible) from 55.55.55.55 (55.55.55.55)
      Origin incomplete, localpref 100, valid, internal
      Received Path ID 0, Local Path ID 0, version 0

Weight

Cisco проприетарный атрибут, используемый только на циско ротуерах и только локально.

Для примера разберем участок между CE1 и Y-PE1/Y-PE2.
Посмотрим как со стороны AS100 мы идем к 111.111.111.111/32:

Y-PE1#show bgp | b 111.111.111.111/32
 * i 111.111.111.111/32
                        2.2.2.2                   0    100      0 1 ?
 *>                     111.100.111.2             0             0 1 ?

Y-PE1#show bgp 111.111.111.111/32
BGP routing table entry for 111.111.111.111/32, version 6
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     6         
  Refresh Epoch 2
  1
    2.2.2.2 (metric 3) from 3.3.3.3 (3.3.3.3)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Originator: 2.2.2.2, Cluster list: 3.3.3.3
      rx pathid: 0x1, tx pathid: 0
  Refresh Epoch 1
  1
    111.100.111.2 from 111.100.111.2 (111.111.111.111)
      Origin incomplete, metric 0, localpref 100, valid, external, best

      rx pathid: 0, tx pathid: 0x0

Y-RR3#show bgp | b 111.111.111.111/32
 * ia111.111.111.111/32
                        2.2.2.2                  0    100      0 1 ?
 *>i                    1.1.1.1                  0    100      0 1 ?
        

Y-RR3#show bgp 111.111.111.111/32
BGP routing table entry for 111.111.111.111/32, version 420
Paths: (2 available, best #2, table default)
  Path advertised to update-groups:
     7         
  Refresh Epoch 1
  1, (Received from a RR-client)
    2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, all
      rx pathid: 0, tx pathid: 0x1
  Path advertised to update-groups:
     7         
  Refresh Epoch 1
  1, (Received from a RR-client)
    1.1.1.1 (metric 2) from 1.1.1.1 (1.1.1.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0

т.е. трафик к CE1 ходит через “верх” – через Y-PE1.
Для наглядности проверим еще трассировкой со стороны CE2:

CE2#traceroute 111.111.111.111 source lo0 nu 
Type escape sequence to abort.
Tracing the route to 111.111.111.111
VRF info: (vrf in name/id, vrf out name/id)
  1 222.200.222.5 8 msec 2 msec 5 msec
  2 200.33.22.1 [AS 200] 21 msec 17 msec 5 msec
  3 200.33.44.2 [AS 200] 18 msec 9 msec 7 msec
  4 96.4.44.4 [AS 200] 19 msec 10 msec 9 msec
  5 100.3.4.1 [AS 100] 15 msec 13 msec 13 msec
  6 100.3.1.2 [AS 100] 37 msec 16 msec 15 msec
  7 111.100.111.2 [AS 100] 20 msec *  27 msec

Теперь сделаем так чтобы Y-PE1 начал ходить до лупбека CE1 (111.111.111.111/32) через Y-PE2, для этого выставим вес в 201 до лупбека получаемого от Y-RR3, который в свою очередь знает о маршруте от Y-PE2.
Для этого создадим ACL в которую поместим только один этот лупбек и ACL поместим в route-map (не забываем создать еще один sequence number в котором оставим все пусто (т.е. все остальное пропускаем), т.к. иначе все кроме префикса из ACL будем дропать – неявное дени). route-map применяем на нейбора Y-RR3 в направлении IN, мы ведь локально на роутере хотим изменить атрибут, а для этого нужно на приём, пока маршрут не заинсталился в таблицу BGP, изменить его атрибут. Да и к тому weight не передается и на out его вешать смысла нет (хотя циска и поругается, но мапу все равно навесит).

Y-PE1 (IOS-XE):
access-list 1 permit host 111.111.111.111
!
route-map TEST-WEIGHT permit 10
 match ip address 1
 set weight 201
route-map TEST-WEIGHT permit 20
!
router bgp 100
 !
 address-family ipv4
  neighbor 3.3.3.3 route-map TEST-WEIGHT in
 !
!

Посмотрим, что получилось

Y-PE1#show bgp | b 111.111.111.111/32
 *>i 111.111.111.111/32
                        2.2.2.2                  0    100    201 1 ?
 *                      111.100.111.2            0             0 1 ?

Y-PE1#show bgp 111.111.111.111/32    
BGP routing table entry for 111.111.111.111/32, version 790
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 5
  1
    2.2.2.2 (metric 3) from 3.3.3.3 (3.3.3.3)
      Origin incomplete, metric 0, localpref 100, weight 201, valid, internal, best

      Originator: 2.2.2.2, Cluster list: 3.3.3.3
      rx pathid: 0x0, tx pathid: 0x0
  Refresh Epoch 4
  1
    111.100.111.2 from 111.100.111.2 (111.111.111.111)
      Origin incomplete, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

Y-RR3#show bgp | b 111.111.111.111/32
 *>i 111.111.111.111/32
                        2.2.2.2                  0    100      0 1 ?

Y-RR3#show bgp 111.111.111.111/32
BGP routing table entry for 111.111.111.111/32, version 703
Paths: (1 available, best #1, table default)
  Path advertised to update-groups:
     7         
  Refresh Epoch 1
  1, (Received from a RR-client)
    2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

Проверим теперь трассировку со стороны CE2 > CE1:

CE2#traceroute 111.111.111.111 source lo0 nu
Type escape sequence to abort.
Tracing the route to 111.111.111.111
VRF info: (vrf in name/id, vrf out name/id)
  1 222.200.222.5 10 msec 2 msec 2 msec
  2 200.33.22.1 [AS 200] 14 msec 6 msec 4 msec
  3 200.33.44.2 [AS 200] 15 msec 6 msec 7 msec
  4 96.4.44.4 [AS 200] 14 msec 10 msec 11 msec
  5 100.3.4.1 [AS 100] 25 msec 12 msec 13 msec
  6 100.3.2.2 [AS 100] 21 msec 21 msec 18 msec
  7 111.100.111.6 [AS 100] 17 msec *  22 msec

Хотелось бы еще заострить внимание на двух вещах:
1)На IOS-XE пока не будет триггера на новый update, weight не применится. Я для этого выполнял Route-refresh – clear ip bgp 3.3.3.3 soft.
2)Как это все происходит внутри AS. Если обратим внимание, то на Y-RR3 путь до 111.111.111.111/32 через Y-PE1 вовсе пропал с таблицы BGP, а связано это с тем, что Y-PE1 отправил update с withdrawn лупбеком CE1 т.е “отозвал” NLRI с 111.111.111.111/32.

Того имеем, что маршрут через Y-PE1 до лупбека CE1 ни кто больше не знает, кроме его самого, даже сам рефлектор. Такое поведение будет актуально с MED и с LP.

Кстати, на IOS-XR конфиг выглядит похоже:

B-PE1 (IOS-XR):
RP/0/0/CPU0:B-PE1(config)#show com ch dif
Tue Mar 29 17:34:27.123 UTC
Building configuration...
!! IOS XR Configuration 6.0.1
   !
+  prefix-set LOOPBACK-CE2
+    222.222.222.222/32
+  end-set
+  route-policy TEST-MED
+    if destination in LOOPBACK-CE2 then
+      set weight 302
+    endif
+    pass
+  end-policy
   router bgp 200
+   neighbor 33.33.33.33
+    address-family ipv4 unicast
+     route-policy TEST-MED in
     !
    !
   !
end

RP/0/0/CPU0:B-PE1#show bgp | b 222.222.222.222/32
Tue Mar 29 17:49:59.049 UTC
*>i222.222.222.222/32 22.22.22.22              0    100    302 2 ?
*                     222.200.222.2            0             0 2 ?


RP/0/0/CPU0:B-PE1#show bgp 222.222.222.222/32
Tue Mar 29 17:50:19.438 UTC
BGP routing table entry for 222.222.222.222/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 34          34
Last Modified: Mar 29 17:35:00.220 for 00:15:19
Paths: (2 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  2
    22.22.22.22 (metric 30) from 33.33.33.33 (22.22.22.22)
      Origin incomplete, metric 0, localpref 100, weight 302, valid, internal, best, group-best
      Received Path ID 1, Local Path ID 1, version 34
      Originator: 22.22.22.22, Cluster list: 33.33.33.33
  Path #2: Received by speaker 0
  Not advertised to any peer
  2
    222.200.222.2 from 222.200.222.2 (222.222.222.222)
      Origin incomplete, metric 0, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: not-found

Local Preference

С помощью LP мы можем повлиять на исходящий трафик внутри локальной AS. В примере попробуем сделать так, чтобы трафик из CE1 до CE2 шел через Y-ASBR5 <> B-ASBR5.
Сейчас трафик до 222.222.222.222/32 ходит через “верх” (Y-ASBR4 <> Y-ASBR4) т.к. рефлектора выбрали этот путь из-за низкого route-id у ASBR4
Проверим трассировкой на CE1

CE1#traceroute 222.222.222.222 source lo0 num
Type escape sequence to abort.
Tracing the route to 222.222.222.222
VRF info: (vrf in name/id, vrf out name/id)
  1 111.100.111.5 5 msec 1 msec 2 msec
  2 100.3.2.1 [AS 100] 14 msec 7 msec 5 msec
  3 100.3.4.2 [AS 100] 10 msec 6 msec 7 msec
  4 96.4.44.44 [AS 100] 21 msec 11 msec 11 msec
  5 200.33.44.1 [AS 200] 21 msec 11 msec 12 msec
  6 200.33.11.2 [AS 200] 23 msec 15 msec 22 msec
  7 222.200.222.2 [AS 200] 17 msec *  50 msec

А так же маршрутную инф-ю в самом bgp на Y-RR3 и Y-ASBR4 

Y-RR3#show bgp 222.222.222.222/32
BGP routing table entry for 222.222.222.222/32, version 43
Paths: (2 available, best #1, table default)
  Path advertised to update-groups:
     1         
  Refresh Epoch 1
  200 2, (Received from a RR-client)
    96.4.44.44 (metric 2) from 4.4.4.4 (4.4.4.4)
      Origin incomplete, metric 0, localpref 100, valid, internal, best

      rx pathid: 0, tx pathid: 0x0
  Path advertised to update-groups:
     1         
  Refresh Epoch 1
  200 2, (Received from a RR-client)
    96.5.55.55 (metric 2) from 5.5.5.5 (5.5.5.5)
      Origin incomplete, metric 0, localpref 100, valid, internal, all
      rx pathid: 0, tx pathid: 0x1


Y-ASBR4#show bgp | b 222.222.222.222/32
 * i 222.222.222.222/32
                       96.5.55.55               0    100      0 200 2 ?
 *>                   96.4.44.44                             0 200 2 ?

С помощью Local Preference мы можем повлиять на это двумя способами: занижаем LP на лучшем маршруте т.е. для 222.222.222.222/32 на Y-ASBR4 или, наоборот, завышаем LP на “худшем” маршруте до loopback CE2 на Y-ASBR5, тем самым сделав его лучшим.
Выполним первый вариант и зададим LP ниже 100 на Y-ASBR4. Для этого создадим ACL где будем матчить этот префикс и роут мапу, в которой укажем что сделать с этим префиксом:

Импровизированная схема с занижением LP на Y-ASBR4 для Lo CE2
Y-ASBR4 (IOS-XE):
access-list 1 permit 222.222.222.222
route-map TEST-LP permit 1
 match ip address 1
 set local-preference 90
route-map TEST-LP permit 10
Навешиваем на BGP пира (B-ASBR4) на IN:
router bgp 100
 address-family ipv4
  neighbor 96.4.44.44 route-map TEST-LP in

Проверим что изменилось:

Y-ASBR4#show bgp | b 222.222.222.222/32
 *>i 222.222.222.222/32
                       96.5.55.55               0    100      0 200 2 ?
 *                    96.4.44.44                     90      0 200 2 ?

Y-ASBR4#show bgp 222.222.222.222/32    
BGP routing table entry for 222.222.222.222/32, version 57
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  200 2
    96.5.55.55 (metric 3) from 3.3.3.3 (3.3.3.3)
      Origin incomplete, metric 0, localpref 100, valid, internal, best

      Originator: 5.5.5.5, Cluster list: 3.3.3.3
      rx pathid: 0x0, tx pathid: 0x0
  Refresh Epoch 1
  200 2
    96.4.44.44 from 96.4.44.44 (44.44.44.44)
      Origin incomplete, localpref 90, valid, external
      rx pathid: 0, tx pathid: 0

Y-RR3#show bgp 222.222.222.222/32
BGP routing table entry for 222.222.222.222/32, version 44
Paths: (1 available, best #1, table default)
  Path advertised to update-groups:
     1         
  Refresh Epoch 1
  200 2, (Received from a RR-client)
    96.5.55.55 (metric 2) from 5.5.5.5 (5.5.5.5)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

Видим, что лучший маршрут изменился, а на рефлекторе и вовсе путь через Y-ASBR4 пропал, как говорил ранее в теме с weight, это связано с тем, что Y-ASBR4, увидев что его маршрут стал не бестовым, отправил рефлектору update с withdraw лупбеком CE2, тем самым “отозвав” его.
Проверим трейс с CE1 и обратим внимание, что хоп #4 изменился, теперь трафик идет через Y-ASBR5<>B-ASBR5:

CE1#traceroute 222.222.222.222 source lo0 num
Type escape sequence to abort.
Tracing the route to 222.222.222.222
VRF info: (vrf in name/id, vrf out name/id)
  1 111.100.111.5 6 msec 2 msec 1 msec
  2 100.3.2.1 [AS 100] 24 msec 4 msec 5 msec
  3 100.3.5.2 [AS 100] 372 msec 9 msec 18 msec
  4 96.5.55.55 [AS 100] 83 msec 13 msec 9 msec
  5 200.33.55.1 [AS 200] 150 msec 16 msec 12 msec
  6 200.33.11.2 [AS 200] 44 msec 17 msec 16 msec
  7 222.200.222.2 [AS 200] 27 msec *  18 msec

Сделаем похожее и со стороны AS200. Маршрут до CE1 от B-ASBR4 является лучшим:

RP/0/0/CPU0:B-RR3#show bgp | b 111.111.111.111
Thu Mar 31 18:38:29.309 UTC
*>i111.111.111.111/32 96.4.44.4                     100      0 100 1 ?
* i                   96.5.55.5                     100      0 100 1 ?

RP/0/0/CPU0:B-RR3#show bgp  111.111.111.111/32   
Thu Mar 31 18:38:35.968 UTC
BGP routing table entry for 111.111.111.111/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 35          35
Last Modified: Mar 31 18:36:28.213 for 00:02:07
Paths: (2 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.2 0.3 
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.2 0.3 
  100 1, (Received from a RR-client)
    96.4.44.4 (metric 20) from 44.44.44.44 (44.44.44.44)
      Origin incomplete, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 25
  Path #2: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.3 
  100 1, (Received from a RR-client)
    96.5.55.5 (metric 20) from 55.55.55.55 (55.55.55.55)
      Origin incomplete, localpref 100, valid, internal, add-path
      Received Path ID 0, Local Path ID 2, version 35

RP/0/0/CPU0:B-ASBR4#show bgp | b 111.111.111.111
Thu Mar 31 18:43:55.446 UTC
* i111.111.111.111/32 96.5.55.5                     100      0 100 1 ?
*>                    96.4.44.4                              0 100 1 ?

RP/0/0/CPU0:B-ASBR4#show bgp 111.111.111.111/32
Thu Mar 31 18:44:03.156 UTC
BGP routing table entry for 111.111.111.111/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 33          33
Last Modified: Mar 31 18:36:25.027 for 00:07:38
Paths: (2 available, best #2)
  Advertised to peers (in unique update groups):
    33.33.33.33     
  Path #1: Received by speaker 0
  Not advertised to any peer
  100 1
    96.5.55.5 (metric 30) from 33.33.33.33 (55.55.55.55)
      Origin incomplete, localpref 100, valid, internal
      Received Path ID 3, Local Path ID 0, version 0
      Originator: 55.55.55.55, Cluster list: 33.33.33.33
  Path #2: Received by speaker 0
  Advertised to peers (in unique update groups):
    33.33.33.33     
  100 1
    96.4.44.4 from 96.4.44.4 (4.4.4.4)
      Origin incomplete, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 33
      Origin-AS validity: not-found

Сделаем так же как и в AS100, занизим LP на префикс, получаемый от Y-ASBR4 на B-ASBR4:

B-ASBR4(IOS-XR):
RP/0/0/CPU0:B-ASBR4(config)#show com ch dif
Thu Mar 31 18:49:33.303 UTC
Building configuration...
!! IOS XR Configuration 6.0.1
   !
+  route-policy LP
+    if destination in (111.111.111.111/32) then
+      set local-preference 90
+    endif
+    pass
+  end-policy
   router bgp 200
    neighbor 96.4.44.4
     address-family ipv4 unicast
<-    route-policy PASS in
+>    route-policy LP in
     !
    !
   !
end

Проверим bgp таблицу на B-ASBR4 и B-RR3:

RP/0/0/CPU0:B-ASBR4# show bgp | b 111.111.111.111/32 
Thu Mar 31 18:54:50.261 UTC
*>i111.111.111.111/32 96.5.55.5                     100      0 100 1 ?
*                     96.4.44.4                      90      0 100 1 ?

RP/0/0/CPU0:B-ASBR4#show bgp 111.111.111.111/32    
Thu Mar 31 18:55:13.760 UTC
BGP routing table entry for 111.111.111.111/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 62          62
Last Modified: Mar 31 18:49:50.027 for 00:05:23
Paths: (2 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  100 1
    96.5.55.5 (metric 30) from 33.33.33.33 (55.55.55.55)
      Origin incomplete, localpref 100, valid, internal, best, group-best
      Received Path ID 1, Local Path ID 1, version 62
      Originator: 55.55.55.55, Cluster list: 33.33.33.33
  Path #2: Received by speaker 0
  Not advertised to any peer
  100 1
    96.4.44.4 from 96.4.44.4 (4.4.4.4)
      Origin incomplete, localpref 90, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: not-found


RP/0/0/CPU0:B-RR3#show bgp 111.111.111.111/32
Thu Mar 31 18:55:43.458 UTC
BGP routing table entry for 111.111.111.111/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                113         113
Last Modified: Mar 31 18:49:50.213 for 00:05:53
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.3 
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.3 
  100 1, (Received from a RR-client)
    96.5.55.5 (metric 20) from 55.55.55.55 (55.55.55.55)
      Origin incomplete, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 113

На рефлекторе, как и ранее, исчез маршрут с B-ASBR4, т.к. B-ASBR4 отозвал его, сообщим об этом рефлектору:

Internet Protocol Version 4, Src: 44.44.44.44, Dst: 33.33.33.33
Transmission Control Protocol, Src Port: 39382, Dst Port: 179, Seq: 39, Ack: 39, Len: 28
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 28
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 5
    Withdrawn Routes
        111.111.111.111/32
            Withdrawn route prefix length: 32
            Withdrawn prefix: 111.111.111.111
    Total Path Attribute Length: 0

Ну и проверка трейсом со стороны CE2:

CE2#traceroute 111.111.111.111 source  lo0 num
Type escape sequence to abort.
Tracing the route to 111.111.111.111
VRF info: (vrf in name/id, vrf out name/id)
  1 222.200.222.5 16 msec 2 msec 1 msec
  2 200.33.22.1 [AS 200] 19 msec 4 msec 4 msec
  3 200.33.55.2 [AS 200] 47 msec 8 msec 8 msec
  4 96.5.55.5 [AS 200] 412 msec 10 msec 9 msec
  5 100.3.5.1 [AS 100] 48 msec 14 msec 14 msec
  6 100.3.1.2 [AS 100] 23 msec 17 msec 32 msec
  7 111.100.111.2 [AS 100] 17 msec *  21 msec

Originate Locally

Тут считаются предпочтительней маршруты которые оригинируются локально, т.е. это те которые заданы через network, aggregate-address или redistribute. У таких маршрутов в bgp таблице next hop будет 0.0.0.0
Для примера посмотрим на p2p (point-to-point) линк между Y-PE1 и CE1 (111.100.111.0/30). У Y-PE1 два маршрута до него, т.к. один это его локальный – директный (directly), а второй от CE1. 

Y-PE1#show bgp | b 111.100.111.0/30      
 *   111.100.111.0/30 111.100.111.2            0             0 1 ?
 *>                   0.0.0.0                  0         32768 ?

На Y-PE1 в таблицу BGP маршрут до 111.100.111.0/30 попал из-за redistribution:

Y-PE1#sh run | i bgp|ipv4|redis
router bgp 100
 bgp log-neighbor-changes
 address-family ipv4
  redistribute connected

AS-Path

Данный атрибут, как мы помним, является well-know mandatory и соответственно обязательно должен быть во всех update сообщениях. Чем короче as-path, тем предпочтительней маршрут.
Есть возможность ухудшить конкретный маршрут путём увеличения длины as хопов в as-path и называется это – as prepend. Best practices, да и в принципе правильным все таки будет считаться это, увеличения as-path путем “клонирования” собственной же AS.
Попробуем сделать так, что бы трафик от CE1 к CE2 шел через Y-PE2, путем навешивания препендов на Y-PE1.
Сейчас это выглядит так:

CE1#show bgp | b 222.222.222.222/32
 *   222.222.222.222/32
                       111.100.111.5                          0 100 200 2 ?
 *>                   111.100.111.1                          0 100 200 2 ?

CE1#traceroute 222.222.222.222 so lo0 num
Type escape sequence to abort.
Tracing the route to 222.222.222.222
VRF info: (vrf in name/id, vrf out name/id)
  1 111.100.111.1 12 msec 2 msec 2 msec
  2 100.3.1.1 [AS 100] 9 msec 5 msec 4 msec
  3 100.3.4.2 [AS 100] 11 msec 7 msec 6 msec
  4 96.4.44.44 [AS 100] 17 msec 10 msec 8 msec
  5 200.33.44.1 [AS 200] 18 msec 10 msec 11 msec
  6 200.33.11.2 [AS 200] 21 msec 13 msec 13 msec
  7 222.200.222.2 [AS 200] 24 msec *  45 msec

На Y-PE1 в этот раз создадим префикс лист, а не ACL (разницы нет, просто для разнообразия), далее в route-map через prefix-list установим препенды. Хочу заметить в значение as-path prepend мы указываем кол-во AS, которые добавятся к нашей же AS, к уже анонсируемой.

Импровизированная схема с as-prepend
Y-PE1 (ISO-XE):
ip prefix-list as-prepend  permit 222.222.222.222/32
!
route-map as-prepend permit 10
 match ip address prefix-list as-prepend
 set as-path prepend 100 100
!
route-map as-prepend permit 20
!
router bgp 100
 address-family ipv4
  neighbor 111.100.111.2 route-map as-prepend out
!

Проверим таблицу bgp и трассировку на CE1:

CE1#show bgp  | b 222.222.222.222/32
 *>  222.222.222.222/32
                       111.100.111.5                          0 100 200 2 ?
 *                    111.100.111.1                          0 100 100 100 200 2 ?

CE1#traceroute 222.222.222.222 so lo0 num
Type escape sequence to abort.
Tracing the route to 222.222.222.222
VRF info: (vrf in name/id, vrf out name/id)
  1 111.100.111.5 12 msec 2 msec 2 msec
  2 100.3.2.1 [AS 100] 8 msec 4 msec 5 msec
  3 100.3.4.2 [AS 100] 12 msec 9 msec 7 msec
  4 96.4.44.44 [AS 100] 18 msec 9 msec 8 msec
  5 200.33.44.1 [AS 200] 21 msec 10 msec 29 msec
  6 200.33.11.2 [AS 200] 27 msec 15 msec 14 msec
  7 222.200.222.2 [AS 200] 15 msec *  81 msec

Хочу обратить внимание, когда мы на IOS-XE смотрим отдаваемые маршруты соседу, то мы видим анонсы, которые еще не были обработаны, мы можем это судить как минимум по отсутствующей AS100 в as-path. 

Y-PE1#$pv4 un neighbors  111.100.111.2 advertised-routes | b 222.222.222     
 *>i 222.222.222.222/32
                       96.4.44.44               0    100      0 200 2 ?

Total number of prefixes 24

Теперь проделаем тоже самое и со стороны AS200 (IOS-XR), аналогично на B-PE1.
До применения as-prepend это выглядит так:

CE2#show bgp | b 111.111.111
 *   111.111.111.111/32
                       222.200.222.5                          0 200 100 1 ?
 *>                   222.200.222.1                          0 200 100 1 ?

CE2#traceroute 111.111.111.111 source  lo0 nu
Type escape sequence to abort.
Tracing the route to 111.111.111.111
VRF info: (vrf in name/id, vrf out name/id)
  1 222.200.222.1 11 msec 2 msec 1 msec
  2 200.33.11.1 [AS 200] 11 msec 5 msec 4 msec
  3 200.33.44.2 [AS 200] 14 msec 8 msec 9 msec
  4 96.4.44.4 [AS 200] 15 msec 11 msec 10 msec
  5 100.3.4.1 [AS 100] 34 msec 12 msec 14 msec
  6 100.3.1.2 [AS 100] 28 msec 23 msec 17 msec
  7 111.100.111.2 [AS 100] 21 msec *  25 msec
RP/0/0/CPU0:B-PE1(config-bgp-nbr-af)#show com ch dif
Thu Mar 31 20:48:30.934 UTC
Building configuration...
!! IOS XR Configuration 6.0.1
   !
+  route-policy as-prepend
+    if destination in (111.111.111.111/32) then
+      prepend as-path 200 2
+    endif
+    pass
+  end-policy
   router bgp 200
    neighbor 222.200.222.2
     address-family ipv4 unicast
<-    route-policy PASS out
+>    route-policy as-prepend out
     !
    !
   !
end

Проверим на CE2:

CE2#show bgp | b 111.111.111
 *>  111.111.111.111/32
                       222.200.222.5                          0 200 100 1 ?
 *                    222.200.222.1                          0 200 200 200 100 1 ?

CE2#traceroute 111.111.111.111 source  lo0 nu
Type escape sequence to abort.
Tracing the route to 111.111.111.111
VRF info: (vrf in name/id, vrf out name/id)
  1 222.200.222.5 14 msec 2 msec 1 msec
  2 200.33.22.1 [AS 200] 14 msec 5 msec 4 msec
  3 200.33.44.2 [AS 200] 15 msec 8 msec 6 msec
  4 96.4.44.4 [AS 200] 19 msec 9 msec 13 msec
  5 100.3.4.1 [AS 100] 22 msec 15 msec 14 msec
  6 100.3.1.2 [AS 100] 21 msec 16 msec 16 msec
  7 111.100.111.2 [AS 100] 24 msec *  32 msec

На IOS-XR, в отличие от ISO-XE, когда просматриваем отдаваемые маршруты, мы уже видим наши препенды:

RP/0/0/CPU0:B-PE1#show bgp neighbor 222.200.222.2 advertised-routes  | i 111.1$
Thu Mar 31 20:49:55.928 UTC
111.111.111.111/32 222.200.222.1   33.33.33.33     200 200 200 100 1?

Origin Code

На сегодняшний день, мы можем встретить только два Origin Code – i (IGP) и ? (Incomplete). Как упоминалось ранее i лучше чем ?. Сейчас в лабе все bgp маршруты имеют ? т.к. на всех роутерах прописана redistribute в bgp . С помощью route-map/route-policy объявим маршрут как i.
Сделать это можно как в политике на out так и на input, сначала попробуем на out.
Выполнять это будем на Y-ASBR5 и B-ASBR5, т.к. от них маршруты до CE1/2 проигрывают из-за router-id.
На Y-ASBR5 сделаем так, чтоб префикс 111.111.111.111/32 отдаваемый в сторону B-ASBR5 стал с origin code – i:

Изменение origin code для Lo CE1 на Y-ASBR5
Y-ASBR5 (IOS-XE):
ip prefix-list origin seq 5 permit 111.111.111.111/32
!
route-map origin permit 10
 match ip address prefix-list origin
 set origin igp
!
route-map origin permit 20
!
router bgp 100
 address-family ipv4
  neighbor 96.5.55.55 route-map origin out

Теперь у B-ASBR4 маршрут станет хуже, а от B-ASBR5 лучше:

RP/0/0/CPU0:B-ASBR4#show bgp | b 111.111.111.111/32
Thu Mar 31 21:57:02.223 UTC
*>i111.111.111.111/32 96.5.55.5                     100      0 100 1 i
*                     96.4.44.4                              0 100 1 ?

Даже CE2 будет об этом знать

CE2# show bgp 111.111.111.111
BGP routing table entry for 111.111.111.111/32, version 28
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  200 100 1
    222.200.222.5 from 222.200.222.5 (22.22.22.22)
      Origin IGP, localpref 100, valid, external, best
  Refresh Epoch 1
  200 200 200 100 1
    222.200.222.1 from 222.200.222.1 (11.11.11.11)
      Origin IGP, localpref 100, valid, external

CE2#traceroute 111.111.111.111 source  lo0 num
Type escape sequence to abort.
Tracing the route to 111.111.111.111
VRF info: (vrf in name/id, vrf out name/id)
  1 222.200.222.5 9 msec 1 msec 1 msec
  2 200.33.22.1 [AS 200] 13 msec 5 msec 4 msec
  3 200.33.55.2 [AS 200] 14 msec 8 msec 6 msec
  4 96.5.55.5 [AS 200] 13 msec 9 msec 9 msec
  5 100.3.5.1 [AS 100] 25 msec 14 msec 14 msec
  6 100.3.1.2 [AS 100] 21 msec 17 msec 15 msec
  7 111.100.111.2 [AS 100] 21 msec *  46 msec

Хочу подметить и напомнить себе же, что для AS100 (Y-Site) все без изменений:

Y-RR3#show bgp | b 111.111.111
 * ia111.111.111.111/32
                       2.2.2.2                  0    100      0 1 ?
 *>i                  1.1.1.1                  0    100      0 1 ?

Теперь проделаем то же самое и на AS200, только теперь для лупбек адреса CE2 (222.222.222.222/32).

Изменение origin code для Lo CE2 на B-ASBR5

Посмотрим как выглядит маршрут на AS100 до применения:

Y-RR3#show bgp | b 222.222.222.222 
* ia222.222.222.222/32
                       96.5.55.55               0    100      0 200 2 ?
 *>i                  96.4.44.44               0    100      0 200 2 ?

Применим конфигурацию на B-ASBR5

B-ASBR5 (IOS-XR):
RP/0/0/CPU0:B-ASBR5(config)#show com ch dif
Thu Mar 31 22:01:51.433 UTC
Building configuration...
!! IOS XR Configuration 6.0.1
   !
+  route-policy origin-code
+    if destination in (222.222.222.222/32) then
+      set origin igp
+    endif
+    pass
+  end-policy
   router bgp 200
    neighbor 96.5.55.5
     address-family ipv4 unicast
<-    route-policy PASS out
+>    route-policy origin-code out
     !
    !
   !
end

Теперь, аналогично как с AS200, на Y-ASBR4 маршрут от eBGP соседа стал хуже:

Y-ASBR4#show bgp | b 222.222.222.222/32
 *>i 222.222.222.222/32
                       96.5.55.55               0    100      0 200 2 i
 *                    96.4.44.44                             0 200 2 ?

Y-ASBR5#show bgp | b 222.222.222.222/32
 *>  222.222.222.222/32
                       96.5.55.55                             0 200 2 i

Y-RR3#show bgp | b 222.222.222.222
 *>i 222.222.222.222/32
                       96.5.55.55               0    100      0 200 2 i

CE1#traceroute 222.222.222.222 source  111.111.111.111 nu
Type escape sequence to abort.
Tracing the route to 222.222.222.222
VRF info: (vrf in name/id, vrf out name/id)
  1 111.100.111.5 5 msec 2 msec 2 msec
  2 100.3.2.1 [AS 100] 14 msec 5 msec 4 msec
  3 100.3.5.2 [AS 100] 16 msec 14 msec 7 msec
  4 96.5.55.55 [AS 100] 19 msec 9 msec 8 msec
  5 200.33.55.1 [AS 200] 20 msec 18 msec 12 msec
  6 200.33.11.2 [AS 200] 38 msec 21 msec 13 msec
  7 222.200.222.2 [AS 200] 19 msec *  74 msec

Теперь попробуем сделать это для политик на IN. На Y-ASBR5 для префикса 222.222.222.222/32 изменим ему атрибут origin code, до того как он “упадет” в control-plane, c ? на i:

Y-ASBR5 (IOS-XE):
!
ip prefix-list origin seq 5 permit 222.222.222.222/32
!
route-map origin permit 10
 match ip address prefix-list origin
 set origin igp
!
route-map origin permit 20
!
router bgp 100
 address-family ipv4
  neighbor 96.5.55.55 route-map origin in
!

Результат тот же, лучшим путь до CE2 стал через Y-ASBR5<>B-ASBR5:

Y-ASBR5#     show bgp | b 222.222.222
 *>  222.222.222.222/32
                       96.5.55.55                             0 200 2 i

Y-ASBR4#show bgp | b 222.222.222
 *>i 222.222.222.222/32
                       96.5.55.55               0    100      0 200 2 i
 *                    96.4.44.44                             0 200 2 ?

CE1#traceroute 222.222.222.222 source  lo0 num
Type escape sequence to abort.
Tracing the route to 222.222.222.222
VRF info: (vrf in name/id, vrf out name/id)
  1 111.100.111.5 5 msec 2 msec 1 msec
  2 100.3.2.1 [AS 100] 10 msec 4 msec 8 msec
  3 100.3.5.2 [AS 100] 11 msec 10 msec 7 msec
  4 96.5.55.55 [AS 100] 20 msec 9 msec 8 msec
  5 200.33.55.1 [AS 200] 41 msec 13 msec 11 msec
  6 200.33.11.2 [AS 200] 26 msec 16 msec 14 msec
  7 222.200.222.2 [AS 200] 17 msec *  39 msec

Попробуем аналогично сделать это и для IOS-XR.
На B-ASBR5 для Lo CE1, получаемого от Y-ASBR5, изменим origin code с ? на i, тем самым сделав его лучшим: 

B-ASBR5(IOS-XR):
RP/0/0/CPU0:B-ASBR5(config)#show com ch dif
Sun Apr 10 17:52:04.235 UTC
Building configuration...
!! IOS XR Configuration 6.0.1
   !
+  route-policy Origin
+    if destination in (111.111.111.111/32) then
+      set origin igp
+    endif
+    pass
+  end-policy
   router bgp 200
    neighbor 96.5.55.5
     address-family ipv4 unicast
<-    route-policy PASS in
+>    route-policy Origin in
     !
    !
   !
end

Проверим изменения:

RP/0/0/CPU0:B-ASBR5(config)#do show bgp 111.111.111.111/32
Sun Apr 10 17:53:07.740 UTC
BGP routing table entry for 111.111.111.111/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 34          34
Last Modified: Apr 10 17:52:34.211 for 00:00:33
Paths: (1 available, best #1)
  Advertised to peers (in unique update groups):
    33.33.33.33     
  Path #1: Received by speaker 0
  Advertised to peers (in unique update groups):
    33.33.33.33     
  100 1
    96.5.55.5 from 96.5.55.5 (5.5.5.5)
      Origin IGP, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 34
      Origin-AS validity: not-found

RP/0/0/CPU0:B-RR3#show bgp | b 111.111.111.111/32
Sun Apr 10 17:53:16.720 UTC
*>i111.111.111.111/32 96.5.55.5                     100      0 100 1 i
*>i200.33.11.0/30     11.11.11.11              0    100      0 ?

CE2#traceroute 111.111.111.111 source lo0 nu
Type escape sequence to abort.
Tracing the route to 111.111.111.111
VRF info: (vrf in name/id, vrf out name/id)
  1 222.200.222.5 8 msec 2 msec 2 msec
  2 200.33.22.1 [AS 200] 16 msec 4 msec 4 msec
  3 200.33.55.2 [AS 200] 37 msec 6 msec 8 msec
  4 96.5.55.5 [AS 200] 358 msec 10 msec 10 msec
  5 100.3.5.1 [AS 100] 52 msec 12 msec 12 msec
  6 100.3.1.2 [AS 100] 28 msec 21 msec 20 msec
  7 111.100.111.2 [AS 100] 38 msec *  27 msec

MED

Попробуем с помощью MED повлиять на входящий трафик в AS1 (111.111.111.111/32).
Сейчас к Lo CE1 ходим через стык CE1<>Y-PE1:

Y-RR3#show bgp | b 111.111
 * ia111.111.111.111/32
                       2.2.2.2                  0    100      0 1 ?
 *>i                  1.1.1.1                  0    100      0 1 ?

CE2#traceroute 111.111.111.111 source lo0 n
Type escape sequence to abort.
Tracing the route to 111.111.111.111
VRF info: (vrf in name/id, vrf out name/id)
  1 222.200.222.5 9 msec 1 msec 1 msec
  2 200.33.22.1 [AS 200] 16 msec 4 msec 5 msec
  3 200.33.44.2 [AS 200] 17 msec 7 msec 7 msec
  4 96.4.44.4 [AS 200] 19 msec 10 msec 8 msec
  5 100.3.4.1 [AS 100] 33 msec 15 msec 15 msec
  6 100.3.1.2 [AS 100] 27 msec 15 msec 16 msec
  7 111.100.111.2 [AS 100] 28 msec *  25 msec

Сделаем так, чтобы трафик к Lo CE1 ходил через CE1<>Y-PE2. Для этого на CE1 создаем route-map, в которой выставим MED 10 для нашего Lo адреса и повесим на OUT, в сторону Y-PE1, тем самым ухудшим маршрут через этот стык:

Хождение трафика к Lo CE1 после увеличения MED
CE1(IOS-XE):
CE1#sh run | s route-map
route-map MED permit 10
 match ip address prefix-list MED
 set metric 10
route-map MED permit 20
!
router bgp 1
 address-family ipv4
  neighbor 111.100.111.1 route-map MED out

Проверяем на Y-PE1 и видим, что на eBGP (прямом) стыке, появилась метрика 10, тем самым ухудшив этот путь.

Y-PE1#show bgp | b 111.111
 *>i 111.111.111.111/32
                       2.2.2.2                  0    100      0 1 ?
 *                    111.100.111.2           10             0 1 ?

Y-RR3#show bgp | b 111.111 
 *>i 111.111.111.111/32
                       2.2.2.2                  0    100      0 1 ?

CE2#traceroute 111.111.111.111 source lo0 numeric 
Type escape sequence to abort.
Tracing the route to 111.111.111.111
VRF info: (vrf in name/id, vrf out name/id)
  1 222.200.222.5 9 msec 1 msec 1 msec
  2 200.33.22.1 [AS 200] 12 msec 4 msec 4 msec
  3 200.33.44.2 [AS 200] 19 msec 23 msec 9 msec
  4 96.4.44.4 [AS 200] 14 msec 10 msec 10 msec
  5 100.3.4.1 [AS 100] 24 msec 12 msec 12 msec
  6 100.3.2.2 [AS 100] 343 msec 15 msec 14 msec
  7 111.100.111.6 [AS 100] 17 msec *  32 msec

Сделаем пример для IOS-XR, в этот раз ухудшим маршрут к CE1 на стыке B-PE2<>CE2.

Хождение трафика от CE2 к CE1 после увеличения MED

Конфиг на IOS-XR практически идентичный, только фраза metric изменяется на med:

B-PE2(IOS-XR):
RP/0/0/CPU0:B-PE2(config)#show com ch dif
Sun Apr 10 19:57:00.881 UTC
Building configuration...
!! IOS XR Configuration 6.0.1
   !
+  prefix-set MED
+    111.111.111.111/32
+  end-set
+  route-policy MED
+    if destination in MED then
+      set med 15
+    endif
+    pass
+  end-policy
   router bgp 200
    neighbor 222.200.222.6
     address-family ipv4 unicast
<-    route-policy PASS out
+>    route-policy MED out
     !
    !
   !
end

Проверим на CE2 маршрут к CE1:

До завышения MED:
CE2#show bgp | b 111.111.111
 *>  111.111.111.111/32
                       222.200.222.5                          0 200 100 1 ?
 *                    222.200.222.1                          0 200 100 1 ?
После завышения MED:
CE2#show bgp | b 111.111.111
 *   111.111.111.111/32
                       222.200.222.5           15             0 200 100 1 ?
 *>                   222.200.222.1                          0 200 100 1 ?

CE2#show bgp 111.111.111.111/32
BGP routing table entry for 111.111.111.111/32, version 33
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  200 100 1
    222.200.222.5 from 222.200.222.5 (22.22.22.22)
      Origin incomplete, metric 15, localpref 100, valid, external
  Refresh Epoch 1
  200 100 1
    222.200.222.1 from 222.200.222.1 (11.11.11.11)
      Origin incomplete, localpref 100, valid, external, best

Path Type

Как уже говорилось ранее, маршрут от eBGP пира является предпочтительней чем от iBGP. Можно рассмотреть на примере Lo CE2 (222.222.222.222/32). У B-PE2 два маршрута до Lo CE2 и выбран лучшим имеено eBGP:

RP/0/0/CPU0:B-PE2#show bgp | b 222.222.222
Sun Apr 10 21:27:44.208 UTC
* i222.222.222.222/32 11.11.11.11              0    100      0 2 ?
*>                    222.200.222.6            0             0 2 ?

Processed 25 prefixes, 40 paths

RP/0/0/CPU0:B-PE2#show bgp 222.222.222.222/32
Sun Apr 10 21:28:14.076 UTC
BGP routing table entry for 222.222.222.222/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 10          10
Last Modified: Apr 10 16:52:42.936 for 04:35:31
Paths: (2 available, best #2)
  Advertised to peers (in unique update groups):
    33.33.33.33     
  Path #1: Received by speaker 0
  Not advertised to any peer
  2
    11.11.11.11 (metric 30) from 33.33.33.33 (11.11.11.11)
      Origin incomplete, metric 0, localpref 100, valid, internal

      Received Path ID 1, Local Path ID 0, version 0
      Originator: 11.11.11.11, Cluster list: 33.33.33.33
  Path #2: Received by speaker 0
  Advertised to peers (in unique update groups):
    33.33.33.33     
  2
    222.200.222.6 from 222.200.222.6 (222.222.222.222)
      Origin incomplete, metric 0, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 10
      Origin-AS validity: not-found

Добавить комментарий

Ваш адрес email не будет опубликован.