Calling a routemap does not handle things as expected

Bugs
1

I have two rout maps which I apply to a BGP import, the first is responsible for setting informational communities and the second one does the actual filtering. However it still allows RPKI invalid routes to pass.

route-map rm-as41051-in {
     rule 1 {
         action permit
         call rm-internet-in
         set {
             large-community {
                 add 213422:1:41051
             }
         }
     }
 }

route-map rm-internet-in {
     rule 1 {
         action deny
         match {
             as-path apl-bogon-asns
         }
     }
     rule 2 {
         action deny
         match {
             ipv6 {
                 address {
                     prefix-list pl6-bogons
                 }
             }
         }
     }
     rule 3 {
         action deny
         match {
             ipv6 {
                 address {
                     prefix-list pl6-tiny-prefix
                 }
             }
         }
     }
     rule 4 {
         action deny
         match {
             rpki invalid
         }
     }
     rule 5 {
         action deny
         match {
             ipv6 {
                 address {
                     prefix-list pl6-ixp-lan
                 }
             }
         }
     }
     rule 65535 {
         action permit
         set {
             large-community {
                 add 213422:0:3
             }
         }
     }
 }

Does anyone know why the call does not do what I expect it to?
I’m on Stream Q2

2

The accept/deny decision is in the caller. The call only runs the callee for side affects, (matches/sets) and discards the accept/deny in the called route-map.

I believe that is how it is. Please verify.

3

That would Match the observed behavior as the permit rule Sets it’s community. However this would contradict the FRR documentation which states:

Call route-map name. If it returns deny, deny the route and finish processing the route-map.

Maybe I need to file a bug report.

4

If it is indeed a bug, it should be easy to reproduce with a very basic config. Unless there is some nuance with your set of rules that triggers the bug.

5

I have now run a quick test with the following route maps:

set policy route-map rm-allowall rule 1 action ‘permit’
set policy route-map rm-allowall rule 1 set local-preference ‘1000’

set policy route-map rm-denyall rule 1 action ‘deny’
set policy route-map rm-denyall rule 1 set local-preference ‘4000’

set policy route-map rm-calling rule 1 action ‘permit’
set policy route-map rm-calling rule 1 call ‘rm-allowall’

After applying rm-calling to a bgp session the routes are permitted and set to local_pref 1000.

run show bgp vrf net neighbors 2a0f:85c1:b7a::c1:1 routes

BGP table version is 338749158, local router ID is 0.0.14.0, vrf id 5
Default local pref 100, local AS 213422
Status codes:  s suppressed, d damped, h history, \* valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop’s vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

V\*> 2a0f:85c1:b7e::/48
fe80::f8a2:36ff:fe86:6304
1000      0 213416 ?

After switch rm-calling to call rm-denyall the route is denied as expected.

That indicates to me that route-maps work as documented just not in my case. But I don’t know why.