[FRR]Setting multipath size to 512 and disabling bgp-vnc for optimization #20744
Conversation
|
@eddieruan-alibaba @hasan-brcm FYI. Please review the changes. |
|
@dgsudharsan , frr 10.0.1 upgrade (PR#20269) is already in progress. Please wait for that to get merged. @sudhanshukumar22 , @adyeung - FYI |
|
/azpw run Azure.sonic-buildimage |
|
/AzurePipelines run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| --disable-zeromq \ | ||
| --enable-ospfapi \ | ||
| - --enable-bgp-vnc \ | ||
| - --enable-multipath=256 \ |
There was a problem hiding this comment.
what is the use case to have 512 ECMP paths from FRR.
Currently FRR uses uint8 for num paths.
There was a problem hiding this comment.
This is fixed by FRR FRRouting/frr#16967. We will be taking this fix once FRR upgrade is done. We do have some specific use case scenarios where the number of nexthops might scale more than 256. So we are setting to 512 here.
There was a problem hiding this comment.
You can refer to the topology here sonic-net/sonic-mgmt#15355
Why I did it
Increased the max multipath to 512. In addition removed bgp-vnc as this feature is not used by SONiC .
https://docs.frrouting.org/en/latest/vnc.html#vnc-and-vnc-gw
This feature adds overhead in general and removing this improves bgp convergence time for scale.
Work item tracking
How I did it
Added a patch modify debian rules.
How to verify it
Run BGP tests in scaled topology.
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)