Skip to content

bgpd: fix import of evpn routes into vni/vrf/esi after nexthop update#10372

Open
louis-6wind wants to merge 2 commits into
FRRouting:masterfrom
louis-6wind:evpn-nht-update
Open

bgpd: fix import of evpn routes into vni/vrf/esi after nexthop update#10372
louis-6wind wants to merge 2 commits into
FRRouting:masterfrom
louis-6wind:evpn-nht-update

Conversation

@louis-6wind

Copy link
Copy Markdown
Contributor

Related to issue #10271

After an update of the BGP nexthop (e.g. update of the igp metric), the
EVPN routes are not updated in VNIs, VRFs and ESIs.

Fix the issue.

Signed-off-by: Louis Scalbert louis.scalbert@6wind.com

Comment thread bgpd/bgp_evpn.c Outdated
@NetDEF-CI

NetDEF-CI commented Jan 19, 2022

Copy link
Copy Markdown
Collaborator
Continuous Integration Result: SUCCESSFUL

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-2824/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Warnings Generated during build:

Checkout code: Successful with additional warnings
Report for bgp_nht.c | 2 issues
===============================================
< WARNING: line over 80 characters
< #1107: FILE: /tmp/f1-890/bgp_nht.c:1107:

@NetDEF-CI

NetDEF-CI commented Jan 19, 2022

Copy link
Copy Markdown
Collaborator
Continuous Integration Result: SUCCESSFUL

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-2825/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

@louis-6wind louis-6wind force-pushed the evpn-nht-update branch 2 times, most recently from 8a086f6 to 2641ab9 Compare January 19, 2022 14:02
@NetDEF-CI

NetDEF-CI commented Jan 19, 2022

Copy link
Copy Markdown
Collaborator
Continuous Integration Result: FAILED

Continuous Integration Result: FAILED

See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-2841/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Failed

Debian 11 amd64 build: Failed (click for details) Debian 11 amd64 build: No useful log found
Successful on other platforms/tests
  • Ubuntu 18.04 ppc64le build
  • FreeBSD 12 amd64 build
  • Fedora 29 amd64 build
  • Ubuntu 16.04 i386 build
  • Ubuntu 18.04 arm7 build
  • Ubuntu 18.04 arm8 build
  • Redhat 8 amd64 build
  • OpenBSD 7 amd64 build
  • Debian 10 amd64 build
  • FreeBSD 11 amd64 build
  • Ubuntu 16.04 arm7 build
  • Ubuntu 18.04 i386 build
  • Ubuntu 18.04 amd64 build
  • Ubuntu 16.04 amd64 build
  • Ubuntu 20.04 amd64 build
  • NetBSD 9 amd64 build
  • Debian 9 amd64 build
  • CentOS 7 amd64 build
  • Ubuntu 16.04 arm8 build

Warnings Generated during build:

Checkout code: Successful with additional warnings
Debian 11 amd64 build: Failed (click for details) Debian 11 amd64 build: No useful log found
<stdin>:13: space before tab in indent.
		    		pi->extra->igpmetric == parent_pi->extra->igpmetric) ||
warning: 1 line adds whitespace errors.
Report for bgp_evpn.c | 6 issues
===============================================
< WARNING: line over 80 characters
< #2501: FILE: /tmp/f1-11173/bgp_evpn.c:2501:
< ERROR: code indent should use tabs where possible
< #2501: FILE: /tmp/f1-11173/bgp_evpn.c:2501:
< WARNING: please, no space before tabs
< #2501: FILE: /tmp/f1-11173/bgp_evpn.c:2501:

@NetDEF-CI

NetDEF-CI commented Jan 19, 2022

Copy link
Copy Markdown
Collaborator
Continuous Integration Result: SUCCESSFUL

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-2842/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

@paunadeu

Copy link
Copy Markdown

PR status?

@louis-6wind

Copy link
Copy Markdown
Contributor Author

PR status?

It is ready and needs a review

@paunadeu

Copy link
Copy Markdown

@ton31337 needs anything additional? who can review this? we have crit infra affected by this

Comment thread bgpd/bgp_nht.c Outdated

@donaldsharp donaldsharp left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure I understand the change in evaluate_paths. Can you go into more detail what you expect to work here?

@louis-6wind louis-6wind force-pushed the evpn-nht-update branch 4 times, most recently from 330d979 to f3fc37a Compare February 9, 2022 15:13
@louis-6wind

louis-6wind commented Feb 9, 2022

Copy link
Copy Markdown
Contributor Author

I am not sure I understand the change in evaluate_paths. Can you go into more detail what you expect to work here?

If the igp metric changes, I want to update nexthop on EVPN routes. bgp_evpn_import_route() can also do updates on existing routes, not only import.

  • bgp_process(path, dest, afi, safi) in evaluate_paths() does the metric update for evpn dest.
  • Metric update for RT5 routes imported via EVPN is done by bgp_process() within install_evpn_route_entry_in_vrf() that is called via bgp_evpn_import_route()

@louis-6wind

Copy link
Copy Markdown
Contributor Author

To reproduce the issue:

PE1 === (10.124.0.0/24) === PE2 === (10.125.0.0/24) ==== PE3
1.1.1.1                    2.2.2.2                      3.3.3.3
(5.5.5.5)                  (5.5.5.5)
  X   ens5 ============= ens4   X   ens6 ============== ens5 X

Apply the configuration PE1 to 3.
PE1

ip a a 10.124.0.1/24 dev ens5
ip li set dev ens5 up
ip li add loop1 type dummy
ip a a 1.1.1.1/32 dev loop1
ip li set dev loop1 up
ip li add vrf1 type vrf table 10
ip li set dev vrf1 up
ip li add br1 type bridge
ip li add vxl1   type vxlan id 100 dev loop1 local 1.1.1.1
ip li set dev vxl1 master br1
ip li set dev br1 master vrf1
ip li set dev br1 up
ip li set dev vxl1 up
ip li add loop2 type dummy
ip a a 5.5.5.5/32 dev loop2
ip li set dev loop2 up
ip li set dev loop2 master vrf1

ip li add loop3 type dummy
ip a a 6.6.6.6/32 dev loop3
ip li set dev loop3 up
ip li set dev loop3 master vrf1

zebra &
staticd&
bfdd&
ospfd&
bgpd&
sleep 2
vtysh
configure terminal
ip route 0.0.0.0/0 10.124.0.44
!
vrf vrf1
 ip route 0.0.0.0/0 192.168.0.44
 vni 100
 exit-vrf
!
router bgp 65400
 bgp router-id 1.1.1.1
 neighbor 3.3.3.3 remote-as 65400
 neighbor 3.3.3.3 bfd
 neighbor 3.3.3.3 update-source loop1
 neighbor 3.3.3.3 capability extended-nexthop
 !
 address-family ipv4 unicast
  no neighbor 3.3.3.3 activate
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor 3.3.3.3 activate
  advertise-all-vni
 exit-address-family
!
router bgp 65400 vrf vrf1
 bgp router-id 1.1.1.1
 !
 address-family ipv4 unicast
  redistribute connected
 exit-address-family
 !
 address-family l2vpn evpn
  autort rfc8365-compatible
  advertise ipv4 unicast
  rd 65400:100
 exit-address-family
!
router ospf
 ospf router-id 1.1.1.1
 redistribute connected
 network 10.124.0.0/24 area 0
!
line vty
!
end

PE2

ip a a 10.124.0.2/24 dev ens4
ip li set dev ens4 up
ip a a 10.125.0.2/24 dev ens6
ip li set dev ens6 up
ip li add loop1 type dummy
ip li set dev loop1 up
ip a a 2.2.2.2/32 dev loop1
ip li add vrf1 type vrf table 10
ip li set dev vrf1 up
ip li add vxl1   type vxlan id 100 dev loop1 local 2.2.2.2
ip li add br1 type bridge
ip li set dev vxl1 master br1
ip li set dev br1 master vrf1
ip li set dev br1 up
ip li set dev vxl1 up
ip li add loop2 type dummy
ip a a 5.5.5.5/32 dev loop2
ip li set dev loop2 up
ip li set dev loop2 master vrf1
sysctl -w net.ipv4.ip_forward=1


zebra&
staticd&
bfdd&
ospfd&
bgpd&
sleep 2
vtysh
configure terminal
vrf vrf1
 vni 100
 exit-vrf
!
router bgp 65400
 bgp router-id 2.2.2.2
 neighbor 3.3.3.3 remote-as 65400
 neighbor 3.3.3.3 bfd
 neighbor 3.3.3.3 update-source loop1
 neighbor 3.3.3.3 capability extended-nexthop
 !
 address-family ipv4 unicast
  no neighbor 3.3.3.3 activate
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor 3.3.3.3 activate
  advertise-all-vni
 exit-address-family
!
router bgp 65400 vrf vrf1
 bgp router-id 2.2.2.2
 !
 address-family ipv4 unicast
  redistribute connected
 exit-address-family
 !
 address-family l2vpn evpn
  autort rfc8365-compatible
  advertise ipv4 unicast
  rd 65400:100
 exit-address-family
!
router ospf
 ospf router-id 2.2.2.2
 redistribute connected
 network 10.124.0.0/24 area 0
 network 10.125.0.0/24 area 0
!
line vty
!
end

PE3

ip a a 10.125.0.3/24 dev ens5
ip li set dev ens5 up
ip link add loop1 type dummy
ip li set dev loop1 up
ip a a 3.3.3.3/32 dev loop1
ip li add vrf1 type vrf table 10
ip li set dev vrf1 up
ip li add br1 type bridge
ip li add vxl1   type vxlan id 100 dev loop1 local 3.3.3.3
ip li set dev vxl1 master br1
ip li set dev br1 master vrf1
ip li set dev br1 up
ip li set dev vxl1 up

zebra &
staticd&
bfdd&
ospfd&
bgpd&

sleep 2

vtysh
configure terminal
vrf vrf1
 vni 100
 exit-vrf
!
router bgp 65400
 bgp router-id 3.3.3.3
 neighbor 1.1.1.1 remote-as 65400
 neighbor 1.1.1.1 bfd
 neighbor 1.1.1.1 update-source loop1
 neighbor 1.1.1.1 capability extended-nexthop
 neighbor 2.2.2.2 remote-as 65400
 neighbor 2.2.2.2 bfd
 neighbor 2.2.2.2 update-source loop1
 neighbor 2.2.2.2 capability extended-nexthop
 !
 address-family ipv4 unicast
  no neighbor 2.2.2.2 activate
  no neighbor 1.1.1.1 activate
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor 1.1.1.1 activate
  neighbor 2.2.2.2 activate
  advertise-all-vni
 exit-address-family
!
router bgp 65400 vrf vrf1
 bgp router-id 3.3.3.3
 !
 address-family ipv4 unicast
  redistribute connected
 exit-address-family
 !
 address-family l2vpn evpn
  autort rfc8365-compatible
  advertise ipv4 unicast
  rd 65400:100
 exit-address-family
!
router ospf
 ospf router-id 3.3.3.3
 network 3.3.3.3/32 area 0
 network 10.125.0.0/24 area 0
!

PE3

pe3# show bgp nexthop 
Current BGP nexthop cache:

 1.1.1.1 valid [IGP metric 20], #paths 2, peer 1.1.1.1
  gate 10.125.0.2, if ens5
  Last update: Thu Dec 30 11:40:38 2021

 2.2.2.2 valid [IGP metric 20], #paths 1, peer 2.2.2.2
  gate 10.125.0.2, if ens5
  Last update: Thu Dec 30 11:41:13 2021

pe3# show bgp vrf vrf1 ipv4
[..]
   Network          Next Hop            Metric LocPrf Weight Path
*>i5.5.5.5/32       1.1.1.1<                 0    100      0 ?
*=i                 2.2.2.2<                 0    100      0 ?

PE1

conf t
router ospf
 redistribute connected metric 200

PE3
IGP metric has changed.

pe3# show bgp nexthop 
Current BGP nexthop cache:

 1.1.1.1 valid [IGP metric 200], #paths 2, peer 1.1.1.1
  gate 10.125.0.2, if ens5
  Last update: Thu Dec 30 11:48:38 2021

 2.2.2.2 valid [IGP metric 20], #paths 1, peer 2.2.2.2
  gate 10.125.0.2, if ens5
  Last update: Thu Dec 30 11:41:13 2021

But the routes remain the same.

pe3# show bgp vrf vrf1 ipv4
[..]
   Network          Next Hop            Metric LocPrf Weight Path
*>i5.5.5.5/32       1.1.1.1<                 0    100      0 ?
*=i                 2.2.2.2<                 0    100      0 ?

Expected output that we get after the patches

pe3# show bgp vrf vrf1 ipv4
[..]
   Network          Next Hop            Metric LocPrf Weight Path
*>i5.5.5.5/32       2.2.2.2<                 0    100      0 ?
* i                 1.1.1.1<                 0    100      0 ?

@louis-6wind louis-6wind changed the title bgpd: fix import of evpn routes into vni/vrf/esi after nexthop update WIP bgpd: fix import of evpn routes into vni/vrf/esi after nexthop update Feb 9, 2022
@louis-6wind louis-6wind force-pushed the evpn-nht-update branch 2 times, most recently from 3d3a0d1 to e28687d Compare February 9, 2022 16:23
@louis-6wind louis-6wind changed the title WIP bgpd: fix import of evpn routes into vni/vrf/esi after nexthop update bgpd: fix import of evpn routes into vni/vrf/esi after nexthop update Feb 9, 2022
@NetDEF-CI

NetDEF-CI commented Feb 9, 2022

Copy link
Copy Markdown
Collaborator
Continuous Integration Result: SUCCESSFUL

Continuous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-3329/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Warnings Generated during build:

Checkout code: Successful with additional warnings
Report for bgp_nht.c | 2 issues
===============================================
< WARNING: space prohibited before semicolon
< #1080: FILE: /tmp/f1-2641/bgp_nht.c:1080:

@NetDEF-CI

NetDEF-CI commented Feb 9, 2022

Copy link
Copy Markdown
Collaborator
Continuous Integration Result: FAILED

Continuous Integration Result: FAILED

Test incomplete. See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-3333/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Successful

Basic Tests: Incomplete

Addresssanitizer topotests part 4: Incomplete (check logs for details)
Successful on other platforms/tests
  • Topotests debian 10 amd64 part 8
  • IPv6 protocols on Ubuntu 18.04
  • Topotests debian 10 amd64 part 3
  • Addresssanitizer topotests part 0
  • Topotests Ubuntu 18.04 amd64 part 6
  • Topotests Ubuntu 18.04 arm8 part 4
  • Topotests Ubuntu 18.04 arm8 part 9
  • Ubuntu 18.04 deb pkg check
  • Ubuntu 20.04 deb pkg check
  • Debian 10 deb pkg check
  • IPv4 protocols on Ubuntu 18.04
  • Addresssanitizer topotests part 1
  • Topotests Ubuntu 18.04 i386 part 4
  • Topotests Ubuntu 18.04 amd64 part 9
  • Topotests Ubuntu 18.04 i386 part 8
  • Debian 9 deb pkg check
  • Addresssanitizer topotests part 8
  • Topotests Ubuntu 18.04 i386 part 3
  • Topotests Ubuntu 18.04 arm8 part 5
  • Addresssanitizer topotests part 7
  • Topotests debian 10 amd64 part 4
  • Topotests Ubuntu 18.04 i386 part 9
  • Topotests Ubuntu 18.04 arm8 part 3
  • Static analyzer (clang)
  • Topotests debian 10 amd64 part 1
  • Addresssanitizer topotests part 5
  • Topotests debian 10 amd64 part 2
  • Topotests Ubuntu 18.04 i386 part 6
  • Topotests Ubuntu 18.04 arm8 part 0
  • IPv4 ldp protocol on Ubuntu 18.04
  • Topotests Ubuntu 18.04 amd64 part 8
  • Ubuntu 16.04 deb pkg check
  • Topotests Ubuntu 18.04 amd64 part 4
  • Topotests Ubuntu 18.04 i386 part 1
  • Addresssanitizer topotests part 2
  • Topotests Ubuntu 18.04 amd64 part 5
  • Topotests debian 10 amd64 part 6
  • Topotests Ubuntu 18.04 arm8 part 1
  • Topotests Ubuntu 18.04 arm8 part 6
  • Topotests Ubuntu 18.04 amd64 part 0
  • Addresssanitizer topotests part 3
  • Topotests Ubuntu 18.04 amd64 part 7
  • Topotests Ubuntu 18.04 arm8 part 2
  • Topotests Ubuntu 18.04 arm8 part 7
  • Fedora 29 rpm pkg check
  • Topotests debian 10 amd64 part 0
  • Addresssanitizer topotests part 9
  • Topotests debian 10 amd64 part 5
  • CentOS 7 rpm pkg check
  • Topotests Ubuntu 18.04 i386 part 7
  • Topotests Ubuntu 18.04 arm8 part 8
  • Topotests Ubuntu 18.04 amd64 part 3
  • Addresssanitizer topotests part 6
  • Topotests Ubuntu 18.04 i386 part 2
  • Topotests debian 10 amd64 part 9
  • Topotests Ubuntu 18.04 amd64 part 2
  • Topotests Ubuntu 18.04 amd64 part 1
  • Topotests Ubuntu 18.04 i386 part 5
  • Topotests Ubuntu 18.04 i386 part 0
  • Topotests debian 10 amd64 part 7

@NetDEF-CI

NetDEF-CI commented Feb 9, 2022

Copy link
Copy Markdown
Collaborator
Continuous Integration Result: FAILED

Continuous Integration Result: FAILED

See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-3330/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Successful

Basic Tests: Failed

Topotests Ubuntu 18.04 i386 part 9: Failed (click for details)

Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO9U18I386-3330/test

Topology Tests failed for Topotests Ubuntu 18.04 i386 part 9
see full log at https://ci1.netdef.org/browse/FRR-PULLREQ2-3330/artifact/TOPO9U18I386/ErrorLog/log_topotests.txt

Successful on other platforms/tests
  • Topotests Ubuntu 18.04 amd64 part 6
  • Topotests Ubuntu 18.04 i386 part 8
  • Addresssanitizer topotests part 0
  • Topotests debian 10 amd64 part 8
  • Ubuntu 20.04 deb pkg check
  • Topotests Ubuntu 18.04 arm8 part 4
  • Topotests Ubuntu 18.04 arm8 part 9
  • Topotests debian 10 amd64 part 3
  • Debian 10 deb pkg check
  • IPv6 protocols on Ubuntu 18.04
  • Addresssanitizer topotests part 1
  • Topotests Ubuntu 18.04 i386 part 4
  • Topotests Ubuntu 18.04 arm8 part 3
  • Topotests debian 10 amd64 part 4
  • Topotests Ubuntu 18.04 i386 part 3
  • Addresssanitizer topotests part 4
  • IPv4 protocols on Ubuntu 18.04
  • Debian 9 deb pkg check
  • Topotests Ubuntu 18.04 amd64 part 9
  • Addresssanitizer topotests part 7
  • Static analyzer (clang)
  • Ubuntu 16.04 deb pkg check
  • Addresssanitizer topotests part 5
  • Topotests debian 10 amd64 part 1
  • Topotests Ubuntu 18.04 i386 part 6
  • Topotests Ubuntu 18.04 amd64 part 8
  • Topotests Ubuntu 18.04 i386 part 1
  • Topotests debian 10 amd64 part 2
  • Topotests Ubuntu 18.04 arm8 part 0
  • Topotests Ubuntu 18.04 arm8 part 5
  • IPv4 ldp protocol on Ubuntu 18.04
  • Topotests Ubuntu 18.04 amd64 part 4
  • Topotests Ubuntu 18.04 arm8 part 1
  • Topotests Ubuntu 18.04 amd64 part 7
  • Topotests Ubuntu 18.04 arm8 part 6
  • Topotests Ubuntu 18.04 amd64 part 5
  • Topotests Ubuntu 18.04 amd64 part 0
  • Addresssanitizer topotests part 2
  • Topotests debian 10 amd64 part 6
  • Fedora 29 rpm pkg check
  • Topotests debian 10 amd64 part 5
  • Topotests Ubuntu 18.04 arm8 part 2
  • Topotests debian 10 amd64 part 0
  • Topotests Ubuntu 18.04 arm8 part 7
  • Addresssanitizer topotests part 3
  • Addresssanitizer topotests part 9
  • CentOS 7 rpm pkg check
  • Addresssanitizer topotests part 8
  • Topotests Ubuntu 18.04 arm8 part 8
  • Topotests debian 10 amd64 part 9
  • Topotests Ubuntu 18.04 i386 part 7
  • Topotests Ubuntu 18.04 amd64 part 3
  • Topotests Ubuntu 18.04 i386 part 2
  • Addresssanitizer topotests part 6
  • Topotests Ubuntu 18.04 amd64 part 1
  • Topotests Ubuntu 18.04 i386 part 5
  • Topotests Ubuntu 18.04 amd64 part 2
  • Ubuntu 18.04 deb pkg check
  • Topotests Ubuntu 18.04 i386 part 0
  • Topotests debian 10 amd64 part 7

@louis-6wind

Copy link
Copy Markdown
Contributor Author

ci:rerun

@NetDEF-CI

Copy link
Copy Markdown
Collaborator

Continuous Integration Result: FAILED

See below for issues.
CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-14403/

This is a comment from an automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

Get source / Pull Request: Successful

Building Stage: Successful

Basic Tests: Failed

Topotests Ubuntu 18.04 amd64 part 1: Failed (click for details) Topotests Ubuntu 18.04 amd64 part 1: Unknown Log URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-14403/artifact/TP1U1804AMD64/TopotestDetails/

Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TP1U1804AMD64-14403/test

Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 1
see full log at https://ci1.netdef.org/browse/FRR-PULLREQ2-14403/artifact/TP1U1804AMD64/TopotestLogs/log_topotests.txt

Topotests Ubuntu 18.04 i386 part 8: Failed (click for details)

Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO8U18I386-14403/test

Topology Tests failed for Topotests Ubuntu 18.04 i386 part 8
see full log at https://ci1.netdef.org/browse/FRR-PULLREQ2-14403/artifact/TOPO8U18I386/TopotestLogs/log_topotests.txt
Topotests Ubuntu 18.04 i386 part 8: Unknown Log
URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-14403/artifact/TOPO8U18I386/TopotestDetails/

Topotests Ubuntu 18.04 arm8 part 9: Failed (click for details) Topotests Ubuntu 18.04 arm8 part 9: Unknown Log URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-14403/artifact/TOPO9U18ARM8/TopotestDetails/ Topotests Ubuntu 18.04 arm8 part 9: No useful log found
Successful on other platforms/tests
  • Topotests Ubuntu 18.04 amd64 part 4
  • Topotests Ubuntu 18.04 i386 part 1
  • Addresssanitizer topotests part 2
  • Topotests Ubuntu 18.04 amd64 part 5
  • Topotests Ubuntu 18.04 amd64 part 0
  • Topotests Ubuntu 18.04 arm8 part 6
  • Topotests Ubuntu 18.04 arm8 part 1
  • Topotests debian 10 amd64 part 6
  • Topotests debian 10 amd64 part 5
  • Topotests debian 10 amd64 part 0
  • Topotests Ubuntu 18.04 arm8 part 2
  • Topotests Ubuntu 18.04 amd64 part 7
  • Addresssanitizer topotests part 3
  • Topotests Ubuntu 18.04 arm8 part 7
  • Addresssanitizer topotests part 9
  • Addresssanitizer topotests part 8
  • Topotests Ubuntu 18.04 i386 part 2
  • CentOS 7 rpm pkg check
  • Topotests debian 10 amd64 part 9
  • Topotests Ubuntu 18.04 arm8 part 8
  • Addresssanitizer topotests part 6
  • Topotests Ubuntu 18.04 amd64 part 3
  • Topotests Ubuntu 18.04 i386 part 7
  • Topotests Ubuntu 18.04 i386 part 0
  • Topotests Ubuntu 18.04 i386 part 5
  • Topotests Ubuntu 18.04 amd64 part 2
  • Topotests debian 10 amd64 part 7
  • Topotests Ubuntu 18.04 amd64 part 6
  • Topotests debian 10 amd64 part 3
  • Addresssanitizer topotests part 0
  • Topotests debian 10 amd64 part 8
  • Topotests Ubuntu 18.04 arm8 part 4
  • Ubuntu 18.04 deb pkg check
  • Ubuntu 20.04 deb pkg check
  • Debian 10 deb pkg check
  • Addresssanitizer topotests part 1
  • Topotests Ubuntu 18.04 arm8 part 3
  • Topotests Ubuntu 18.04 i386 part 4
  • Topotests debian 10 amd64 part 4
  • Topotests Ubuntu 18.04 i386 part 3
  • Debian 9 deb pkg check
  • Addresssanitizer topotests part 4
  • Topotests Ubuntu 18.04 arm8 part 5
  • Topotests Ubuntu 18.04 amd64 part 9
  • Topotests Ubuntu 18.04 i386 part 9
  • Addresssanitizer topotests part 7
  • Static analyzer (clang)
  • Topotests debian 10 amd64 part 1
  • Addresssanitizer topotests part 5
  • Topotests Ubuntu 18.04 i386 part 6
  • Topotests debian 10 amd64 part 2
  • Topotests Ubuntu 18.04 amd64 part 8
  • Topotests Ubuntu 18.04 arm8 part 0

@louis-6wind

Copy link
Copy Markdown
Contributor Author

ci:rerun

@github-actions

Copy link
Copy Markdown

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@ton31337

Copy link
Copy Markdown
Member

@Mergifyio rebase

@mergify

mergify Bot commented Nov 14, 2025

Copy link
Copy Markdown

rebase

✅ Branch has been successfully rebased

@louis-6wind

Copy link
Copy Markdown
Contributor Author

@ton31337 it was rebased yesterday

@ton31337

Copy link
Copy Markdown
Member

Could you fix the styling also?

@louis-6wind

Copy link
Copy Markdown
Contributor Author

done

@riw777

riw777 commented May 14, 2026

Copy link
Copy Markdown
Member

@greptile review

@greptile-apps

greptile-apps Bot commented May 14, 2026

Copy link
Copy Markdown

Greptile Summary

This PR fixes EVPN type-5 routes not being updated in VRFs after a BGP nexthop IGP metric change (e.g., underlay metric update). The root cause was a two-part gap: evaluate_paths() in bgp_nht.c never triggered re-import for EVPN routes when validity was unchanged but the IGP metric changed, and install_evpn_route_entry_in_vrf() in bgp_evpn.c would short-circuit on an identical attribute hash even when BGP_PATH_IGP_CHANGED was set on the parent path.

  • bgp_nht.c: Adds an else if branch in evaluate_paths() that fires when nexthop validity is unchanged but BGP_PATH_IGP_CHANGED is set for an EVPN prefix, calling bgp_evpn_import_route (or unimport) to refresh VRF routes with the updated metric.
  • bgp_evpn.c: In install_evpn_route_entry_in_vrf(), the attrhash_cmp early-return is now skipped when parent_pi carries BGP_PATH_IGP_CHANGED, ensuring the derived route is re-processed and best-path is recalculated.
  • Tests: Extends the bgp_path_selection topotest with VXLAN/VNI plumbing across all three routers and two new test cases verifying ECMP and metric-based path selection for EVPN type-5 routes.

Confidence Score: 4/5

The core logic change is small and targeted; the main risk is the new NHT else-if branch triggering redundant unimports when a nexthop is already invalid.

Both changed code paths are narrow and well-contained. The bgp_evpn.c change simply widens the condition under which the early-return is bypassed, and the bgp_nht.c addition mirrors the existing validity-change handling pattern. The test suite is extended with concrete ECMP and metric selection assertions. Minor cosmetic issues (misleading comment, missing exit-address-family in test configs) do not affect correctness.

bgpd/bgp_nht.c — the new else-if branch and its comment; r2/bgpd.conf and r3/bgpd.conf — missing exit-address-family in the ipv4 unicast block.

Important Files Changed

Filename Overview
bgpd/bgp_nht.c Adds a new else-if branch in evaluate_paths() to trigger bgp_evpn_import_route/unimport when BGP_PATH_IGP_CHANGED is set and nexthop validity is unchanged; comment in the branch is slightly misleading.
bgpd/bgp_evpn.c Bypasses the attrhash_cmp early-return in install_evpn_route_entry_in_vrf() when parent_pi has BGP_PATH_IGP_CHANGED set, ensuring VRF routes are re-processed on metric updates even when the stored attribute hash matches.
tests/topotests/bgp_path_selection/test_bgp_path_selection.py Adds VRF/VNI setup in setup_module and two new test functions (evpn_r5_ecmp, evpn_r5_metric) that verify EVPN type-5 route ECMP and IGP-metric-based path selection; "r5" naming may be confused with router names.
tests/topotests/bgp_path_selection/r2/bgpd.conf Adds l2vpn evpn address-family to the default VRF and a new vrf2 BGP instance with EVPN type-5 advertisement; address-family ipv4 unicast block is missing an explicit exit-address-family.
tests/topotests/bgp_path_selection/r3/bgpd.conf Mirror of r2/bgpd.conf changes for r3; same missing exit-address-family pattern in the new vrf2 block.
tests/topotests/bgp_path_selection/r1/bgpd.conf Adds l2vpn evpn address-family to the default VRF and a new vrf2 BGP instance; config is structurally clean.
tests/topotests/bgp_path_selection/r1/zebra.conf Adds VNI 100 mapping for vrf2.
tests/topotests/bgp_path_selection/r2/zebra.conf Adds VNI 100 mapping for vrf2.
tests/topotests/bgp_path_selection/r3/zebra.conf Adds VNI 100 mapping for vrf2.

Sequence Diagram

sequenceDiagram
    participant Zebra
    participant NHT as bgp_nht.c (evaluate_paths)
    participant EVPN as bgp_evpn.c (import_route)
    participant VRF as install_evpn_route_entry_in_vrf

    Zebra->>NHT: Nexthop update (metric changed)
    NHT->>NHT: SET BGP_PATH_IGP_CHANGED on path
    NHT->>NHT: "old_path_valid == bnc_is_valid_nexthop?"
    Note over NHT: YES - new else-if branch fires
    NHT->>EVPN: bgp_evpn_import_route(path)
    EVPN->>VRF: install_evpn_route_entry_in_vrf(parent_pi)
    VRF->>VRF: CHECK_FLAG(parent_pi, BGP_PATH_IGP_CHANGED)?
    Note over VRF: YES - skip attrhash_cmp early-return
    VRF->>VRF: Update attr, trigger bgp_process
    NHT->>NHT: bgp_process(dest) [BGP_NEXTHOP_METRIC_CHANGED]
Loading
Prompt To Fix All With AI
Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
bgpd/bgp_nht.c:1505-1507
**Inaccurate comment in the new else-if branch**

The comment says "import the EVPN routes if the path validity changed or update existing routes," but this `else if` is only reached when `old_path_valid == bnc_is_valid_nexthop` — i.e., validity did **not** change. The "path validity changed" part is misleading; the branch solely handles the metric-update case where the nexthop validity is unchanged.

### Issue 2 of 3
tests/topotests/bgp_path_selection/test_bgp_path_selection.py:168-169
**Potentially confusing "r5" in test function names**

`test_bgp_path_selection_evpn_r5_ecmp` and `test_bgp_path_selection_evpn_r5_metric` use the suffix `r5`, which in this topology context (routers r1/r2/r3) looks like a reference to a non-existent router. The intent is EVPN route type 5 (IP prefix). Consider renaming to `_evpn_type5_ecmp` / `_evpn_type5_metric` to avoid confusion with router names.

### Issue 3 of 3
tests/topotests/bgp_path_selection/r2/bgpd.conf:31-34
**Missing `exit-address-family` for `address-family ipv4 unicast`**

The `address-family ipv4 unicast` block in the new `router bgp 65002 vrf vrf2` stanza has no closing `exit-address-family` before the next `address-family l2vpn evpn` entry. The same pattern applies in `r3/bgpd.conf`. While FRR's parser may handle an implicit exit, this is inconsistent with the rest of the config file and could cause unexpected parsing behaviour across FRR versions.

Reviews (1): Last reviewed commit: "tests: add an evpn RT5 path selection to..." | Re-trigger Greptile

Comment thread bgpd/bgp_nht.c
Comment on lines +1505 to +1507
if (bnc_is_valid_nexthop)
/* import the EVPN routes if the path validity
* changed or update existing routes.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Inaccurate comment in the new else-if branch

The comment says "import the EVPN routes if the path validity changed or update existing routes," but this else if is only reached when old_path_valid == bnc_is_valid_nexthop — i.e., validity did not change. The "path validity changed" part is misleading; the branch solely handles the metric-update case where the nexthop validity is unchanged.

Prompt To Fix With AI
This is a comment left during a code review.
Path: bgpd/bgp_nht.c
Line: 1505-1507

Comment:
**Inaccurate comment in the new else-if branch**

The comment says "import the EVPN routes if the path validity changed or update existing routes," but this `else if` is only reached when `old_path_valid == bnc_is_valid_nexthop` — i.e., validity did **not** change. The "path validity changed" part is misleading; the branch solely handles the metric-update case where the nexthop validity is unchanged.

How can I resolve this? If you propose a fix, please make it concise.

Comment on lines 168 to 169
assert result is None, "Failed to see BGP prefixes on R1"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Potentially confusing "r5" in test function names

test_bgp_path_selection_evpn_r5_ecmp and test_bgp_path_selection_evpn_r5_metric use the suffix r5, which in this topology context (routers r1/r2/r3) looks like a reference to a non-existent router. The intent is EVPN route type 5 (IP prefix). Consider renaming to _evpn_type5_ecmp / _evpn_type5_metric to avoid confusion with router names.

Prompt To Fix With AI
This is a comment left during a code review.
Path: tests/topotests/bgp_path_selection/test_bgp_path_selection.py
Line: 168-169

Comment:
**Potentially confusing "r5" in test function names**

`test_bgp_path_selection_evpn_r5_ecmp` and `test_bgp_path_selection_evpn_r5_metric` use the suffix `r5`, which in this topology context (routers r1/r2/r3) looks like a reference to a non-existent router. The intent is EVPN route type 5 (IP prefix). Consider renaming to `_evpn_type5_ecmp` / `_evpn_type5_metric` to avoid confusion with router names.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Comment on lines +31 to +34
bgp router-id 192.0.2.2
no bgp ebgp-requires-policy
address-family ipv4 unicast
redistribute connected

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Missing exit-address-family for address-family ipv4 unicast

The address-family ipv4 unicast block in the new router bgp 65002 vrf vrf2 stanza has no closing exit-address-family before the next address-family l2vpn evpn entry. The same pattern applies in r3/bgpd.conf. While FRR's parser may handle an implicit exit, this is inconsistent with the rest of the config file and could cause unexpected parsing behaviour across FRR versions.

Prompt To Fix With AI
This is a comment left during a code review.
Path: tests/topotests/bgp_path_selection/r2/bgpd.conf
Line: 31-34

Comment:
**Missing `exit-address-family` for `address-family ipv4 unicast`**

The `address-family ipv4 unicast` block in the new `router bgp 65002 vrf vrf2` stanza has no closing `exit-address-family` before the next `address-family l2vpn evpn` entry. The same pattern applies in `r3/bgpd.conf`. While FRR's parser may handle an implicit exit, this is inconsistent with the rest of the config file and could cause unexpected parsing behaviour across FRR versions.

How can I resolve this? If you propose a fix, please make it concise.

@mergify

mergify Bot commented May 14, 2026

Copy link
Copy Markdown

Deprecation notice: This pull request comes from a fork and was rebased using bot_account impersonation. This capability will be removed on July 1, 2026. After this date, the rebase action will no longer be able to rebase fork pull requests with this configuration. Please switch to the update action/command to ensure compatibility going forward.

@mergify

mergify Bot commented May 14, 2026

Copy link
Copy Markdown

rebase

✅ Branch has been successfully rebased

@riw777 riw777 requested review from riw777 and removed request for riw777 May 18, 2026 11:14
@RodrigoMNardi

Copy link
Copy Markdown
Contributor

ci:rerun

Related to issue FRRouting#10271. When importing prefixes from EVPN, any changes
to the BGP nexthop associated with those prefixes, such as a change in
the route metric to the peer, will not trigger a re-evaluation of the
imported prefixes.

In evaluate_path(), the import is only triggered when the validity of
the path changes, which is not the case when, for example, the route
metric to the peer changes.

Request import or unimport when BGP_PATH_IGP_CHANGED is set but the path
validity is unchanged. In install_evpn_route_entry_in_vrf(), do not skip
VRF import when BGP_PATH_IGP_CHANGED is set.

Fixes: 34ea39b ("bgpd: Check NHT change for triggering EVPN import or unimport")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add an evpn RT5 path selection to bgp_path_selection

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
@louis-6wind

Copy link
Copy Markdown
Contributor Author

ci:rerun

1 similar comment
@louis-6wind

Copy link
Copy Markdown
Contributor Author

ci:rerun

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants