# Атрибут Next-Hop и iBGP ![Схема сети](/files/-MVI5qqD3qgCt8SW_-DE) Когда мы попытаемся пропинговать маршрут, который мы получили по iBGP, то это не получится. Всё дело в том, что BGP не меняет атрибут Nex-Hop при передачи маршрута iBGP-соседу. Т.е. выходит так, что роутеру, который не является бордером AS передаётся маршрут с Next-Hop IP-адресом, о котором этот роутер никак не может узнать. Что с этим можно мделать? Для этого есть несколько путей, но, по факту, самые адекватные - это либо на eBGP пире прописать атрибут Next-Hop Self, который позволит при передаче маршрута iBGP-соседу менять атрибут Next-Hop, либо добавить маршрут до p2p eBGP-сети в IGP (например, через OSPF, указав линк как passive). Указывается Next-Hop Self довольно просто: ``` root@RT.MSK.M34# edit policy-options policy-statement next-hop-self [edit policy-options policy-statement next-hop-self] root@RT.MSK.M34# set from protocol bgp route-type external [edit policy-options policy-statement next-hop-self] root@RT.MSK.M34# set then next-hop self [edit policy-options policy-statement next-hop-self] root@RT.MSK.M34# top root@RT.MSK.M34# set protocols bgp group intra-Sub-AS export next-hop-self ``` Тут видно, что мы экспортируем маршруты полученные только от external BGP к iBGP-пирам с параметром next-hop-self. Посмотрим что происходило до коммита вышеуказанной конфигурации на M9: ``` root@RT.MSK.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 root@RT.MSK.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 root@RT.MSK.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-маршрутов ничего не найдено, поэтому эти маршруты не используются и попадают в спрятанные. Более подробная информация [тут](https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-overview.html#id-bgp-route-resolution-overview). После применения изменений выбирается маршрут с кратчайшим AS-Path, а атрибут next-hop меняется на LoopBack бордера: ``` root@RT.MSK.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 root@RT.MSK.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; } } } ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://netlabs.gitbook.io/juniper/5-bgp/ibgp/atribut-next-hop-i-ibgp.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.