-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[bgp] Add 'allow list' manager feature #5513
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
Merged
pavel-shirshov
merged 21 commits into
sonic-net:master
from
pavel-shirshov:pavelsh/allow_list_feature
Oct 2, 2020
Merged
[bgp] Add 'allow list' manager feature #5513
pavel-shirshov
merged 21 commits into
sonic-net:master
from
pavel-shirshov:pavelsh/allow_list_feature
Oct 2, 2020
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
would you highlight the change between this one and the last one that has been commited? easier to review that. |
the last commit in this branch it what I changed 5fc465f |
@lguohan We need, but I afraid it will break something else. Previously bgpcfgd worked without swsscommon as a dependency. So I try to make the changes as minimal as possible. |
lguohan
approved these changes
Oct 2, 2020
abdosi
pushed a commit
that referenced
this pull request
Oct 6, 2020
implements a new feature: "BGP Allow list." This feature allows us to control which IP prefixes are going to be advertised via ebgp from the routes received from EBGP neighbors.
santhosh-kt
pushed a commit
to santhosh-kt/sonic-buildimage
that referenced
this pull request
Feb 25, 2021
implements a new feature: "BGP Allow list." This feature allows us to control which IP prefixes are going to be advertised via ebgp from the routes received from EBGP neighbors.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements a new feature: "BGP Allow list." The previous PR was reverted because installation of swsscommon module interfere with thermalcontrol tests.
This feature allows us to control which IP prefixes are going to be advertised via ebgp from the routes received from EBGP neighbors.
The feature can be enabled or disabled using "allow_list_enabled" flag in the /etc/sonic/deployment_id_asn_map.yml`
There is another flag for the feature: default_action. When this flag is equal "permit", this feature will not drop any BGP prefixes. The prefixes will be marked with drop_community. It is useful for debugging. But when the flag is equal to "deny", all prefixes, which are not explicitly listed as "Allowed" will be marked with no-export community which prevent them from being exported to ebgp neighbors.
We use prefix-lists for each list of filtered prefixes. You can add default entries which are going to be inserted to the prefix-list to default_pl_rules
We can control the feature by using the following schema:
The schema above means the following:
a. Import IPv4 prefixes "10.20.0.0/16" and "10.50.1.0/29" only if they have associated BGP community "1010:1010".
b. Import IPv6 prefixes "fc01:10::/64" and "fc02:20::/64" only if they have associated BGP community "1010:1010".
c. Import IPv4 prefixes "10.20.0.0/16" and "10.50.1.0/29". The community is not required.
d. Import IPv6 prefixes "fc01:10::/64" and "fc02:20::/64". The community is not required.
All other prefixes will be either marked or dropped (depends on the "default_action" flag. see above for "allow_list_default_action").
When BGP starts and this feature is enabled, all prefixes are going to be either marked with the community or marked with "no-export" community. That depends on "default_action" flag.
The following BGP configuration is generated by default:
When we apply the configuration you can find on the top of this PR description, the following BGP configuration will be generated.
As you can see from the output above the feature is isolated inside of "ALLOW_LIST_DEPLOYMENT_ID_0_V4" and "ALLOW_LIST_DEPLOYMENT_ID_0_V6" route-maps. We call the route-maps on top of each "FROM" route-map for each deployment_id. When the "ALLOW_LIST_DEPLOYMENT_ID_0_V*" route-map evaluation returns "deny", the "FROM" route-map will return deny. But when "ALLOW_LIST_DEPLOYMENT_ID_0_V*" route-map evaluation returns "permit", the next "FROM" route-map entry will be evaluated.
After each change of configuration the feature "restart" all bgp neighbors. Both IPv4 and IPv6 neighbors restart in the soft mode.
To change a list of prefixes inside of each record, you can apply the new list of prefixes with the same key. bgpcfgd will update corresponding prefix-lists automatically.
- Why I did it
I implemented the new feature. See the description above.
- How I did it
I introduced a new functionality into bgpcfgd. All code mostly isolated inside of BGPAllowListMgr class. Also I made some changes inside of bgp jinja2 templates.
- How to verify it
sonic-cfggen -j test_schema.conf --write-to-db
. After that you can useshow runningconfiguration bgp
to check the changed configuration. Also take a look into /var/log/syslog. There you can find the following output:After that you can use
show runningconfiguration bgp
to check the changed configuration.Test coverage data
- Which release branch to backport (provide reason below if selected)
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)