sirmax Posted May 13 Доброго дня Есть роутер FRR который я пытаюсь настроить в качестве External Router для Tangsten Fabric (это такая себе SDN) Со стороны FRR настройки такие debug vrf ! vrf vrf-tf-public ip route 0.0.0.0/0 192.168.22.254 management exit-vrf ! ! router bgp 65000 bgp router-id 192.168.32.101 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 10.80.3.55 remote-as 65000 neighbor 10.80.3.56 remote-as 65000 neighbor 10.80.3.57 remote-as 65000 neighbor 10.80.3.58 remote-as 65000 ! ! address-family ipv4 vpn neighbor 192.168.32.102 activate neighbor 10.80.3.55 activate neighbor 10.80.3.55 soft-reconfiguration inbound neighbor 10.80.3.55 route-map SET-NEX-THOP-TF out neighbor 10.80.3.56 activate neighbor 10.80.3.56 soft-reconfiguration inbound neighbor 10.80.3.56 route-map SET-NEX-THOP-TF out neighbor 10.80.3.57 activate neighbor 10.80.3.57 soft-reconfiguration inbound neighbor 10.80.3.57 route-map SET-NEX-THOP-TF out neighbor 10.80.3.58 activate neighbor 10.80.3.58 soft-reconfiguration inbound neighbor 10.80.3.58 route-map SET-NEX-THOP-TF out exit-address-family exit ! router bgp 65000 vrf vrf-tf-public ! address-family ipv4 unicast redistribute kernel redistribute static label vpn export auto rd vpn export 65000:10001 rt vpn both 65000:10001 export vpn import vpn exit-address-family Тут поясню > ip route 0.0.0.0/0 192.168.22.254 management Это маршрут из VRF в интерфейс с именем management > neighbor 10.80.3.55 remote-as 65000 Этот и прочие пиры - это control nodes там поднят BGP Роут-мап нужен что б назначать свой адрес (в сторону интерфейса по которому должен идти трафик, сессия поднята через другой интерфейс) route-map SET-NEX-THOP-TF permit 10 set ip next-hop 10.80.6.253 exit Для примера возмем один адрес 10.170.6.201 который используется как floating виртуальной машиной frr1# show bgp ipv4 vpn 10.170.6.201/32 BGP routing table entry for 10.80.6.54:3:10.170.6.201/32, version 3 not allocated Paths: (2 available, best #1) Not advertised to any peer Local 10.80.6.54 from 10.80.3.55 (10.80.3.55) Origin incomplete, metric 100, localpref 200, valid, internal, multipath, best (Router ID) Extended Community: RT:65000:10001 RT:65000:8000004 ET:2 ET:13 Rmac:fe:35:6b:ee:38:2c UNK:128, 113 Remote label: 52 Last update: Tue May 13 14:37:42 2025 Local 10.80.6.54 from 10.80.3.57 (10.80.3.57) Origin incomplete, metric 100, localpref 200, valid, internal, multipath Extended Community: RT:65000:10001 RT:65000:8000004 ET:2 ET:13 Rmac:fe:35:6b:ee:38:2c UNK:128, 113 Remote label: 52 Last update: Tue May 13 14:37:42 2025 Насколько я могу судить RT:65000:10001 правильный и я ожидаю что этот маршрут окажется в таблице маршрутизации Однако в таблице маршрутизации я ничего не вижу frr1# show ip route vrf vrf-tf-public Codes: K - kernel route, C - connected, L - local, 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, t - Table-Direct, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure VRF vrf-tf-public: K>* 0.0.0.0/0 [0/0] via 192.168.22.254, management (vrf default), weight 1, 03:19:56 C>* 10.80.6.0/24 is directly connected, tenant, weight 1, 03:19:56 L>* 10.80.6.253/32 is directly connected, tenant, weight 1, 03:19:56 Из того что прповерил (по колесам постучал) : VRF существует ip vrf Name Table ----------------------- vrf-tf-public 10001 В нем есть интерфейс (с именем tenant) и некстхоп 10.80.6.54 через него доступен Мак-вдреса видны, более того после того как на SDN уехал анонс дефолта я вижу трафик (пинг с ВМки) 18:01:36.454186 fe:35:6b:ee:38:2c > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 126: 10.80.6.54 > 10.80.6.253: GREv0, proto MPLS unicast (0x8847), length 92: MPLS (label 82, exp 0, [S], ttl 61) 10.170.6.201 > 10.10.10.10: ICMP echo request, id 36754, seq 11962, length 64 Такая инкапсуляция - MPLS over GRE это в данном случае ожидаемое поведение Для декапсуляции используется такая конструкция - по сути тунели на каждую ноду где могут быть ВМки (трафик идет не с тех нод с которыми поднята сессия) 20: gre-hp-dl380g6@tenant: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/gre 10.80.6.253 peer 10.80.6.52 promiscuity 0 allmulti 0 minmtu 68 maxmtu 65511 gre remote 10.80.6.52 local 10.80.6.253 dev tenant ttl 128 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 21: gre-dell-r710@tenant: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/gre 10.80.6.253 peer 10.80.6.54 promiscuity 0 allmulti 0 minmtu 68 maxmtu 65511 gre remote 10.80.6.54 local 10.80.6.253 dev tenant ttl 128 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 Я вижу что трафик успешно уходит и возвращается в VRF "внешний" интерфейс FRR в Global tcpdump -n -i management port ! 22 18:04:23.370666 IP 10.170.6.201 > 10.10.10.10: ICMP echo request, id 36754, seq 12125, length 64 18:04:23.370997 IP 10.10.10.10 > 10.170.6.201: ICMP echo reply, id 36754, seq 12125, length 64 Интерфейс VRF tcpdump -n -i vrf-tf-public request, id 36754, seq 12466, length 64 18:10:12.572723 IP 10.170.6.201 > 10.10.10.10: ICMP echo request, id 36754, seq 12466, length 64 18:10:12.573037 IP 10.10.10.10 > 10.170.6.201: ICMP echo reply, id 36754, seq 12466, length 64 но на этом все - так как маршрута нет то дальше идти ему некуда Куда блин копать? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Morty Posted May 13 (edited) 1 час назад, sirmax сказал: Доброго дня Есть роутер FRR который я пытаюсь настроить в качестве External Router для Tangsten Fabric (это такая себе SDN) Со стороны FRR настройки такие debug vrf ! vrf vrf-tf-public ip route 0.0.0.0/0 192.168.22.254 management exit-vrf ! ! router bgp 65000 bgp router-id 192.168.32.101 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 10.80.3.55 remote-as 65000 neighbor 10.80.3.56 remote-as 65000 neighbor 10.80.3.57 remote-as 65000 neighbor 10.80.3.58 remote-as 65000 ! ! address-family ipv4 vpn neighbor 192.168.32.102 activate neighbor 10.80.3.55 activate neighbor 10.80.3.55 soft-reconfiguration inbound neighbor 10.80.3.55 route-map SET-NEX-THOP-TF out neighbor 10.80.3.56 activate neighbor 10.80.3.56 soft-reconfiguration inbound neighbor 10.80.3.56 route-map SET-NEX-THOP-TF out neighbor 10.80.3.57 activate neighbor 10.80.3.57 soft-reconfiguration inbound neighbor 10.80.3.57 route-map SET-NEX-THOP-TF out neighbor 10.80.3.58 activate neighbor 10.80.3.58 soft-reconfiguration inbound neighbor 10.80.3.58 route-map SET-NEX-THOP-TF out exit-address-family exit ! router bgp 65000 vrf vrf-tf-public ! address-family ipv4 unicast redistribute kernel redistribute static label vpn export auto rd vpn export 65000:10001 rt vpn both 65000:10001 export vpn import vpn exit-address-family Тут поясню > ip route 0.0.0.0/0 192.168.22.254 management Это маршрут из VRF в интерфейс с именем management > neighbor 10.80.3.55 remote-as 65000 Этот и прочие пиры - это control nodes там поднят BGP Роут-мап нужен что б назначать свой адрес (в сторону интерфейса по которому должен идти трафик, сессия поднята через другой интерфейс) route-map SET-NEX-THOP-TF permit 10 set ip next-hop 10.80.6.253 exit Для примера возмем один адрес 10.170.6.201 который используется как floating виртуальной машиной frr1# show bgp ipv4 vpn 10.170.6.201/32 BGP routing table entry for 10.80.6.54:3:10.170.6.201/32, version 3 not allocated Paths: (2 available, best #1) Not advertised to any peer Local 10.80.6.54 from 10.80.3.55 (10.80.3.55) Origin incomplete, metric 100, localpref 200, valid, internal, multipath, best (Router ID) Extended Community: RT:65000:10001 RT:65000:8000004 ET:2 ET:13 Rmac:fe:35:6b:ee:38:2c UNK:128, 113 Remote label: 52 Last update: Tue May 13 14:37:42 2025 Local 10.80.6.54 from 10.80.3.57 (10.80.3.57) Origin incomplete, metric 100, localpref 200, valid, internal, multipath Extended Community: RT:65000:10001 RT:65000:8000004 ET:2 ET:13 Rmac:fe:35:6b:ee:38:2c UNK:128, 113 Remote label: 52 Last update: Tue May 13 14:37:42 2025 Насколько я могу судить RT:65000:10001 правильный и я ожидаю что этот маршрут окажется в таблице маршрутизации Однако в таблице маршрутизации я ничего не вижу frr1# show ip route vrf vrf-tf-public Codes: K - kernel route, C - connected, L - local, 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, t - Table-Direct, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure VRF vrf-tf-public: K>* 0.0.0.0/0 [0/0] via 192.168.22.254, management (vrf default), weight 1, 03:19:56 C>* 10.80.6.0/24 is directly connected, tenant, weight 1, 03:19:56 L>* 10.80.6.253/32 is directly connected, tenant, weight 1, 03:19:56 Из того что прповерил (по колесам постучал) : VRF существует ip vrf Name Table ----------------------- vrf-tf-public 10001 В нем есть интерфейс (с именем tenant) и некстхоп 10.80.6.54 через него доступен Мак-вдреса видны, более того после того как на SDN уехал анонс дефолта я вижу трафик (пинг с ВМки) 18:01:36.454186 fe:35:6b:ee:38:2c > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 126: 10.80.6.54 > 10.80.6.253: GREv0, proto MPLS unicast (0x8847), length 92: MPLS (label 82, exp 0, [S], ttl 61) 10.170.6.201 > 10.10.10.10: ICMP echo request, id 36754, seq 11962, length 64 Такая инкапсуляция - MPLS over GRE это в данном случае ожидаемое поведение Для декапсуляции используется такая конструкция - по сути тунели на каждую ноду где могут быть ВМки (трафик идет не с тех нод с которыми поднята сессия) 20: gre-hp-dl380g6@tenant: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/gre 10.80.6.253 peer 10.80.6.52 promiscuity 0 allmulti 0 minmtu 68 maxmtu 65511 gre remote 10.80.6.52 local 10.80.6.253 dev tenant ttl 128 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 21: gre-dell-r710@tenant: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/gre 10.80.6.253 peer 10.80.6.54 promiscuity 0 allmulti 0 minmtu 68 maxmtu 65511 gre remote 10.80.6.54 local 10.80.6.253 dev tenant ttl 128 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 Я вижу что трафик успешно уходит и возвращается в VRF "внешний" интерфейс FRR в Global tcpdump -n -i management port ! 22 18:04:23.370666 IP 10.170.6.201 > 10.10.10.10: ICMP echo request, id 36754, seq 12125, length 64 18:04:23.370997 IP 10.10.10.10 > 10.170.6.201: ICMP echo reply, id 36754, seq 12125, length 64 Интерфейс VRF tcpdump -n -i vrf-tf-public request, id 36754, seq 12466, length 64 18:10:12.572723 IP 10.170.6.201 > 10.10.10.10: ICMP echo request, id 36754, seq 12466, length 64 18:10:12.573037 IP 10.10.10.10 > 10.170.6.201: ICMP echo reply, id 36754, seq 12466, length 64 но на этом все - так как маршрута нет то дальше идти ему некуда Куда блин копать? Если правильно понял, то вам надо получить маршрут из vrf-tf-public в default vrf. Вроде так должно работать: router bgp 65000 address-family ipv4 unicast rt vpn import 65000:10001 import vpn ! router bgp 65000 vrf vrf-tf-public address-family ipv4 unicast redistribute kernel redistribute static rd vpn export 65000:10001 rt vpn export 65000:10001 export vpn Edited May 13 by Morty Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted May 13 7 минут назад, Morty сказал: Если правильно понял, то вам надо получить маршрут Нет, мне надо получить маршрут в vrf-tf-public но установленный в таблицу роутинга сейчас же он есть в bgp но не установлен в fib Route leaking пока не нужен, это отдельная задача Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted May 14 Продолжая это ебучее веселое исследование Попробовал удалить все что связано с VRF и попробовать в Global Скрытый текст router bgp 65000 bgp router-id 192.168.32.101 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 10.80.3.55 remote-as 65000 neighbor 10.80.3.56 remote-as 65000 neighbor 10.80.3.57 remote-as 65000 neighbor 10.80.3.58 remote-as 65000 ! address-family ipv4 unicast redistribute kernel redistribute static label vpn export auto rd vpn export 65000:10001 rt vpn both 65000:10001 export vpn import vpn exit-address-family ! address-family ipv4 vpn neighbor 10.80.3.55 activate neighbor 10.80.3.55 soft-reconfiguration inbound neighbor 10.80.3.55 route-map SET-NEX-THOP-TF out neighbor 10.80.3.56 activate neighbor 10.80.3.56 soft-reconfiguration inbound neighbor 10.80.3.56 route-map SET-NEX-THOP-TF out neighbor 10.80.3.57 activate neighbor 10.80.3.57 soft-reconfiguration inbound neighbor 10.80.3.57 route-map SET-NEX-THOP-TF out neighbor 10.80.3.58 activate neighbor 10.80.3.58 soft-reconfiguration inbound neighbor 10.80.3.58 route-map SET-NEX-THOP-TF out exit-address-family exit То маршруты заехали frr1# show ip route ... C>* 10.80.3.0/24 is directly connected, lcm-k8s, weight 1, 00:04:26 L>* 10.80.3.253/32 is directly connected, lcm-k8s, weight 1, 00:04:26 C>* 10.80.6.0/24 is directly connected, tenant, weight 1, 00:04:26 L>* 10.80.6.253/32 is directly connected, tenant, weight 1, 00:04:26 B>* 10.170.6.201/32 [200/100] via 10.80.6.54, tenant, label 52, weight 1, 00:03:55 B>* 10.170.6.202/32 [200/100] via 10.80.6.52, tenant, label 42, weight 1, 00:04:10 B>* 10.170.6.203/32 [200/100] via 10.80.6.54, tenant, label 62, weight 1, 00:03:55 C>* 192.168.22.0/24 [0/100] is directly connected, management, weight 1, 00:04:26 L>* 192.168.22.121/32 is directly connected, management, weight 1, 00:04:26 K>* 192.168.22.254/32 [0/100] is directly connected, management, weight 1, 00:04:26 K>* 192.168.32.1/32 [0/100] via 192.168.22.254, management, src 192.168.22.121, weight 1, 00:04:26 K>* 192.168.32.2/32 [0/100] via 192.168.22.254, management, src 192.168.22.121, weight 1, 00:04:26 L * 192.168.32.101/32 is directly connected, loopback0, weight 1, 00:04:26 C>* 192.168.32.101/32 is directly connected, loopback0, weight 1, 00:04:26 L * 192.168.32.201/32 is directly connected, loopback1, weight 1, 00:04:26 C>* 192.168.32.201/32 is directly connected, loopback1, weight 1, 00:04:26 O 192.168.40.0/30 [110/10] is directly connected, frr, weight 1, 00:04:25 C>* 192.168.40.0/30 is directly connected, frr, weight 1, 00:04:26 L>* 192.168.40.1/32 is directly connected, frr, weight 1, 00:04:26 root@frr1:~# ip ro s 10.80.3.0/24 dev lcm-k8s proto kernel scope link src 10.80.3.253 10.80.6.0/24 dev tenant proto kernel scope link src 10.80.6.253 10.170.6.201 nhid 22 encap mpls 52 via 10.80.6.54 dev tenant proto bgp metric 20 10.170.6.202 nhid 19 encap mpls 42 via 10.80.6.52 dev tenant proto bgp metric 20 10.170.6.203 nhid 23 encap mpls 62 via 10.80.6.54 dev tenant proto bgp metric 20 192.168.22.0/24 dev management proto kernel scope link src 192.168.22.121 metric 100 192.168.22.254 dev management proto dhcp scope link src 192.168.22.121 metric 100 192.168.32.1 via 192.168.22.254 dev management proto dhcp src 192.168.22.121 metric 100 192.168.32.2 via 192.168.22.254 dev management proto dhcp src 192.168.22.121 metric 100 192.168.40.0/30 dev frr proto kernel scope link src 192.168.40.1 Если добавить тунели для декапсуляции/инкапсуляции то работает как ожидалось - трафик начал ходить в обе стороны 10.80.3.0/24 dev lcm-k8s proto kernel scope link src 10.80.3.253 10.80.6.0/24 dev tenant proto kernel scope link src 10.80.6.253 10.170.6.201 nhid 37 encap mpls 52 via 192.168.1.1 dev gre-dell-r710 proto bgp metric 20 10.170.6.202 nhid 40 encap mpls 42 via 192.168.1.2 dev gre-hp-dl380g6 proto bgp metric 20 192.168.22.0/24 dev management proto kernel scope link src 192.168.22.121 metric 100 192.168.22.254 dev management proto dhcp scope link src 192.168.22.121 metric 100 192.168.32.1 via 192.168.22.254 dev management proto dhcp src 192.168.22.121 metric 100 192.168.32.2 via 192.168.22.254 dev management proto dhcp src 192.168.22.121 metric 100 192.168.40.0/30 dev frr proto kernel scope link src 192.168.40.1 Что видно в дампе с правильной (двойной, мать его!) инкапсуляцией 08:35:29.316036 fe:35:6b:ee:38:2c > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 126: 10.80.6.54 > 10.80.6.253: GREv0, proto MPLS unicast (0x8847), length 92: MPLS (label 80, exp 0, [S], ttl 61) 10.170.6.201 > 10.10.10.10: ICMP echo request, id 19377, seq 2, length 64 08:35:29.316546 00:99:00:00:00:01 > fe:35:6b:ee:38:2c, ethertype IPv4 (0x0800), length 126: 10.80.6.253 > 10.80.6.54: GREv0, proto MPLS unicast (0x8847), length 92: MPLS (label 52, exp 0, [S], ttl 63) 10.10.10.10 > 10.170.6.201: ICMP echo reply, id 19377, seq 2, length 64 Осталось выяснить что не так с VRF 🙂 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
