<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[BGP отражает маршруты к одноранговому узлу, от которого он их получил.]]></title><description><![CDATA[<p dir="auto">Здравствуйте, Давайте начнем с топологии, чтобы было легче понять, о чем я говорю: ![Topology.png] Между всеми соседними маршрутизаторами, за исключением R1 и R4, существуют сеансы BGP. Эти маршрутизаторы не имеют настроенного пиринга, и это сделано специально. При выполнении<br />
лабораторных работ по BGP я столкнулся со следующей проблемой: я объявил маршрут по умолчанию от маршрутизатора R1 и R4 на основе соседства. Маршрутизатор R2 повторно объявляет маршрут по умолчанию, полученный от R1, для R3, но не получает маршрут по умолчанию, исходящий от R4. Под «не получает» я имею в виду, что он не появляется в таблице BGP.<br />
Я попробовал выполнить жесткий сброс пиринга BGP между R2 и R3, и это сработало на некоторое время, но через несколько мгновений маршрут по умолчанию от R4 снова был удален из таблицы BGP R2 из-за получения обратно маршрута по умолчанию от собственного AS R2. По сути, маршрутизатор R3 отразил маршрут по умолчанию, который он узнал от R2, обратно в R2, что привело к удалению маршрута по умолчанию, исходящего из R4, из таблицы BGP, несмотря на то, что это другой маршрут с другим AS-Path. Вот соответствующие фрагменты конфигурации маршрутизаторов: R1:<br />
interface GigabitEthernet0/0 ip address 10.0.0.1 255.255.255.252 duplex auto speed auto media-type rj45<br />
!<br />
interface GigabitEthernet0/2 ip address 150.1.1.1 255.255.255.0 duplex auto speed auto media-type rj45<br />
!<br />
router bgp 1 bgp router-id 1.1.1.1 bgp log-neighbor-changes neighbor 10.0.0.2 remote-as 2 neighbor 10.0.0.2 default-originate R2:<br />
interface GigabitEthernet0/0 ip address 10.0.0.2 255.255.255.252 duplex auto speed auto media-type rj45<br />
!<br />
interface GigabitEthernet0/1 ip address 10.0.0.9 255.255.255.252 duplex auto speed auto media-type rj45<br />
!<br />
interface GigabitEthernet0/2 ip address 150.2.2.2 255.255.255.0 duplex auto speed auto media-type rj45<br />
!<br />
router bgp 2 bgp router-id 2.2.2.2 bgp log-neighbor-changes network 150.2.2.0 mask 255.255.255.0 neighbor 10.0.0.1 remote-as 1 neighbor 10.0.0.10 remote-as 3 R3:<br />
interface GigabitEthernet0/0 ip address 10.0.0.10 255.255.255.252 duplex auto speed auto media-type rj45<br />
!<br />
interface GigabitEthernet0/1 ip address 10.0.0.13 255.255.255.252 duplex auto speed auto media-type rj45<br />
!<br />
interface GigabitEthernet0/2 ip address 150.3.3.3 255.255.255.0 duplex auto speed auto media-type rj45<br />
!<br />
router bgp 3 bgp router-id 3.3.3.3 bgp log-neighbor-changes network 150.3.3.0 mask 255.255.255.0 neighbor 10.0.0.9 remote-as 2 neighbor 10.0.0.14 remote-as 1 R4:<br />
interface GigabitEthernet0/0 ip address 10.0.0.14 255.255.255.252 duplex auto speed auto media-type rj45<br />
!<br />
interface GigabitEthernet0/2 ip address 150.1.1.4 255.255.255.0 duplex auto speed auto media-type rj45<br />
!<br />
route-map DEFAULT-SECONDARY permit 10 set as-path prepend 1 1<br />
router bgp 1 bgp log-neighbor-changes neighbor 10.0.0.13 remote-as 3 neighbor 10.0.0.13 default-originate route-map DEFAULT-SECONDARY Вот состояние таблицы BGP на каждом устройстве перед очисткой сеанса BGP между R2 и R3: R1# sh ip bgp<br />
BGP table version is 7, local router ID is 1.1.1.1<br />
Status codes: s suppressed, d damped, h history, * valid, &gt; 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, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete<br />
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path 0.0.0.0 0.0.0.0 0 i *&gt; 150.2.2.0/24 10.0.0.2 0 0 2 i *&gt; 150.3.3.0/24 10.0.0.2 0 2 3 i R2#sh ip bgp<br />
BGP table version is 6, local router ID is 2.2.2.2<br />
Status codes: s suppressed, d damped, h history, * valid, &gt; 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, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete<br />
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *&gt; 0.0.0.0 10.0.0.1 0 1 i - here you can see that there is only the route received from R1 but no route from R4 *&gt; 150.2.2.0/24 0.0.0.0 0 32768 i *&gt; 150.3.3.0/24 10.0.0.10 0 0 3 i R3#sh ip bgp<br />
BGP table version is 8, local router ID is 3.3.3.3<br />
Status codes: s suppressed, d damped, h history, * valid, &gt; 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, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete<br />
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *&gt; 0.0.0.0 10.0.0.9 0 2 1 i * 10.0.0.14 0 1 1 1 i *&gt; 150.2.2.0/24 10.0.0.9 0 0 2 i *&gt; 150.3.3.0/24 0.0.0.0 0 32768 i R4# sh ip bgp<br />
BGP table version is 7, local router ID is 150.1.1.4<br />
Status codes: s suppressed, d damped, h history, * valid, &gt; 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, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete<br />
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path 0.0.0.0 0.0.0.0 0 i *&gt; 150.2.2.0/24 10.0.0.13 0 3 2 i *&gt; 150.3.3.0/24 10.0.0.13 0 0 3 i Вот состояние таблицы BGP на R2 вскоре после жесткого сброса сеанса между R2 и R3: R2#sh ip bgp<br />
BGP table version is 6, local router ID is 2.2.2.2<br />
Status codes: s suppressed, d damped, h history, * valid, &gt; 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, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete<br />
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 0.0.0.0 10.0.0.10 0 3 1 1 1 i - the route has appeared *&gt; 10.0.0.1 0 1 i *&gt; 150.2.2.0/24 0.0.0.0 0 32768 i *&gt; 150.3.3.0/24 10.0.0.10 0 0 3 i Вот сообщения отладки обновления BGP, которые появились после сброса сеанса, непосредственно перед удалением маршрута из R4: *Jan 31 09:51:09.936: BGP(0): 10.0.0.10 rcv UPDATE w/ attr: nexthop 10.0.0.10, origin i, originator 0.0.0.0, merged path 3 2 1, AS_PATH , community , extended community , SSA attribute *Jan 31 09:51:09.937: BGPSSA ssacount is 0, Tunnel attribute *Jan 31 09:51:09.937: Tunnel encap type: 0, encap size: 0<br />
*Jan 31 09:51:09.937: BGP(0): 10.0.0.10 rcv UPDATE about 0.0.0.0/0 -- DENIED due to: AS-PATH contains our own AS;<br />
*Jan 31 09:51:09.937: BGP(0): 10.0.0.10 rcv UPDATE w/ attr: nexthop 10.0.0.10, origin i, originator 0.0.0.0, merged path 3 2, AS_PATH , community , extended community , SSA attribute *Jan 31 09:51:09.938: BGPSSA ssacount is 0, Tunnel attribute R2#<br />
*Jan 31 09:51:09.938: Tunnel encap type: 0, encap size: 0<br />
*Jan 31 09:51:09.938: BGP(0): 10.0.0.10 rcv UPDATE about 150.2.2.0/24 -- DENIED due to: AS-PATH contains our own AS;<br />
*Jan 31 09:51:10.369: BGP(0): (base) 10.0.0.1 send UPDATE (format) 150.3.3.0/24, next 10.0.0.2, metric 0, path 3 Я заметил, что R3 рекламирует маршрут по умолчанию, который он получил от R2, обратно R2: R3#sh ip bgp neighbors 10.0.0.9 advertised-routes BGP table version is 8, local router ID is 3.3.3.3<br />
Status codes: s suppressed, d damped, h history, * valid, &gt; 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, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete<br />
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *&gt; 0.0.0.0 10.0.0.9 0 2 1 i *&gt; 150.2.2.0/24 10.0.0.9 0 0 2 i *&gt; 150.3.3.0/24 0.0.0.0 0 32768 i Total number of prefixes 3 Мой вопрос: является ли это правильным поведением BGP, и если да, то почему оно работает именно так? Или это программная ошибка? Моя версия IOS — Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), версия 15.9(3)M8, RELEASE SOFTWARE (fc1).<br />
Заранее спасибо,<br />
Алекс</p>
<p dir="auto"><img src="/forum/uploads/files/cisco/22ff6b0c98b77b4f331564c051748fd91a1fa5b8.png" alt="" class=" img-fluid img-markdown" /></p>
]]></description><link>https://sla247.ru/forum/topic/882/bgp-отражает-маршруты-к-одноранговому-узлу-от-которого-он-их-получил</link><generator>RSS for Node</generator><lastBuildDate>Fri, 15 May 2026 17:58:34 GMT</lastBuildDate><atom:link href="https://sla247.ru/forum/topic/882.rss" rel="self" type="application/rss+xml"/><pubDate>Fri, 13 Feb 2026 19:57:37 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to BGP отражает маршруты к одноранговому узлу, от которого он их получил. on Fri, 13 Feb 2026 19:57:43 GMT]]></title><description><![CDATA[<p dir="auto">Привет, <a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/a-dreszler" aria-label="Profile: a-dreszler">@<bdi>a-dreszler</bdi></a><br />
Я хотел бы прокомментировать причину, по которой R3 отправляет обновление для маршрута по умолчанию обратно в R2, даже несмотря на то, что лучший путь BGP для маршрута по умолчанию в R3 проходит через R2. 1. Можете ли вы подтвердить, что R3 не имеет исходящих фильтров для пиринга с R2 и R4? 2. Повторите сценарий, выполнив следующие действия на<br />
R3<br />
: настройте две фиктивные карты маршрутов (например,<br />
route-map TO-R2 permit any<br />
и<br />
route-map TO-R4 permit any<br />
), примените первую карту маршрутов в исходящем направлении к R2, а вторую карту маршрутов — в исходящем направлении к R4, подождите некоторое время, выполните на R3 команду<br />
show bgp ipv4 unicast update-group<br />
и подтвердите, что R2 и R4 находятся в отдельных группах обновлений, выполните команду<br />
show bgp ipv4 unicast neighbors x.x.x.x advertised-routes<br />
и замените x.x.x.x адресами пиринга R2 и R4, вы больше не должны видеть, что R3 рекламирует маршрут по умолчанию обратно к R2. Спасибо, Кристиан.</p>
]]></description><link>https://sla247.ru/forum/post/5649</link><guid isPermaLink="true">https://sla247.ru/forum/post/5649</guid><dc:creator><![CDATA[Cristian Matei]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:57:43 GMT</pubDate></item><item><title><![CDATA[Reply to BGP отражает маршруты к одноранговому узлу, от которого он их получил. on Fri, 13 Feb 2026 19:57:42 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте.<br />
Приношу извинения, я уже писал ранее, но неправильно прочитал ваш пост, поэтому удалил его, однако с тех пор другие пользователи уже ответили.<br />
Хочу только добавить, что поведение, которое вы наблюдаете,<br />
ТАКЖЕ<br />
связано с тем, что вы добавляете префикс из R4. Если бы вы не добавляли префикс в R4, я бы сказал, что и R2, и R3 имели бы двойные записи в своем bgp rib для полученных маршрутов по умолчанию. Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.<br />
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.<br />
С уважением,<br />
Пол</p>
]]></description><link>https://sla247.ru/forum/post/5648</link><guid isPermaLink="true">https://sla247.ru/forum/post/5648</guid><dc:creator><![CDATA[paul driver]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:57:42 GMT</pubDate></item><item><title><![CDATA[Reply to BGP отражает маршруты к одноранговому узлу, от которого он их получил. on Fri, 13 Feb 2026 19:57:41 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте<br />
[, <a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/a-dreszler" aria-label="Profile: a-dreszler">@<bdi>a-dreszler</bdi></a>] Нормальное и ожидаемое поведение... это следствие нормального выбора оптимального пути + правил объявления eBGP + предотвращения циклов... как объяснил г-н Риттер. С уважением<br />
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.</p>
]]></description><link>https://sla247.ru/forum/post/5647</link><guid isPermaLink="true">https://sla247.ru/forum/post/5647</guid><dc:creator><![CDATA[M02@rt37]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:57:41 GMT</pubDate></item><item><title><![CDATA[Reply to BGP отражает маршруты к одноранговому узлу, от которого он их получил. on Fri, 13 Feb 2026 19:57:40 GMT]]></title><description><![CDATA[<p dir="auto">Спасибо,<br />
<a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/a-dreszler" aria-label="Profile: a-dreszler">@<bdi>a-dreszler</bdi></a>,<br />
и спасибо за отзыв. С уважением,<br />
Гарольд Риттер, CCIE #4168 (EI, SP)</p>
]]></description><link>https://sla247.ru/forum/post/5646</link><guid isPermaLink="true">https://sla247.ru/forum/post/5646</guid><dc:creator><![CDATA[Harold Ritter]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:57:40 GMT</pubDate></item><item><title><![CDATA[Reply to BGP отражает маршруты к одноранговому узлу, от которого он их получил. on Fri, 13 Feb 2026 19:57:39 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте. Спасибо за ответ, я думаю, что теперь я все понял. Я упустил тот факт, что BGP рекламирует только лучший путь.<br />
С уважением,</p>
]]></description><link>https://sla247.ru/forum/post/5645</link><guid isPermaLink="true">https://sla247.ru/forum/post/5645</guid><dc:creator><![CDATA[a-dreszler]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:57:39 GMT</pubDate></item><item><title><![CDATA[Reply to BGP отражает маршруты к одноранговому узлу, от которого он их получил. on Fri, 13 Feb 2026 19:57:38 GMT]]></title><description><![CDATA[<p dir="auto">Привет,<br />
<a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/a-dreszler" aria-label="Profile: a-dreszler">@<bdi>a-dreszler</bdi></a><br />
, Важно помнить, что BGP рекламирует только лучший путь для каждого префикса. R3 видит лучший путь от R2, поскольку путь, полученный от R4, имеет более длинный AS Path. Для R3 нормальным поведением является рекламирование лучшего пути всем своим соседям, включая R2. R2 просто игнорирует это обновление, поскольку его собственный номер AS присутствует в AS Path. Это называется обнаружением петли AS Path. С уважением,<br />
Гарольд Риттер, CCIE #4168 (EI, SP)</p>
]]></description><link>https://sla247.ru/forum/post/5644</link><guid isPermaLink="true">https://sla247.ru/forum/post/5644</guid><dc:creator><![CDATA[Harold Ritter]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:57:38 GMT</pubDate></item></channel></rss>