Проектирование сети L2–L3 в центре обработки данных с использованием eBGP

[satish.txt1]

Друзья, Мы используем EVPN/VxLAN в нашей структуре, и теперь пришло время для масштабирования, поэтому я подумываю запустить демон FRR на всех серверах Linux и соединить их с листьевым коммутатором TOR с помощью eBGP и создать полноценную сеть L3 от конца до конца. Это позволит мне удалить LACP из коммутаторов и создать простую и масштабируемую сеть. У меня есть несколько вопросов, связанных с проектированием ASN и пирингом BGP. Я провожу лабораторные работы для POC, и вот что я пытаюсь сделать: у меня есть маршрутизатор R1, коммутатор Cisco Nexus и два хоста, на которых запущен демон FRR для работы BGP. Я пытаюсь использовать локальный адрес ipv6 для простоты, чтобы мне не нужно было назначать интерфейс на каждом пире из-за масштабирования. В будущем у нас может быть более 1000 хостов в центре обработки данных, и не стоит назначать каждый интерфейсный IP-адрес для пиринга. ![Screenshot 2025-11-15 at 23.20.52.png] Конфигурация R1 (Cisco Nexus версии 10.x) interface Ethernet1/1
no switchport
ipv6 address use-link-local-only
no shutdown interface Ethernet1/2
no switchport
ipv6 address use-link-local-only
no shutdown interface loopback0
ip address 10.0.0.100/32 router bgp 65000
router-id 10.0.0.100
address-family ipv4 unicast
!
neighbor Ethernet1/1
remote-as 65001
address-family ipv4 unicast
disable-peer-as-check
!
neighbor Ethernet1/2
remote-as 65001
address-family ipv4 unicast
disable-peer-as-check Конфигурация Host1 frr frr version 8.1
frr defaults traditional
hostname Host1
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens2 no ipv6 nd suppress-ra
exit
!
interface lo ip address 10.0.0.1/32
exit
!
router bgp 65001 bgp router-id 10.0.0.1 no bgp ebgp-requires-policy neighbor ens2 interface remote-as 65000 ! address-family ipv4 unicast network 10.0.0.1/32 redistribute connected neighbor ens2 allowas-in exit-address-family ! Конфигурация Host2 frr frr version 8.1
frr defaults traditional
hostname Host2
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
interface ens2 no ipv6 nd suppress-ra
exit
!
interface lo ip address 10.0.0.3/32
exit
!
router bgp 65001 bgp router-id 10.0.0.3 no bgp ebgp-requires-policy neighbor ens2 interface remote-as 65000 ! address-family ipv4 unicast network 10.0.0.3/32 redistribute connected neighbor ens2 allowas-in exit-address-family ! Статус пиринга bgp Host1 Host1# show ip bgp summary IPv4 Unicast Summary (VRF default):
BGP router identifier 10.0.0.1, local AS number 65001 vrf-id 0
BGP table version 28
RIB entries 3, using 552 bytes of memory
Peers 1, using 723 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
ens2 4 65000 799 797 0 0 0 00:45:29 1 2 N/A Total number of neighbors 1 Маршрутизация BGP хоста 1 Host1# show ip bgp
BGP table version is 28, local router ID is 10.0.0.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.1/32 0.0.0.0 0 32768 i

• 0.0.0.0 0 32768 ?
  > 10.0.0.3/32 ens2 0 65000 65001 i Displayed 2 routes and 3 total paths Таблица маршрутизации ip Host1 Host1# show ip route
  Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure C> 10.0.0.1/32 is directly connected, lo, 1d11h43m
  B>* 10.0.0.3/32 [20/0] via fe80::5009:8bff:fea9:1b08, ens2, weight 1, 00:39:27 Host1# show bgp ipv4 10.0.0.3
  BGP routing table entry for 10.0.0.3/32, version 28
  Paths: (1 available, best #1, table default) Advertised to non peer-group peers: ens2 65000 65001 fe80::5009:8bff:fea9:1b08 from ens2 (10.0.0.100) (fe80::5009:8bff:fea9:1b08) (used) Origin IGP, valid, external, best (First path received) Last update: Sun Nov 16 03:58:53 2025 Таблица маршрутизации R1 R1# show ip route
  IP Route Table for VRF "default"
  '*' denotes best ucast next-hop
  '**' denotes best mcast next-hop
  '[x/y]' denotes [preference/metric]
  '%<string>' in via output denotes VRF <string> 10.0.0.1/32, ubest/mbest: 1/0 *via fe80::5054:ff:fe19:7db0%default, Eth1/1, [20/0], 01:02:20, bgp-65000, e
  xternal, tag 65001
  10.0.0.3/32, ubest/mbest: 1/0 *via fe80::5054:ff:fe10:930d%default, Eth1/2, [20/0], 00:54:53, bgp-65000, e
  xternal, tag 65001
  10.0.0.100/32, ubest/mbest: 2/0, attached *via 10.0.0.100, Lo0, [0/0], 01:15:26, local *via 10.0.0.100, Lo0, [0/0], 01:15:26, direct Вы можете видеть, что Host1 показывает 10.0.0.3 в качестве следующего прыжка к ipv6-адресу (адрес локальной связи). Из-за этого я не могу выполнить ping 10.0.0.3, потому что ipv4 требует ipv4-адрес следующего прыжка, а не ipv6, так как в этом случае я могу решить свою проблему? Если я использую ipv4 peering, то это создаст проблему автоматизации и масштабирования. Как другие люди используют BGP от начала до конца без сложностей?</string></string>

[satish.txt1]

Я решил проблему, или, скорее, нашел недостающий кусочек пазла. Проблема заключалась не в
next-hop-self,
а в
ip forward
. После добавления ip forward на оба интерфейса R1 проблема была решена, и я могу выполнять ping между host1 и host2. interface Ethernet1/1 no switchport ip forward ipv6 address use-link-local-only no shutdown interface Ethernet1/2 no switchport ip forward ipv6 address use-link-local-only no shutdown Требования к пересылке IP (в NX-OS) В некоторых версиях NX-OS, чтобы RFC 5549 работал
без
назначения IPv4-адреса на интерфейсе, необходимо включить ip forward на интерфейсе. Согласно руководству по настройке BGP в NX-OS:
«Чтобы использовать RFC 5549, необходимо настроить как минимум один IPv4-адрес. Если вы не хотите настраивать IPv4-адрес, необходимо включить функцию IP forward, чтобы использовать RFC 5549».
Cisco
Без ip forward плоскость данных может не пересылать пакеты должным образом, поскольку коммутатор может отбрасывать пакеты IPv4, даже если BGP устанавливает маршрут.

[M02@rt37]

Здравствуйте
[, @satish.txt1] Спасибо за интересный случай и подробности. Вы используете пиринг через IP v6, и в этом сценарии следующие прыжки IPv4 не переписываются автоматически, на мой взгляд. Поэтому для принудительного использования маршрутизируемого следующего прыжка IP v4 необходимо использовать команду
next-hop-self
. -- добавьте эту команду в семейство адресов IPv4 для каждого соседа eBGP, обращенного к хосту... С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

[M02@rt37]

Большое спасибо за отзыв,
@satish.txt1 С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените .ı|ı.ı|ı.

[satish.txt1]

Я разместил полное решение в своем блоге для тех, кто ищет решение: https://medium.com/@satishdotpatel/build-layer-3-datacenter-using-bgp-62eaccc0a421