]> git.proxmox.com Git - mirror_frr.git/commit
lib: Introducing a 3rd state for route-map match cmd: RMAP_NOOP
authorLakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Wed, 19 Jun 2019 21:04:36 +0000 (14:04 -0700)
committerLakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Mon, 22 Jul 2019 15:08:13 +0000 (08:08 -0700)
commitb68885f9b7fecc50b74c86801c3aee31b62aa061
treec506a6cb5e8e98c0dc1968dcd8001eb368fa0706
parentf1b9024dd5d194d9032c1bde4402b53609389d42
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>
18 files changed:
bgpd/bgp_evpn.c
bgpd/bgp_route.c
bgpd/bgp_routemap.c
bgpd/bgp_rpki.c
bgpd/bgp_updgrp_adv.c
eigrpd/eigrp_routemap.c
isisd/isis_routemap.c
lib/routemap.c
lib/routemap.h
ospf6d/ospf6_asbr.c
ospfd/ospf_routemap.c
ospfd/ospf_zebra.c
ripd/rip_routemap.c
ripngd/ripng_routemap.c
zebra/redistribute.c
zebra/zebra_nhg.c
zebra/zebra_rnh.c
zebra/zebra_routemap.c