[bgpcfgd] Add bgpcfgd support for static routes#7233
[bgpcfgd] Add bgpcfgd support for static routes#7233shi-su merged 5 commits intosonic-net:masterfrom
Conversation
| }), | ||
| True, | ||
| [ | ||
| "ip route 10.1.2.0/24 blackhole 10" |
There was a problem hiding this comment.
Does this feature consider mgmt route as well? e.g mgmt route in default & mgmt VRFs.
There was a problem hiding this comment.
The scope of this PR is to cover STATIC_ROUTE table in config_db. Routes that are reflected in this table are considered, otherwise not.
There was a problem hiding this comment.
I see all test cases are with PortChannel0001/PortChannel0002, can we have some tests with Etherent and Vlan interfaces as well?
There was a problem hiding this comment.
Added a test case with Ethernet interfaces. Since bgpcfgd is basically a translator from config_db to the commands. The interface type should not make any difference from the unit test perspective.
There was a problem hiding this comment.
I understand, it is better to test other interfaces as well.
| from .manager import Manager | ||
| from .template import TemplateFabric | ||
| import socket | ||
|
|
There was a problem hiding this comment.
Did we test save & restore for STATIC_ROUTE table?
There was a problem hiding this comment.
Do you mean saving and restoring items in STATIC_ROUTE table in config_db? There should be a config command to apply changes to config_db. I think the test for that is not going to be covered by this PR. There would be unit tests for the config command. And we are planning to have sonic-mgmt tests to test the static route feature as a whole.
| cmd_list = self.static_route_commands(ip_nh_set, cur_nh_set, ip_prefix, vrf) | ||
|
|
||
| if cmd_list: | ||
| self.cfg_mgr.push_list(cmd_list) |
There was a problem hiding this comment.
Can we add test cases with other L3 interfaces as well e.g PHY/VLAN..etc.?
There was a problem hiding this comment.
I am not sure if I fully understood your suggestion. Could you please maybe give an example of what additional test case you are suggesting?
There was a problem hiding this comment.
Looks like you have added the test cases with Ethernet already, thanks.
prsunny
left a comment
There was a problem hiding this comment.
Please find comments. Also, "default" is optional in the STATIC_ROUTE schema. Would suggest modify your description so as to avoid any confusion.
| @@ -0,0 +1,173 @@ | |||
| import traceback | |||
There was a problem hiding this comment.
Please rename this file to managers_static_rt.py to be consistent with existing files
There was a problem hiding this comment.
Renamed the file name to managers_static_rt.py.
| "SET", | ||
| ("default|10.1.1.0/24", { | ||
| "nexthop": "10.0.0.57, 10.0.0.59", | ||
| "ifname": "PortChannel0001", |
There was a problem hiding this comment.
ifname is optional, so is nexthop.. so if either one is provided, you should consider it valid. But if user specifies both, then there should be empty string to specify positional arguments. Could you please add few cases for this as well?
There was a problem hiding this comment.
Yes, both ifname and nexthop are optional. In the case where both ifname and nexthop are given, they should have the number of items to avoid confusion. An empty string separated by a comma is needed if only one item has no value given, for example, "nexthop": "10.0.0.57,10.0.0.59", "ifname": "PortChannel0001," is valid, "nexthop": "10.0.0.57, 10.0.0.59", "ifname": "PortChannel0001" is not. I added more test cases to better cover these scenarios.
| StaticRouteMgr(common_objs, "CONFIG_DB", "STATIC_ROUTE"), | ||
| ] | ||
| runner = Runner(common_objs['cfg_mgr']) | ||
| for mgr in managers: |
There was a problem hiding this comment.
I dont see any code in "RouteOrch::addRoute" to trigger the proactive nbr resolution when nexthop is not resolved, is this already planned? Did we test fast path routing with static route config in the HW?
There was a problem hiding this comment.
Resolving nexthop in RouteOrch is our next step for the static route tasks.
| mgr, | ||
| "SET", | ||
| ("vrfRED|10.1.3.0/24", { | ||
| "nexthop": "10.0.0.57,10.0.0.59,10.0.0.61,10.0.0.63", |
There was a problem hiding this comment.
please also have a test to remove one nexthop
There was a problem hiding this comment.
Added the scenario of removing part of the nexthops.
|
@venkatmahalingam , could you please re-review/sign-off? |
Why I did it Add bgpcfgd support for static routes. How I did it Add bgpcfgd support to subscribe changes in STATIC_ROUTE table in CONFIG_DB and program via vtysh. The key of STATIC_ROUTE table is formatted as STATIC_ROUTE|vrf|ip_prefix, while the vrf is optional. If would be treated the same as "default" if no vrf is given. Add unit tests.
Why I did it Add bgpcfgd support for static routes. How I did it Add bgpcfgd support to subscribe changes in STATIC_ROUTE table in CONFIG_DB and program via vtysh. The key of STATIC_ROUTE table is formatted as STATIC_ROUTE|vrf|ip_prefix, while the vrf is optional. If would be treated the same as "default" if no vrf is given. Add unit tests.
Why I did it Add bgpcfgd support for static routes. How I did it Add bgpcfgd support to subscribe changes in STATIC_ROUTE table in CONFIG_DB and program via vtysh. The key of STATIC_ROUTE table is formatted as STATIC_ROUTE|vrf|ip_prefix, while the vrf is optional. If would be treated the same as "default" if no vrf is given. Add unit tests.
Why I did it
Add bgpcfgd support for static routes.
How I did it
Add bgpcfgd support to subscribe changes in STATIC_ROUTE table in CONFIG_DB and program via vtysh. The key of STATIC_ROUTE table is formatted as STATIC_ROUTE|vrf|ip_prefix, while the vrf is optional. If would be treated the same as "default" if no vrf is given.
Add unit tests.
How to verify it
Confirm that changes in STATIC_ROUTE table in CONFIG_DB are applied. CONFIG_DB example:
Static routes:
Which release branch to backport (provide reason below if selected)
Description for the changelog
A picture of a cute animal (not mandatory but encouraged)