summaryrefslogtreecommitdiffstats
path: root/zebra/redistribute.c
diff options
context:
space:
mode:
authorLakshman Krishnamoorthy <lkrishnamoor@vmware.com>2019-06-19 23:04:36 +0200
committerLakshman Krishnamoorthy <lkrishnamoor@vmware.com>2019-07-22 17:08:13 +0200
commitb68885f9b7fecc50b74c86801c3aee31b62aa061 (patch)
treec506a6cb5e8e98c0dc1968dcd8001eb368fa0706 /zebra/redistribute.c
parentMerge pull request #4688 from qlyoung/alpine-docker-rpki (diff)
downloadfrr-b68885f9b7fecc50b74c86801c3aee31b62aa061.tar.xz
frr-b68885f9b7fecc50b74c86801c3aee31b62aa061.zip
lib: Introducing a 3rd state for route-map match cmd: RMAP_NOOP
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: State1: If match cmd returns RMAP_MATCH then, keep existing behaviour. If routemap type is PERMIT, execute set cmds or call cmds if applicable, otherwise PERMIT! Else If routemap type is DENY, we DENYMATCH right away State2: If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH 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. Also, this rule should be applicable for routes with VNI label only, and not for routes without labels. For example, type 3 and type 4 EVPN routes do not have labels, so, this match cmd should let them through. 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 to indicate that it encountered an invalid check, and needs to abort just that rule, but continue with other rules. As a result we have a 3rd state: State3: If match cmd returned RMAP_NOOP Then, proceed to other route-map, otherwise if there are no more rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH. Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Diffstat (limited to 'zebra/redistribute.c')
-rw-r--r--zebra/redistribute.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/zebra/redistribute.c b/zebra/redistribute.c
index d56579ff4..0280cde23 100644
--- a/zebra/redistribute.c
+++ b/zebra/redistribute.c
@@ -574,7 +574,7 @@ int zebra_add_import_table_entry(struct zebra_vrf *zvrf, struct route_node *rn,
struct route_entry *newre;
struct route_entry *same;
struct prefix p;
- route_map_result_t ret = RMAP_MATCH;
+ route_map_result_t ret = RMAP_PERMITMATCH;
afi_t afi;
afi = family2afi(rn->p.family);
@@ -583,7 +583,7 @@ int zebra_add_import_table_entry(struct zebra_vrf *zvrf, struct route_node *rn,
afi, re->type, re->instance, &rn->p, re->ng.nexthop,
zvrf->vrf->vrf_id, re->tag, rmap_name);
- if (ret != RMAP_MATCH) {
+ if (ret != RMAP_PERMITMATCH) {
UNSET_FLAG(re->flags, ZEBRA_FLAG_SELECTED);
zebra_del_import_table_entry(zvrf, rn, re);
return 0;