-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bgpcfgd] Add bgpcfgd support for static routes #7233
Conversation
}), | ||
True, | ||
[ | ||
"ip route 10.1.2.0/24 blackhole 10" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this feature consider mgmt route as well? e.g mgmt route in default & mgmt VRFs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we test save & restore for STATIC_ROUTE table?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add test cases with other L3 interfaces as well e.g PHY/VLAN..etc.?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you have added the test cases with Ethernet already, thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please rename this file to managers_static_rt.py
to be consistent with existing files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -53,6 +54,8 @@ def do_work(): | |||
BGPAllowListMgr(common_objs, "CONFIG_DB", "BGP_ALLOWED_PREFIXES"), | |||
# BBR Manager | |||
BBRMgr(common_objs, "CONFIG_DB", "BGP_BBR"), | |||
# Static Route Managers | |||
StaticRouteMgr(common_objs, "CONFIG_DB", "STATIC_ROUTE"), | |||
] | |||
runner = Runner(common_objs['cfg_mgr']) | |||
for mgr in managers: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolving nexthop in RouteOrch is our next step for the static route tasks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please also have a test to remove one nexthop
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)