bgpd: new vpn-policy CLI#1913
Conversation
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-2944/ This is a comment from an EXPERIMENTAL automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings:CLANG Static Analyzer Summary
19 Static Analyzer issues remaining.See details at |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-2945/ This is a comment from an EXPERIMENTAL automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings:CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base19 Static Analyzer issues remaining.See details at |
|
Hi @paulzlabn - the changes look fine in general from a "vpn" perspective. I have a couple of comments inline. |
| @@ -107,11 +107,8 @@ static inline int vpn_leak_to_vpn_active(struct bgp *bgp_vrf, afi_t afi, | |||
| } | |||
There was a problem hiding this comment.
In this function (vpn_leak_to_vpn_active), there is no check on instance type. Of course, that is not changed in this commit, but I happened to compare with its counterpart below (vpn_leak_from_vpn_active) which has the check.
| @@ -107,11 +107,8 @@ static inline int vpn_leak_to_vpn_active(struct bgp *bgp_vrf, afi_t afi, | |||
| } | |||
There was a problem hiding this comment.
Again, not modified by this commit, but isn't there a repetition in function vpn_leak_postchange() for the TOVPN case - vpn_leak_from_vrf_update_all() called twice?
There was a problem hiding this comment.
Removed duplicate call, not sure how that sneaked in there. Thanks!
| "rt <fromvpn|tovpn|both> RTLIST...", | ||
| DEFPY (af_rt_vpn_imexport, | ||
| af_rt_vpn_imexport_cmd, | ||
| "[no] <rt|route-target> vpn <import|export|both>$direction_str RTLIST...", |
There was a problem hiding this comment.
It appears that an add/configure operation will replace RTs and a no/delete operation will remove all RTs. Is that correct? If yes, I need to think about it because I think we'll want "additive" capability and selective delete. Of course, could be added subsequently, but IIRC, we support it now for EVPN.
There was a problem hiding this comment.
Yes, current behavior is to replace.
Maybe "add rt vpn ... RTLIST..." or "rt vpn ... + RTLIST..."? It would probably be good to make "add" vs. "replace" semantics explicit.
Are there other parts of the FRR CLI that support additive vs. replacement behavior?
| @@ -6477,10 +6418,18 @@ DEFUN (vpn_policy_rt, | |||
|
|
|||
| vpn_leak_prechange(dir, afi, bgp_get_default(), bgp); | |||
There was a problem hiding this comment.
I don't see a check on whether import or export is enabled for this VRF or not. Without that, the pre and post change operations may walk routing tables before they bail out. Or maybe it is there some place that I missed? This comment may apply to other handlers too.
| bgp->vpn_policy[afi].rtlist[dir] = NULL; | ||
| } | ||
|
|
||
| vpn_leak_postchange(dir, afi, bgp_get_default(), bgp); |
There was a problem hiding this comment.
If the no/delete removes all RTs, isn't postchange operation unnecessary? It bails out if RT is not there way into the code.
There was a problem hiding this comment.
I'm wary of removing this call here because it would not be obvious (to someone working on the code later) that this optimization can be or has been done. In the interest of avoiding future confusion by preserving a consistent design pattern of "prechange; change; postchange" I would prefer to leave this call in.
|
One general comment. RD_SET is currently used to denote both presence of RD and configuration of RD. When auto-RD supported is added later on, these two notions need to be separated out (or the presence checks removed). |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
|
@vivek-cumulus wrote:
Maybe we could indicate auto-RD via RD_SET + tovpn_rd.family = AF_UNSPEC. |
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an EXPERIMENTAL automated CI system. Get source and apply patch from patchwork: SuccessfulBuilding Stage: FailedOmniOS amd64 build: Successful OpenBSD60 amd64 build: FailedMake failed for OpenBSD60 amd64 build Warnings Generated during build:Checkout code: Successful with additional warnings:OpenBSD60 amd64 build: FailedMake failed for OpenBSD60 amd64 build |
|
NetDEF-CI wrote: Artifact of new doc organization? |
|
So this is the VTY for configuring RD/RT per BGP instance. |
bgpd/bgp_vty.c
Outdated
| bgp_imexport_vpn_cmd, | ||
| "[no] <import|export>$direction_str vpn", | ||
| "Export routes to another routing protocol\n" | ||
| "to VPN RIB per vpn-policy") |
There was a problem hiding this comment.
Please add the correct help strings, we are missing some here.
There was a problem hiding this comment.
Thanks for catching; fixed.
|
The first commit really needs a bit more explanation of what it is implementing instead of assuming the person knows what it is. Have we updated the doc/XXX with these cli changes yet? I do not see it yet. |
9347540 to
dc767ba
Compare
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-2992/ This is a comment from an EXPERIMENTAL automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings:CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base19 Static Analyzer issues remaining.See details at |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
|
@pguibert6WIND wrote:
I might misunderstand what you are asking, so if I did not answer your question, please let me know. vrf-policy should no longer be needed. The code in this PR supports multiple VRFs per bgpd. Here is an example from bgpd.conf: |
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-2993/ This is a comment from an EXPERIMENTAL automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings:CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base19 Static Analyzer issues remaining.See details at |
PR FRRouting#1739 added code to leak routes between (default VRF) VPN safi and unicast RIBs in any VRF. That set of changes included temporary CLI including vpn-policy blocks to specify RD/RT/label/&c. After considerable discussion, we arrived at a consensus CLI shown below. The code of this PR implements the vpn-specific parts of this syntax: router bgp <as> [vrf <FOO>] address-family <afi> unicast rd (vpn|evpn) export (AS:NN | IP:nn) label (vpn|evpn) export (0..1048575) rt (vpn|evpn) (import|export|both) RTLIST... nexthop vpn (import|export) (A.B.C.D | X:X::X:X) route-map (vpn|evpn|vrf NAME) (import|export) MAP [no] import|export [vpn|evpn|evpn8] [no] import|export vrf NAME User documentation of the vpn-specific parts of the above syntax is in PR FRRouting#1937 Signed-off-by: G. Paul Ziemba <paulz@labn.net>
…h fix
- vpn_leak_to_vpn_active(): check instance type
- vpn_leak_prechange(): qualify with test for active
- vpn_leak_postchange(): remove duplicated call to
vpn_leak_from_vrf_update_all()
- bgp_vty.c: Avoid null-pointer dereference for command "no rt vpn import"
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
b4984b2 to
c7109e0
Compare
|
@donaldsharp wrote:
Updated message of first commit with more detail. Documentation of new CLI now in PR #1937 |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-2996/ This is a comment from an EXPERIMENTAL automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings:CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base19 Static Analyzer issues remaining.See details at |
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-2997/ This is a comment from an EXPERIMENTAL automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings:CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base19 Static Analyzer issues remaining.See details at |
PR #1739 added code to leak routes between (default VRF) VPN safi and unicast RIBs in any VRF. That set of changes included temporary CLI including
vpn-policyblocks to specify RD/RT/label/&c. After considerable discussion, we arrived at a consensus CLI shown below.The code of this PR implements the vpn-specific parts of this syntax:
User documentation of the vpn-specific parts of the above syntax is in PR #1937