Skip to content
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

Merged
merged 5 commits into from
Apr 8, 2021

Conversation

shi-su
Copy link
Contributor

@shi-su shi-su commented Apr 5, 2021

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_ROUTE": {
    "10.1.1.0/24": {
        "nexthop": "10.0.0.57,10.0.0.59"
    },
    "default|10.1.2.0/24": {
        "nexthop": "10.0.0.57,10.0.0.59", 
        "ifname": "PortChannel0001,PortChannel0002", 
        "distance": "10,10", 
        "blackhole": "false,false"
    },
    "default|10.1.3.0/24": {
        "blackhole": "true"
    },
    "default|fc00:10::/64": {
        "nexthop": "fc00::72", 
        "ifname": "PortChannel0001", 
        "distance": "10", 
        "nexthop-vrf": "default", 
        "blackhole": "false"
    }
}

Static routes:

admin@vlab-01:~$ show ip route static
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

S>* 0.0.0.0/0 [200/0] via 10.250.0.1, eth0, weight 1, 00:00:34
S>* 10.1.1.0/24 [1/0] via 10.0.0.57, PortChannel0001, weight 1, 00:00:20
  *                   via 10.0.0.59, PortChannel0002, weight 1, 00:00:20
S>* 10.1.2.0/24 [10/0] via 10.0.0.57, PortChannel0001, weight 1, 00:00:20
  *                    via 10.0.0.59, PortChannel0002, weight 1, 00:00:20
S>* 10.1.3.0/24 [1/0] unreachable (blackhole), weight 1, 00:00:30

admin@vlab-01:~$ show ipv6 route static
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

S>* fc00:1::/64 [1/0] is directly connected, Loopback0, weight 1, 00:01:09
S>* fc00:10::/64 [10/0] via fc00::72, PortChannel0001, weight 1, 00:01:05

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012

Description for the changelog

A picture of a cute animal (not mandatory but encouraged)

@shi-su shi-su requested a review from lguohan as a code owner April 5, 2021 21:04
@shi-su shi-su requested a review from prsunny April 5, 2021 21:04
}),
True,
[
"ip route 10.1.2.0/24 blackhole 10"
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

@venkatmahalingam venkatmahalingam Apr 6, 2021

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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

Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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)
Copy link
Collaborator

@venkatmahalingam venkatmahalingam Apr 6, 2021

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.?

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

@lguohan
Copy link
Collaborator

lguohan commented Apr 6, 2021

@prsunny

Copy link
Contributor

@prsunny prsunny left a 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
Copy link
Contributor

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

Copy link
Contributor Author

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",
Copy link
Contributor

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?

Copy link
Contributor Author

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:
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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",
Copy link
Contributor

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

Copy link
Contributor Author

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.

@shi-su shi-su requested a review from prsunny April 7, 2021 16:10
@prsunny
Copy link
Contributor

prsunny commented Apr 7, 2021

@venkatmahalingam , could you please re-review/sign-off?

@shi-su shi-su merged commit 42059ac into sonic-net:master Apr 8, 2021
@shi-su shi-su deleted the static_route branch April 8, 2021 20:52
raphaelt-nvidia pushed a commit to raphaelt-nvidia/sonic-buildimage that referenced this pull request May 23, 2021
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.
qiluo-msft pushed a commit that referenced this pull request May 24, 2021
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.
carl-nokia pushed a commit to carl-nokia/sonic-buildimage that referenced this pull request Aug 7, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants