Атрибут Next-Hop и iBGP

Схема сети

Когда мы попытаемся пропинговать маршрут, который мы получили по iBGP, то это не получится. Всё дело в том, что BGP не меняет атрибут Nex-Hop при передачи маршрута iBGP-соседу. Т.е. выходит так, что роутеру, который не является бордером AS передаётся маршрут с Next-Hop IP-адресом, о котором этот роутер никак не может узнать. Что с этим можно мделать? Для этого есть несколько путей, но, по факту, самые адекватные - это либо на eBGP пире прописать атрибут Next-Hop Self, который позволит при передаче маршрута iBGP-соседу менять атрибут Next-Hop, либо добавить маршрут до p2p eBGP-сети в IGP (например, через OSPF, указав линк как passive).

Указывается Next-Hop Self довольно просто:

[e-mail].M34# edit policy-options policy-statement next-hop-self   

[edit policy-options policy-statement next-hop-self]
[e-mail].M34# set from protocol bgp route-type external 

[edit policy-options policy-statement next-hop-self]
[e-mail].M34# set then next-hop self                       

[edit policy-options policy-statement next-hop-self]
[e-mail].M34# top                                          

[e-mail].M34# set protocols bgp group intra-Sub-AS export next-hop-self    

Тут видно, что мы экспортируем маршруты полученные только от external BGP к iBGP-пирам с параметром next-hop-self.

Посмотрим что происходило до коммита вышеуказанной конфигурации на M9:

[e-mail].M9# run show route receive-protocol bgp 10.1.1.200 table inet.0       

inet.0: 43 destinations, 58 routes (43 active, 0 holddown, 4 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  8.1.0.0/16              8.0.0.2                      100        8000 8001 I
* 100.0.0.0/24            8.0.0.2                      100        8000 I
  101.0.0.0/24            8.0.0.2                      100        8000 8001 I

[e-mail].M9# run show route receive-protocol bgp 10.1.1.200 table inet.0 all                

inet.0: 43 destinations, 58 routes (43 active, 0 holddown, 4 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  8.0.0.0/16              8.0.0.2                      100        8000 I
  8.1.0.0/16              8.0.0.2                      100        8000 8001 I
  9.1.0.0/16              8.0.0.2                      100        8000 8001 9001 I
* 100.0.0.0/24            8.0.0.2                      100        8000 I
  101.0.0.0/24            8.0.0.2                      100        8000 8001 I
  
[e-mail].M9# run show route protocol bgp 8.0.0.0 all 

inet.0: 43 destinations, 58 routes (43 active, 0 holddown, 4 hidden)
+ = Active Route, - = Last Active, * = Both

8.0.0.0/16         *[BGP/170] 01:36:23, localpref 100, from 10.0.0.1
                      AS path: (65002) 9001 8001 8000 I, validation-state: unverified
                    > to 10.0.0.3 via ae3.0
                    [BGP/170] 01:36:23, localpref 100
                      AS path: (65002) 9001 8001 8000 I, validation-state: unverified
                    > to 10.0.0.3 via ae3.0
                    [BGP/170] 01:36:23, localpref 100, from 10.1.1.200
                      AS path: 8000 I, validation-state: unverified
                      Unusable
                    [BGP/170] 04:23:05, localpref 100, from 10.1.1.201
                      AS path: 8000 I, validation-state: unverified
                      Unusable

Т.е. тут видно, что мы хоть и принимаем маршруты от RT.MSK.M34, но они скрываются и не используются. Почему? Потому что для IP-адреса, указанного в атрибуте Next-Hop происходит Recursive Lookup в таблице маршрутизации. Соответственно, для 8.0.0.2 в таблице IGP-маршрутов ничего не найдено, поэтому эти маршруты не используются и попадают в спрятанные. Более подробная информация тут.

После применения изменений выбирается маршрут с кратчайшим AS-Path, а атрибут next-hop меняется на LoopBack бордера:

[e-mail].M9# run show route 8.0.0.0                                 

inet.0: 43 destinations, 56 routes (43 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

8.0.0.0/16         *[BGP/170] 00:00:21, localpref 100, from 10.1.1.200
                      AS path: 8000 I, validation-state: unverified
                    > to 10.1.1.2 via ae0.0
                    
[e-mail].M9# run show route receive-protocol bgp 10.1.1.200 

inet.0: 43 destinations, 56 routes (43 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 8.0.0.0/16              10.1.1.200                   100        8000 I
  8.1.0.0/16              10.1.1.200                   100        8000 8001 I
  9.1.0.0/16              10.1.1.200                   100        8000 8001 9001 I
* 100.0.0.0/24            10.1.1.200                   100        8000 I
  101.0.0.0/24            10.1.1.200                   100        8000 8001 I

Соответственно далее указываем и применяем эту политику для всех eBGP-пиров:

protocols {
    bgp {
        group intra-Sub-AS {
            export next-hop-self;
        }
    }
}
policy-options {
    policy-statement next-hop-self {
        from {
            protocol bgp;               
            route-type external;
        }
        then {
            next-hop self;
        }
    }
}