-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
bgpd: Filtering received EVPN routes based on VNI does not work #4078
Conversation
💚 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-7127/ This is a comment from an automated CI system. clang_check |
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: FailedCentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7230/artifact/CI005BUILD/config.status/config.statusPackage building failed for CentOS 7 amd64 build:
CentOS 6 amd64 build: Failed (click for details)CentOS 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7230/artifact/CI006BUILD/config.status/config.statusPackage building failed for CentOS 6 amd64 build:
Successful on other platforms
Warnings Generated during build:Checkout code: Successful with additional warningsCentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7230/artifact/CI005BUILD/config.status/config.statusPackage building failed for CentOS 7 amd64 build:
CentOS 6 amd64 build: Failed (click for details)CentOS 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7230/artifact/CI006BUILD/config.status/config.statusPackage building failed for CentOS 6 amd64 build:
|
💚 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 |
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-7234/ This is a comment from an 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 base66 Static Analyzer issues remaining.See details at |
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.
LGTM after the most recent pushes; will wait a couple of days and merge if no-one else comments. :-)
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
665dc91
to
b513aaa
Compare
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: FailedCentOS 6 amd64 build: Failed (click for details)CentOS 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7368/artifact/CI006BUILD/config.status/config.statusPackage building failed for CentOS 6 amd64 build:
CentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7368/artifact/CI005BUILD/config.status/config.statusPackage building failed for CentOS 7 amd64 build:
Successful on other platforms
Warnings Generated during build:Checkout code: Successful with additional warningsCentOS 6 amd64 build: Failed (click for details)CentOS 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7368/artifact/CI006BUILD/config.status/config.statusPackage building failed for CentOS 6 amd64 build:
CentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7368/artifact/CI005BUILD/config.status/config.statusPackage building failed for CentOS 7 amd64 build:
|
💚 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-7367/ This is a comment from an automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings
CLANG Static Analyzer Summary
Fixed warnings:
New warnings:
Static Analysis warning summary compared to base:
66 Static Analyzer issues remaining.See details at |
f2189da
to
fd8bc15
Compare
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: FailedUbuntu 16.04 i386 build: Failed (click for details)Ubuntu 16.04 i386 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/U1604I386/config.status/config.statusMake failed for Ubuntu 16.04 i386 build:
OmniOS amd64 build: Failed (click for details)OmniOS amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI010BUILD/config.status/config.statusMake failed for OmniOS amd64 build:
Debian 9 amd64 build: Failed (click for details)Debian 9 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI021BUILD/config.status/config.statusMake failed for Debian 9 amd64 build:
NetBSD 7 amd64 build: Failed (click for details)NetBSD 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI012BUILD/config.status/config.statusMake failed for NetBSD 7 amd64 build:
Ubuntu 16.04 amd64 build: Failed (click for details)Ubuntu 16.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI014BUILD/config.status/config.statusMake failed for Ubuntu 16.04 amd64 build:
CentOS 6 amd64 build: Failed (click for details)CentOS 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI006BUILD/config.status/config.statusMake failed for CentOS 6 amd64 build:
CentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI005BUILD/config.status/config.statusMake failed for CentOS 7 amd64 build:
Ubuntu 14.04 amd64 build: Failed (click for details)Ubuntu 14.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI001BUILD/config.status/config.statusMake failed for Ubuntu 14.04 amd64 build:
Debian 8 amd64 build: Failed (click for details)Debian 8 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI008BLD/config.status/config.statusMake failed for Debian 8 amd64 build:
OpenBSD 6 amd64 build: Failed (click for details)OpenBSD 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI011BUILD/config.status/config.statusMake failed for OpenBSD 6 amd64 build:
FreeBSD 11 amd64 build: Failed (click for details)FreeBSD 11 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI009BUILD/config.status/config.statusMake failed for FreeBSD 11 amd64 build:
NetBSD 6 amd64 build: Failed (click for details)NetBSD 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI007BUILD/config.status/config.statusMake failed for NetBSD 6 amd64 build:
Ubuntu 18.04 amd64 build: Failed (click for details)Ubuntu 18.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/U1804AMD64/config.status/config.statusMake failed for Ubuntu 18.04 amd64 build:
Successful on other platforms
Warnings Generated during build:Checkout code: Successful with additional warningsUbuntu 16.04 i386 build: Failed (click for details)Ubuntu 16.04 i386 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/U1604I386/config.status/config.statusMake failed for Ubuntu 16.04 i386 build:
OmniOS amd64 build: Failed (click for details)OmniOS amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI010BUILD/config.status/config.statusMake failed for OmniOS amd64 build:
Debian 9 amd64 build: Failed (click for details)Debian 9 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI021BUILD/config.status/config.statusMake failed for Debian 9 amd64 build:
NetBSD 7 amd64 build: Failed (click for details)NetBSD 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI012BUILD/config.status/config.statusMake failed for NetBSD 7 amd64 build:
Ubuntu 16.04 amd64 build: Failed (click for details)Ubuntu 16.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI014BUILD/config.status/config.statusMake failed for Ubuntu 16.04 amd64 build:
CentOS 6 amd64 build: Failed (click for details)CentOS 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI006BUILD/config.status/config.statusMake failed for CentOS 6 amd64 build:
CentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI005BUILD/config.status/config.statusMake failed for CentOS 7 amd64 build:
Ubuntu 14.04 amd64 build: Failed (click for details)Ubuntu 14.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI001BUILD/config.status/config.statusMake failed for Ubuntu 14.04 amd64 build:
Debian 8 amd64 build: Failed (click for details)Debian 8 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI008BLD/config.status/config.statusMake failed for Debian 8 amd64 build:
OpenBSD 6 amd64 build: Failed (click for details)OpenBSD 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI011BUILD/config.status/config.statusMake failed for OpenBSD 6 amd64 build:
FreeBSD 11 amd64 build: Failed (click for details)FreeBSD 11 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI009BUILD/config.status/config.statusMake failed for FreeBSD 11 amd64 build:
NetBSD 6 amd64 build: Failed (click for details)NetBSD 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/CI007BUILD/config.status/config.statusMake failed for NetBSD 6 amd64 build:
Ubuntu 18.04 amd64 build: Failed (click for details)Ubuntu 18.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7370/artifact/U1804AMD64/config.status/config.statusMake failed for Ubuntu 18.04 amd64 build:
|
💚 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 |
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-7369/ This is a comment from an automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings
CLANG Static Analyzer Summary
Fixed warnings:
New warnings:
Static Analysis warning summary compared to base:
66 Static Analyzer issues remaining.See details at |
rebase off of current master and force push the changes and clean up the format issues then I'll look at it. |
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-7371/ This is a comment from an automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings
CLANG Static Analyzer Summary
66 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-7372/ This is a comment from an automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings
CLANG Static Analyzer Summary
66 Static Analyzer issues remaining.See details at |
@donaldsharp Lakshman did rebase and all tests passed after that. |
@srimohans -> no way anything was rebased w/ 66 SA warnings left |
still looks like it needs a rebase to me... :-) |
@donaldsharp @riw777 I respectfully agree with both of you :) |
Created 2 separate PRs #4314 and #4315 for the lib/routemap.c change, and extract tunnel type change. @donaldsharp @vivek-cumulus @srimohans @louberger |
45974c2
to
351d8d3
Compare
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: FailedCentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7637/artifact/CI005BUILD/config.status/config.statusPackage building failed for CentOS 7 amd64 build:
CentOS 6 amd64 build: Failed (click for details)CentOS 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7637/artifact/CI006BUILD/config.status/config.statusPackage building failed for CentOS 6 amd64 build:
Successful on other platforms
Warnings Generated during build:Checkout code: Successful with additional warningsCentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7637/artifact/CI005BUILD/config.status/config.statusPackage building failed for CentOS 7 amd64 build:
CentOS 6 amd64 build: Failed (click for details)CentOS 6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7637/artifact/CI006BUILD/config.status/config.statusPackage building failed for CentOS 6 amd64 build:
|
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
351d8d3
to
1ed974c
Compare
💚 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-7654/ This is a comment from an 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 base12 Static Analyzer issues remaining.See details at |
Introducing a 3rd state for route_map_apply library function: RMAP_OKAY Traditionally route map rule apis were designed to return a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH. Depending on this response, the following statemachine decided the course of action: State1: Receveived RMAP_MATCH THEN: If Routemap type is PERMIT, execute other rules if applicable, otherwise we PERMIT! Else: If Routemap type is DENY, we DENYMATCH right away State2: Received RMAP_NOMATCH, continue on to next rule, otherwise, return DENYMATCH by default if nothing matched. With reference to PR 4078 (FRRouting#4078), we require a 3rd state because of the following situation: The issue - what if, the rule api needs to abort or ignore a rule?: "match evpn vni xx" route-map filter can be applied to incoming routes regardless of whether the tunnel type is vxlan or mpls. This rule should be N/A for mpls based evpn route, but applicable to only vxlan based evpn route. Today, the filter produces either a match or nomatch response regardless of whether it is mpls/vxlan, resulting in either permitting or denying the route.. So an mpls evpn route may get filtered out incorrectly. Eg: "route-map RM1 permit 10 ; match evpn vni 20" or "route-map RM2 deny 20 ; match vni 20" With the introduction of the 3rd state, we can abort this rule check safely. How? The rules api can now return RMAP_OKAY (or another enum) to indicate that it encountered an invalid check, and needs to abort just that rule, but continue with other rules. Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR as the 3rd state (or create a new enum like RMAP_IGNORE)? We chose to go with RMAP_OKAY (but open to ideas), as a way to bypass the rmap filter As a result we have a 3rd state: State3: Received RMAP_OKAY Then, proceed to other rules, otherwise return RMAP_OKAY by default. Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Introducing a 3rd state for route_map_apply library function: RMAP_OKAY Traditionally route map rule apis were designed to return a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH. Depending on this response, the following statemachine decided the course of action: State1: Receveived RMAP_MATCH THEN: If Routemap type is PERMIT, execute other rules if applicable, otherwise we PERMIT! Else: If Routemap type is DENY, we DENYMATCH right away State2: Received RMAP_NOMATCH, continue on to next rule, otherwise, return DENYMATCH by default if nothing matched. With reference to PR 4078 (FRRouting#4078), we require a 3rd state because of the following situation: The issue - what if, the rule api needs to abort or ignore a rule?: "match evpn vni xx" route-map filter can be applied to incoming routes regardless of whether the tunnel type is vxlan or mpls. This rule should be N/A for mpls based evpn route, but applicable to only vxlan based evpn route. Today, the filter produces either a match or nomatch response regardless of whether it is mpls/vxlan, resulting in either permitting or denying the route.. So an mpls evpn route may get filtered out incorrectly. Eg: "route-map RM1 permit 10 ; match evpn vni 20" or "route-map RM2 deny 20 ; match vni 20" With the introduction of the 3rd state, we can abort this rule check safely. How? The rules api can now return RMAP_OKAY (or another enum) to indicate that it encountered an invalid check, and needs to abort just that rule, but continue with other rules. Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR as the 3rd state (or create a new enum like RMAP_IGNORE)? We chose to go with RMAP_OKAY (but open to ideas), as a way to bypass the rmap filter As a result we have a 3rd state: State3: Received RMAP_OKAY Then, proceed to other rules, otherwise return RMAP_OKAY by default. Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP Traditionally route map MATCH rule apis were designed to return a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH. (Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR). Depending on this response, the following statemachine decided the course of action: Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH) State1: Receveived RMAP_MATCH THEN: If Routemap type is PERMIT, execute other rules if applicable, otherwise we PERMIT! Else: If Routemap type is DENY, we DENYMATCH right away State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise, return DENYMATCH by default if nothing matched. With reference to PR 4078 (FRRouting#4078), we require a 3rd state because of the following situation: The issue - what if, the rule api needs to abort or ignore a rule?: "match evpn vni xx" route-map filter can be applied to incoming routes regardless of whether the tunnel type is vxlan or mpls. This rule should be N/A for mpls based evpn route, but applicable to only vxlan based evpn route. Today, the filter produces either a match or nomatch response regardless of whether it is mpls/vxlan, resulting in either permitting or denying the route.. So an mpls evpn route may get filtered out incorrectly. Eg: "route-map RM1 permit 10 ; match evpn vni 20" or "route-map RM2 deny 20 ; match vni 20" With the introduction of the 3rd state, we can abort this rule check safely. How? The rules api can now return RMAP_NOOP (or another enum) to indicate that it encountered an invalid check, and needs to abort just that rule, but continue with other rules. Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR as the 3rd state (or create a new enum like RMAP_NOOP)? RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd. We chose to go with RMAP_NOOP (but open to ideas), as a way to bypass the rmap filter As a result we have a 3rd state: State3: Received RMAP_NOOP Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default. Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP Traditionally route map MATCH rule apis were designed to return a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH. (Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR). Depending on this response, the following statemachine decided the course of action: Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH) State1: Receveived RMAP_MATCH THEN: If Routemap type is PERMIT, execute other rules if applicable, otherwise we PERMIT! Else: If Routemap type is DENY, we DENYMATCH right away State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise, return DENYMATCH by default if nothing matched. With reference to PR 4078 (FRRouting#4078), we require a 3rd state because of the following situation: The issue - what if, the rule api needs to abort or ignore a rule?: "match evpn vni xx" route-map filter can be applied to incoming routes regardless of whether the tunnel type is vxlan or mpls. This rule should be N/A for mpls based evpn route, but applicable to only vxlan based evpn route. Today, the filter produces either a match or nomatch response regardless of whether it is mpls/vxlan, resulting in either permitting or denying the route.. So an mpls evpn route may get filtered out incorrectly. Eg: "route-map RM1 permit 10 ; match evpn vni 20" or "route-map RM2 deny 20 ; match vni 20" With the introduction of the 3rd state, we can abort this rule check safely. How? The rules api can now return RMAP_NOOP (or another enum) to indicate that it encountered an invalid check, and needs to abort just that rule, but continue with other rules. Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR as the 3rd state (or create a new enum like RMAP_NOOP)? RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd. We chose to go with RMAP_NOOP (but open to ideas), as a way to bypass the rmap filter As a result we have a 3rd state: State3: Received RMAP_NOOP Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default. Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
all the comments from you were addressed by submitter. Multiple reviewers had already approved this. Can you go ahead, approve & merge this ? |
CI:rerun |
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: FailedDebian 9 amd64 build: Failed (click for details)Debian 9 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI021BUILD/config.status/config.statusMake failed for Debian 9 amd64 build:
Ubuntu 18.04 ppc64le build: Failed (click for details)Ubuntu 18.04 ppc64le build: config.log output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/U1804PPC64LEBUILD/config.log/ Ubuntu 18.04 ppc64le build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/U1804PPC64LEBUILD/config.status/config.statusMake failed for Ubuntu 18.04 ppc64le build:
OmniOS amd64 build: Failed (click for details)OmniOS amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI010BUILD/config.status/config.statusMake failed for OmniOS amd64 build:
NetBSD 7 amd64 build: Failed (click for details)NetBSD 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI012BUILD/config.status/config.statusMake failed for NetBSD 7 amd64 build:
Ubuntu 16.04 amd64 build: Failed (click for details)Ubuntu 16.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI014BUILD/config.status/config.statusMake failed for Ubuntu 16.04 amd64 build:
Ubuntu 14.04 amd64 build: Failed (click for details)Ubuntu 14.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI001BUILD/config.status/config.statusMake failed for Ubuntu 14.04 amd64 build:
Ubuntu 16.04 i386 build: Failed (click for details)Ubuntu 16.04 i386 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/U1604I386/config.status/config.statusMake failed for Ubuntu 16.04 i386 build:
Debian 8 amd64 build: Failed (click for details)Debian 8 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI008BLD/config.status/config.statusMake failed for Debian 8 amd64 build:
FreeBSD 11 amd64 build: Failed (click for details)FreeBSD 11 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI009BUILD/config.status/config.statusMake failed for FreeBSD 11 amd64 build:
Fedora 29 amd64 build: Failed (click for details)Fedora 29 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/F29BUILD/config.status/config.statusMake failed for Fedora 29 amd64 build:
CentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI005BUILD/config.status/config.statusMake failed for CentOS 7 amd64 build:
FreeBSD 12 amd64 build: Failed (click for details)FreeBSD 12 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/FBSD12AMD64/config.status/config.statusMake failed for FreeBSD 12 amd64 build:
Ubuntu 18.04 amd64 build: Failed (click for details)Ubuntu 18.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/U1804AMD64/config.status/config.statusMake failed for Ubuntu 18.04 amd64 build:
Successful on other platforms
Warnings Generated during build:Checkout code: Successful with additional warningsDebian 9 amd64 build: Failed (click for details)Debian 9 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI021BUILD/config.status/config.statusMake failed for Debian 9 amd64 build:
Ubuntu 18.04 ppc64le build: Failed (click for details)Ubuntu 18.04 ppc64le build: config.log output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/U1804PPC64LEBUILD/config.log/ Ubuntu 18.04 ppc64le build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/U1804PPC64LEBUILD/config.status/config.statusMake failed for Ubuntu 18.04 ppc64le build:
OmniOS amd64 build: Failed (click for details)OmniOS amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI010BUILD/config.status/config.statusMake failed for OmniOS amd64 build:
NetBSD 7 amd64 build: Failed (click for details)NetBSD 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI012BUILD/config.status/config.statusMake failed for NetBSD 7 amd64 build:
Ubuntu 16.04 amd64 build: Failed (click for details)Ubuntu 16.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI014BUILD/config.status/config.statusMake failed for Ubuntu 16.04 amd64 build:
Ubuntu 14.04 amd64 build: Failed (click for details)Ubuntu 14.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI001BUILD/config.status/config.statusMake failed for Ubuntu 14.04 amd64 build:
Ubuntu 16.04 i386 build: Failed (click for details)Ubuntu 16.04 i386 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/U1604I386/config.status/config.statusMake failed for Ubuntu 16.04 i386 build:
Debian 8 amd64 build: Failed (click for details)Debian 8 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI008BLD/config.status/config.statusMake failed for Debian 8 amd64 build:
FreeBSD 11 amd64 build: Failed (click for details)FreeBSD 11 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI009BUILD/config.status/config.statusMake failed for FreeBSD 11 amd64 build:
Fedora 29 amd64 build: Failed (click for details)Fedora 29 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/F29BUILD/config.status/config.statusMake failed for Fedora 29 amd64 build:
CentOS 7 amd64 build: Failed (click for details)CentOS 7 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/CI005BUILD/config.status/config.statusMake failed for CentOS 7 amd64 build:
FreeBSD 12 amd64 build: Failed (click for details)FreeBSD 12 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/FBSD12AMD64/config.status/config.statusMake failed for FreeBSD 12 amd64 build:
Ubuntu 18.04 amd64 build: Failed (click for details)Ubuntu 18.04 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-7884/artifact/U1804AMD64/config.status/config.statusMake failed for Ubuntu 18.04 amd64 build:
|
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP Traditionally route map MATCH rule apis were designed to return a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH. (Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR). Depending on this response, the following statemachine decided the course of action: Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH) State1: Receveived RMAP_MATCH THEN: If Routemap type is PERMIT, execute other rules if applicable, otherwise we PERMIT! Else: If Routemap type is DENY, we DENYMATCH right away State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise, return DENYMATCH by default if nothing matched. With reference to PR 4078 (FRRouting#4078), we require a 3rd state because of the following situation: The issue - what if, the rule api needs to abort or ignore a rule?: "match evpn vni xx" route-map filter can be applied to incoming routes regardless of whether the tunnel type is vxlan or mpls. This rule should be N/A for mpls based evpn route, but applicable to only vxlan based evpn route. Today, the filter produces either a match or nomatch response regardless of whether it is mpls/vxlan, resulting in either permitting or denying the route.. So an mpls evpn route may get filtered out incorrectly. Eg: "route-map RM1 permit 10 ; match evpn vni 20" or "route-map RM2 deny 20 ; match vni 20" With the introduction of the 3rd state, we can abort this rule check safely. How? The rules api can now return RMAP_NOOP (or another enum) to indicate that it encountered an invalid check, and needs to abort just that rule, but continue with other rules. Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR as the 3rd state (or create a new enum like RMAP_NOOP)? RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd. We chose to go with RMAP_NOOP (but open to ideas), as a way to bypass the rmap filter As a result we have a 3rd state: State3: Received RMAP_NOOP Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default. Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
@donaldsharp This PR has enum dependency from: #4315 (PR 4315 has to be merged before this) to get RMAP_NOOP. |
1ed974c
to
4cc1365
Compare
Issue1: When "neighbor X.X.X.X route-map RM-VNI-FILTER in" is configured under evpn address-family, all the received routes are dropped regardless of whether the route has a matching vni or not. Issue2: Routes with 2 labels are not filtered correctly Issue3: Interpreting the label based on tunnel type, vxlan was not done correctly. Vxlan label has 24 bits, whereas, MPLS label is 20 bits long Fix1: The handler bgp_update() that services the received route ignored the route's label while deciding whether to filter it or not. As part of the fix, the handler now uses the label info to make the decision about whether to filter the route or not. Fix2: route_match_vni() now tries to match both the labels within the route, not just the one. Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
CI:rerun |
@donaldsharp @srimohans @qlyoung |
💚 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-7907/ This is a comment from an automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base11 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-7906/ This is a comment from an automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base11 Static Analyzer issues remaining.See details at |
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP Traditionally route map MATCH rule apis were designed to return a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH. (Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR). Depending on this response, the following statemachine decided the course of action: Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH) State1: Receveived RMAP_MATCH THEN: If Routemap type is PERMIT, execute other rules if applicable, otherwise we PERMIT! Else: If Routemap type is DENY, we DENYMATCH right away State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise, return DENYMATCH by default if nothing matched. With reference to PR 4078 (FRRouting#4078), we require a 3rd state because of the following situation: The issue - what if, the rule api needs to abort or ignore a rule?: "match evpn vni xx" route-map filter can be applied to incoming routes regardless of whether the tunnel type is vxlan or mpls. This rule should be N/A for mpls based evpn route, but applicable to only vxlan based evpn route. Today, the filter produces either a match or nomatch response regardless of whether it is mpls/vxlan, resulting in either permitting or denying the route.. So an mpls evpn route may get filtered out incorrectly. Eg: "route-map RM1 permit 10 ; match evpn vni 20" or "route-map RM2 deny 20 ; match vni 20" With the introduction of the 3rd state, we can abort this rule check safely. How? The rules api can now return RMAP_NOOP (or another enum) to indicate that it encountered an invalid check, and needs to abort just that rule, but continue with other rules. Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR as the 3rd state (or create a new enum like RMAP_NOOP)? RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd. We chose to go with RMAP_NOOP (but open to ideas), as a way to bypass the rmap filter As a result we have a 3rd state: State3: Received RMAP_NOOP Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default. Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Issue1: When "neighbor X.X.X.X route-map RM-VNI-FILTER in" is configured under evpn address-family,
all the received routes are dropped regardless of whether the route has a matching vni or not.
Issue2: Routes with 2 labels are not filtered correctly
Issue3: Interpreting the label based on tunnel type, vxlan was not done correctly.
Vxlan label has 24 bits, whereas, MPLS label is 20 bits long
Fix1: The handler bgp_update() that services the received route ignored the route's label while deciding whether to filter it or not. As part of the fix, the handler now uses the label info to make the decision about whether to filter the route or not.
Fix2: route_match_vni() now tries to match both the labels within the route, not just the one.
Related fix : Extract tunnel type
This fix relies on PR 4314 #4314 to extract the tunnel type from bgp extended communities. The information about the route's tunnel type (vxlan or mpls) is needed to apply "match evpn vni xx" rule. This rule is applicable to vxlan routes, and should exit safely for mpls based evpn routes.
Related fix: a 3rd state for the route map filter.
PR 4315 #4315 is crucial to this fix, because it provides a way for "match evpn vni xx" rule to safely abort the check for non-applicable routes (mpls based evpn routes)
Signed-off-by: Lakshman Krishnamoorthy lkrishnamoor@vmware.com