diff options
author | Lakshman Krishnamoorthy <lkrishnamoor@vmware.com> | 2019-06-19 23:04:36 +0200 |
---|---|---|
committer | Lakshman Krishnamoorthy <lkrishnamoor@vmware.com> | 2019-07-22 17:08:13 +0200 |
commit | b68885f9b7fecc50b74c86801c3aee31b62aa061 (patch) | |
tree | c506a6cb5e8e98c0dc1968dcd8001eb368fa0706 /zebra/redistribute.c | |
parent | Merge pull request #4688 from qlyoung/alpine-docker-rpki (diff) | |
download | frr-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.c | 4 |
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; |