*: PBR - netlink interaction and basic definitions #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Handle the return value of argv_find_and_parse_afi() to avoid passing along bad values. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
…ian-file debianpkg: Add missing frr-dbg.lintian-overrides to Makefile
bgpd: fix some coverity scan issues
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya<mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.comy>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 11, 2024
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 11, 2024
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 13, 2024
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 13, 2024
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 13, 2024
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 13, 2024
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 17, 2024
There is a race condition with addpath withdrawal. The withdrawal never happens if it was request when coalesce timer running. It can be demonstrated by adding to bgp_snmp_bgp4v2mib/rr/bgpd.conf: > router bgp 65004 > + coalesce-time 10000 But it also happens in other conditions. For example, when using "vtysh -f" to load the configuration. It results in having two identical paths but with different addpath on r2: > r2# sh bgp ipv4 10.0.0.0/31 > BGP routing table entry for 10.0.0.0/31, version 3 > Paths: (3 available, best #1, table default) > 65004 > 192.168.12.4 from 192.168.12.4 (192.168.12.4) > Origin IGP, metric 1, valid, external, multipath, best (AS Path) > AddPath ID: RX 0, TX-All 2 TX-Best-Per-AS 0 TX-Best-Selected 0 > Advertised to: 192.168.12.4 > Last update: Thu Sep 12 16:13:59 2024 > 65004 > 192.168.12.4 from 192.168.12.4 (192.168.12.4) > Origin IGP, metric 1, valid, external, multipath > AddPath ID: RX 3, TX-All 4 TX-Best-Per-AS 0 TX-Best-Selected 0 > Advertised to: 192.168.12.4 > Last update: Thu Sep 12 16:13:59 2024 The first path has been created first but should be withdrawn later. Withdraw the stale addpath even the coalesce timer is running. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 17, 2024
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 17, 2024
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 18, 2024
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 18, 2024
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 18, 2024
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 18, 2024
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 18, 2024
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 18, 2024
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 18, 2024
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Dec 18, 2024
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 3, 2025
…n 12 LTTng support Issue: FRR currently utilizes LTTng version 2.10, which has been updated to version 2.13.5-1. This update needs a change in the library, requiring an update on the FRR side to make LTTng working. Fix: Updated the LTTng library dependency from liblttng-ust.so.0 to liblttng-ust-fork.so.1 to align with the new version requirements. UT: unit testing to confirm LTTng's operational status with the new library: - System: Linux mlx-2410ba1-02 6.1.0-cl-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4+cl5.9.0u1 (2023-08-11) x86_64 GNU/Linux - Test Command: /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-zebra-onboot/ /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-onboot/ - Results: Confirmed successful interface updates and address additions, indicating LTTng is functioning as expected with the updated library. Ticket: #3735825 Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 3, 2025
When bgp neighbor GSHUT is done, advertise routes recivied from this neighbor with GSHUT attribute. Ticket: #3948080 Testing: mlx-4600ca1-01(config-router)# neighbor 210.2.0.2 graceful-shutdown logs: 2024/06/18 00:11:34 BGP: [MS8ZT-QEXJ8] u2:s4 210.2.0.2 announcing routes 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, localpref 0, community graceful-shutdown, path 201 200 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [WEV7K-2GAQ5] u1:s3 send UPDATE len 96 (max message len: 65535) numpfx 9 2024/06/18 00:11:35 BGP: [MBFVT-8GSC6] u1:s3 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, localpref 0, metric 0, community graceful-shutdown, path 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 133.133.133.133/32 IPv4 unicast mlx-4600ca1-01(config-router)#no neighbor 210.2.0.2 graceful-shutdown logs: 024/06/18 00:12:59 BGP: [MS8ZT-QEXJ8] u2:s6 210.2.0.2 announcing routes 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, path 201 200 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 89 (max message len: 65535) numpfx 9 2024/06/18 00:13:00 BGP: [MBFVT-8GSC6] u1:s5 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, metric 0, path 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 133.133.133.133/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 56 (max message len: 65535) numpfx 1 default route: n2# show ip bgp 0.0.0.0/0 BGP routing table entry for 0.0.0.0/0, version 70 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: mlx-4600ca1-01(210.2.0.1) n3(210.3.1.3) n3(2210:210:3:1::3) 201 100 210.2.0.1 (mlx-4600ca1-01) from mlx-4600ca1-01(210.2.0.1) (20.0.0.1) Origin IGP, metric 0, localpref 0, valid, external, bestpath-from-AS 201, best (First path received) Community: graceful-shutdown Last update: Wed Jun 26 20:20:29 2024 Signed-off-by: Vijayalaxmi Basavaraj <vbasavaraj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 3, 2025
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 3, 2025
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 3, 2025
…n 12 LTTng support Issue: FRR currently utilizes LTTng version 2.10, which has been updated to version 2.13.5-1. This update needs a change in the library, requiring an update on the FRR side to make LTTng working. Fix: Updated the LTTng library dependency from liblttng-ust.so.0 to liblttng-ust-fork.so.1 to align with the new version requirements. UT: unit testing to confirm LTTng's operational status with the new library: - System: Linux mlx-2410ba1-02 6.1.0-cl-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4+cl5.9.0u1 (2023-08-11) x86_64 GNU/Linux - Test Command: /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-zebra-onboot/ /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-onboot/ - Results: Confirmed successful interface updates and address additions, indicating LTTng is functioning as expected with the updated library. Ticket: #3735825 Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 3, 2025
When bgp neighbor GSHUT is done, advertise routes recivied from this neighbor with GSHUT attribute. Ticket: #3948080 Testing: mlx-4600ca1-01(config-router)# neighbor 210.2.0.2 graceful-shutdown logs: 2024/06/18 00:11:34 BGP: [MS8ZT-QEXJ8] u2:s4 210.2.0.2 announcing routes 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, localpref 0, community graceful-shutdown, path 201 200 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [WEV7K-2GAQ5] u1:s3 send UPDATE len 96 (max message len: 65535) numpfx 9 2024/06/18 00:11:35 BGP: [MBFVT-8GSC6] u1:s3 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, localpref 0, metric 0, community graceful-shutdown, path 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 133.133.133.133/32 IPv4 unicast mlx-4600ca1-01(config-router)#no neighbor 210.2.0.2 graceful-shutdown logs: 024/06/18 00:12:59 BGP: [MS8ZT-QEXJ8] u2:s6 210.2.0.2 announcing routes 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, path 201 200 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 89 (max message len: 65535) numpfx 9 2024/06/18 00:13:00 BGP: [MBFVT-8GSC6] u1:s5 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, metric 0, path 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 133.133.133.133/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 56 (max message len: 65535) numpfx 1 default route: n2# show ip bgp 0.0.0.0/0 BGP routing table entry for 0.0.0.0/0, version 70 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: mlx-4600ca1-01(210.2.0.1) n3(210.3.1.3) n3(2210:210:3:1::3) 201 100 210.2.0.1 (mlx-4600ca1-01) from mlx-4600ca1-01(210.2.0.1) (20.0.0.1) Origin IGP, metric 0, localpref 0, valid, external, bestpath-from-AS 201, best (First path received) Community: graceful-shutdown Last update: Wed Jun 26 20:20:29 2024 Signed-off-by: Vijayalaxmi Basavaraj <vbasavaraj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 6, 2025
Global BGP configuration knob like 'bgp graceful-shutdown' is not rendered properly via frr-reload script. when the config line is rendered if happened to be post router bgp config lines, frr end up rendering bgp gr-shut under bgp instance config though global config knob is set. Two fixes: 1) Move bgp global config line at the beginning of pending config lines to add. 2) Skip adding bgp global config line in second pass of frr-reload script run. The second fix is required to avoid following scenario: 2022-08-30 20:40:53,397 DEBUG: Running Frr Config (Pass #0) ['bgp graceful-shutdown\n', 'router bgp 65564\n timers bgp 3 9\n', 'router bgp 65564\n bgp deterministic-med\n', 2022-08-30 20:40:54,042 DEBUG: Running Frr Config (Pass #1) 'vrf mgmt\n', 'router bgp 65564 vrf sym_1\n address-family l2vpn evpn\n', 'bgp graceful-shutdown\n', <<<<<<< reapp %Failed: per-vrf graceful-shutdown config not permitted with global graceful-shutdown line 97: Failure to communicate[13] to bgpd, line: bgp graceful-shutdown [8816|bgpd] Configuration file[/etc/frr/frr.conf] processing failure: 13 Ticket: #3187405 Testing Done: Add and remove 'bgp graceful-shutdown' config in frr.conf and perform frr-reload. Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 6, 2025
route-map match condition on evpn default-route does not have proper check that its truly type-5 before checking prefixlen being 0. In absence of the fix, the set condition applied to all evpn routes as evpn prefix is type union so just checking for prefixlen 0 is not sufficient. Ticket:#3227895 Issue:3227895 Testing Done: Apply ingress route-map policy: route-map POLICY_OUT_SS permit 10 match evpn default-route set metric 6666 Default route contains metric only to default route: BGP routing table entry for 144.1.1.6:4:[5]:[0]:[0.0.0.0/0]/352 Paths: (2 available, best #1) Advertised to non peer-group peers: leaf-21(swp1) leaf-22(swp2) Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-21(swp1) (6.0.0.26) Origin IGP, metric 6666, valid, external, bestpath-from-AS 651004, best (Router ID) Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Route [5]:[0]:[0]:[0.0.0.0] VNI 104002 651004 652000 651001 660000 6.0.0.1 from leaf-22(swp2) (6.0.0.27) Origin IGP, metric 6666, valid, external Extended Community: RT:4640:104002 ET:8 Rmac:00:02:00:00:00:04 Last update: Fri Oct 7 20:25:39 2022 Signed-off-by: Chirag Shah <chirag@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 6, 2025
…n 12 LTTng support Issue: FRR currently utilizes LTTng version 2.10, which has been updated to version 2.13.5-1. This update needs a change in the library, requiring an update on the FRR side to make LTTng working. Fix: Updated the LTTng library dependency from liblttng-ust.so.0 to liblttng-ust-fork.so.1 to align with the new version requirements. UT: unit testing to confirm LTTng's operational status with the new library: - System: Linux mlx-2410ba1-02 6.1.0-cl-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4+cl5.9.0u1 (2023-08-11) x86_64 GNU/Linux - Test Command: /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-zebra-onboot/ /usr/lib/frr/frr_babeltrace.py /var/log/lttng-traces/frr-local-onboot/ - Results: Confirmed successful interface updates and address additions, indicating LTTng is functioning as expected with the updated library. Ticket: #3735825 Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 6, 2025
When bgp neighbor GSHUT is done, advertise routes recivied from this neighbor with GSHUT attribute. Ticket: #3948080 Testing: mlx-4600ca1-01(config-router)# neighbor 210.2.0.2 graceful-shutdown logs: 2024/06/18 00:11:34 BGP: [MS8ZT-QEXJ8] u2:s4 210.2.0.2 announcing routes 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, localpref 0, community graceful-shutdown, path 201 200 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:11:35 BGP: [WEV7K-2GAQ5] u1:s3 send UPDATE len 96 (max message len: 65535) numpfx 9 2024/06/18 00:11:35 BGP: [MBFVT-8GSC6] u1:s3 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:11:35 BGP: [TN0HX-6G1RR] u1:s3 send UPDATE w/ attr: nexthop 0.0.0.0, localpref 0, metric 0, community graceful-shutdown, path 2024/06/18 00:11:35 BGP: [HVRWP-5R9NQ] u1:s3 send UPDATE 133.133.133.133/32 IPv4 unicast mlx-4600ca1-01(config-router)#no neighbor 210.2.0.2 graceful-shutdown logs: 024/06/18 00:12:59 BGP: [MS8ZT-QEXJ8] u2:s6 210.2.0.2 announcing routes 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, origin ?, path 201 200 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 20.10.10.2/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.0.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.2.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.3.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.4.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.5.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.2.6.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 210.3.1.0/24 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 89 (max message len: 65535) numpfx 9 2024/06/18 00:13:00 BGP: [MBFVT-8GSC6] u1:s5 210.2.0.2 send UPDATE w/ nexthop 210.2.0.1 2024/06/18 00:13:00 BGP: [TN0HX-6G1RR] u1:s5 send UPDATE w/ attr: nexthop 0.0.0.0, metric 0, path 2024/06/18 00:13:00 BGP: [HVRWP-5R9NQ] u1:s5 send UPDATE 133.133.133.133/32 IPv4 unicast 2024/06/18 00:13:00 BGP: [WEV7K-2GAQ5] u1:s5 send UPDATE len 56 (max message len: 65535) numpfx 1 default route: n2# show ip bgp 0.0.0.0/0 BGP routing table entry for 0.0.0.0/0, version 70 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: mlx-4600ca1-01(210.2.0.1) n3(210.3.1.3) n3(2210:210:3:1::3) 201 100 210.2.0.1 (mlx-4600ca1-01) from mlx-4600ca1-01(210.2.0.1) (20.0.0.1) Origin IGP, metric 0, localpref 0, valid, external, bestpath-from-AS 201, best (First path received) Community: graceful-shutdown Last update: Wed Jun 26 20:20:29 2024 Signed-off-by: Vijayalaxmi Basavaraj <vbasavaraj@nvidia.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 9, 2025
…utes detail` If we have a route-map that sets some attributes e.g. community or large-community, and the route-map is applied for outgoing direction, everything is fine, but we missed the point that `advertised-routes detail` was not using the applied attributes to display and instead it uses what is received from the peer (original). Let's fix this, and use what's already applied (advertise attributes), and we can now see: ``` route-map r3 permit 10 match ip address prefix-list p1 set community 65001:65002 set extcommunity bandwidth 100 set large-community 65001:65002:65003 exit ! ... address-family ipv4 unicast neighbor 192.168.2.3 route-map r3 out exit-address-family ... ``` The output: ``` r2# show bgp ipv4 neighbors 192.168.2.3 advertised-routes detail BGP table version is 1, local router ID is 192.168.2.2, vrf id 0 Default local pref 100, local AS 65002 BGP routing table entry for 10.10.10.1/32, version 1 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.1.1 192.168.2.3 65001 0.0.0.0 from 192.168.1.1 (192.168.1.1) Origin IGP, valid, external, best (First path received) Community: 65001:65002 Extended Community: LB:65002:12500000 (100.000 Mbps) Large Community: 65001:65002:65003 Last update: Thu Dec 19 17:00:40 2024 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 9, 2025
The following ASAN error can be seen. > ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x608000036c20 > #0 0x7f3d7a4b5425 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:198 > #1 0x7f3d7a426a16 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common > /sanitizer_stacktrace.h:122 > #2 0x7f3d7a426a16 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1074 > #3 0x7f3d7a03f330 in mt_count_free lib/memory.c:78 > #4 0x7f3d7a03f330 in qfree lib/memory.c:130 > #5 0x7f3d76ccf89b in bmp_peer_status_changed bgpd/bgp_bmp.c:982 > #6 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47 > #7 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287 > #8 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777 > #9 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140 > #10 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764 > #11 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003 > #12 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062 > #13 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228 > #14 0x7f3d7a107b53 in vty_command lib/vty.c:625 > #15 0x7f3d7a109902 in vty_execute lib/vty.c:1388 > #16 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400 > #17 0x7f3d7a0f848b in event_call lib/event.c:2019 > #18 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232 > #19 0x560ae29e0037 in main bgpd/bgp_main.c:555 > #20 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > #21 0x7f3d79a29e3f in __libc_start_main_impl ../csu/libc-start.c:392 > #22 0x560ae29e4ef4 in _start (/usr/lib/frr/bgpd+0x2eeef4) > > 0x608000036c20 is located 0 bytes inside of 81-byte region [0x608000036c20,0x608000036c71) > freed by thread T0 here: > #0 0x7f3d7a4b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127 > #1 0x7f3d76ccf85f in bmp_peer_status_changed bgpd/bgp_bmp.c:981 > #2 0x560ae2aa6a94 in hook_call_peer_status_changed bgpd/bgp_fsm.c:47 > #3 0x560ae2aa6a94 in bgp_fsm_change_status bgpd/bgp_fsm.c:1287 > #4 0x560ae2c4f2e5 in peer_delete bgpd/bgpd.c:2777 > #5 0x560ae2c58d24 in bgp_delete bgpd/bgpd.c:4140 > #6 0x560ae2bbb47e in no_router_bgp bgpd/bgp_vty.c:1764 > #7 0x7f3d79fb74ed in cmd_execute_command_real lib/command.c:1003 > #8 0x7f3d79fb78a3 in cmd_execute_command lib/command.c:1062 > #9 0x7f3d79fb7e03 in cmd_execute lib/command.c:1228 > #10 0x7f3d7a107b53 in vty_command lib/vty.c:625 > #11 0x7f3d7a109902 in vty_execute lib/vty.c:1388 > #12 0x7f3d7a10cc32 in vtysh_read lib/vty.c:2400 > #13 0x7f3d7a0f848b in event_call lib/event.c:2019 > #14 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232 > #15 0x560ae29e0037 in main bgpd/bgp_main.c:555 > #16 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > previously allocated by thread T0 here: > #0 0x7f3d7a4b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7f3d7a03f0e9 in qmalloc lib/memory.c:101 > #2 0x7f3d76cd0166 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2194 > #3 0x7f3d76cd0166 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2236 > #4 0x7f3d76cd29b8 in bmp_vrf_state_changed bgpd/bgp_bmp.c:3479 > #5 0x560ae2c45b34 in hook_call_bgp_instance_state bgpd/bgpd.c:88 > #6 0x560ae2c4d158 in bgp_instance_up bgpd/bgpd.c:3936 > #7 0x560ae29e5ed1 in bgp_vrf_enable bgpd/bgp_main.c:299 > #8 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:286 > #9 0x7f3d7a0ff8b1 in vrf_enable lib/vrf.c:275 > #10 0x7f3d7a12ab66 in zclient_vrf_add lib/zclient.c:2561 > #11 0x7f3d7a12eb43 in zclient_read lib/zclient.c:4624 > #12 0x7f3d7a0f848b in event_call lib/event.c:2019 > #13 0x7f3d7a01e627 in frr_run lib/libfrr.c:1232 > #14 0x560ae29e0037 in main bgpd/bgp_main.c:555 > #15 0x7f3d79a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
donaldsharp
pushed a commit
that referenced
this pull request
Jan 9, 2025
The following memory leak can be observed when turning off and on the BGP vrf interface. > ==706056==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 78 byte(s) in 1 object(s) allocated from: > #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101 > #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042 > #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079 > #4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204 > #5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64 > #6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234 > #7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57 > #8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203 > #9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671 > #10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624 > #11 0x7fbf5f18078d in event_call lib/event.c:1996 > #12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232 > #13 0x562740c0cae1 in main bgpd/bgp_main.c:557 > #14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 78 byte(s) in 1 object(s) allocated from: > #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101 > #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042 > #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079 > #4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627 > #5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590 > #6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197 > #7 0x7fbf5f18078d in event_call lib/event.c:1996 > #8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232 > #9 0x562740c0cae1 in main bgpd/bgp_main.c:557 > #10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fix this by freeing the previous open_tx and open_rx contexts before setting up the new one. Also at deletion of peer, free the open_rx context. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.