[FRR]: Upgrade FRR to version 10.3#22267
Conversation
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@cscarpitta, @ahsalam, the image with the FRR upgrade cannot pass the sanity check and test_pretest.py which seems to be caused by BGP container down. Please check locally. |
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…group”.
Assume we have a BGP peer group called `BGPSLBPassive`.
This peer group is attached to a listen range `192.168.0.0/21`.
CONFIG_DB configuration:
> $ sonic-db-cli CONFIG_DB hgetall "BGP_PEER_RANGE|BGPSLBPassive"
> {'ip_range@': '192.168.0.0/21', 'name': 'BGPSLBPassive', 'src_address': '10.1.0.32'}
FRR configuration:
> ...
> router bgp 65100
> neighbor BGPSLBPassive peer-group
> bgp listen range 192.168.0.0/21 peer-group BGPSLBPassive
> ...
Now, we delete the peer group `BGPSLBPassive` from CONFIG_DB:
> $ sonic-db-cli CONFIG_DB del BGP_PEER_RANGE|BGPSLBPassive
In response to this, bgpcfgd tries to run the following vtysh command
to delete the peer group from the FRR configuration:
> vtysh -c "no neighbor BGPSLBPassive peer-group"
But the above vtysh command returns an error:
> %%Peer-group BGPSLBPassive is attached to 1 listen-range(s), delete them first
The problem is due to a change in recent versions of FRR.
Starting with FRR 10.1, if a peer group is attached to a "listen range",
the range must be removed before the peer group can be deleted.
In order to fix this issue, this commit does a change in bgpcfgd.
When bgpcfgd has to delete a peer group, it first runs the command
"no bgp listen range ..." to remove the "listen range" associated with
the peer group, and only then proceed with deleting the peer group.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run Azure.sonic-buildimage |
|
Commenter does not have sufficient privileges for PR 22267 in repo sonic-net/sonic-buildimage |
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-buildimage |
|
/AzurePipelines run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-buildimage |
|
/AzurePipelines run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@StormLiangMS, @liushilongbuaa saw the following message in the error . Can you help to rerun it? Conflict already exists in master |
|
/azpw ms_conflict |
|
/AzurePipelines run Azure.sonic-buildimage |
|
Commenter does not have sufficient privileges for PR 22267 in repo sonic-net/sonic-buildimage |
|
/azpw run Azure.sonic-buildimage |
|
/AzurePipelines run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-buildimage |
|
/AzurePipelines run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@cscarpitta , all PR validation in https://github.com/sonic-net/sonic-swss/pulls failed because this change. Here is how I validate it:
Missing log: Above just 1 example, there are many test cases failed. |
|
Hi @liuh-80 Thanks for reporting the issue. I raised two PRs to fix the test failures: |
| if (CHECK_FLAG(attr->flag, ATTR_FLAG_BIT(BGP_ATTR_NEXT_HOP))) | ||
| - nh_invalid = (attr->nexthop.s_addr == INADDR_ANY || | ||
| - !ipv4_unicast_valid(&attr->nexthop) || | ||
| + if (!ipv4_unicast_valid(&attr->nexthop) || |
There was a problem hiding this comment.
in FRRouting 10.0 or 8.5, the code is
if (attr->nexthop.s_addr == INADDR_ANY || !ipv4_unicast_valid(&attr->nexthop) || bgp_nexthop_self(bgp, afi, type, stype, attr, dest)) return true;
in Frrouting 10.3, the code is updated to
if (CHECK_FLAG(attr->flag, ATTR_FLAG_BIT(BGP_ATTR_NEXT_HOP))) nh_invalid = (attr->nexthop.s_addr == INADDR_ANY || !ipv4_unicast_valid(&attr->nexthop) || bgp_nexthop_self(bgp, afi, type, stype, attr, dest));
so the patch for Frr10.3 should be like this
nh_invalid = (!ipv4_unicast_valid(&attr->nexthop) || bgp_nexthop_self(bgp, afi, type, stype, attr, dest));
not be like this:
if (!ipv4_unicast_valid(&attr->nexthop) || bgp_nexthop_self(bgp, afi, type, stype, attr, dest));
New patches that were added:
Removed patches:
Realigned patches: