BGP reflection, no filtering?

RouterOS Forwarding Protocols
1

Hi,

Is it a known design quirk that route filters do not apply to reflected prefixes on a RouterOS route reflector?

We have filters in place to change local preference when processing prefixes from another region so that local preference results in the following preference order:

  • Local customers
  • Remote customers
  • Local peers
  • Remote peers
  • Local transit
  • Remote transit

It appears that prefixes received from a router in another region are correctly installed in to the route reflector’s own routing table with the correct local preference set but other peers receive the prefixes without modification. We have additional FRRouting route reflectors which apply filters and also reflect routes which do not behave in this manner.



Sample route filter entries from a RouterOS route reflector:

add bgp-local-pref=150 chain=peer-rr-regional-in set-bgp-local-pref=130
add bgp-local-pref=149 chain=peer-rr-regional-in set-bgp-local-pref=129
add bgp-local-pref=148 chain=peer-rr-regional-in set-bgp-local-pref=128
add bgp-local-pref=147 chain=peer-rr-regional-in set-bgp-local-pref=127
add bgp-local-pref=146 chain=peer-rr-regional-in set-bgp-local-pref=126
add bgp-local-pref=145 chain=peer-rr-regional-in set-bgp-local-pref=125

Sample router filter entries from a FRRouting route reflector:

route-map peer-rr-regional-in permit 100
 match local-preference 150
 on-match goto 1000
 set local-preference 130
!
route-map peer-rr-regional-in permit 110
 match local-preference 149
 on-match goto 1000
 set local-preference 129
!
route-map peer-rr-regional-in permit 120
 match local-preference 148
 on-match goto 1000
 set local-preference 128
!
route-map peer-rr-regional-in permit 130
 match local-preference 147
 on-match goto 1000
 set local-preference 127
!
route-map peer-rr-regional-in permit 140
 match local-preference 146
 on-match goto 1000
 set local-preference 126
!
route-map peer-rr-regional-in permit 150
 match local-preference 145
 on-match goto 1000
 set local-preference 125
!



Resulting routing table on a route reflector client:

[admin@testing] > ip route print detail where dst-address=41.217.247.0/24
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
       B - blackhole, U - unreachable, P - prohibit
 0 ADb  dst-address=41.217.247.0/24 pref-src=10.0.11.1 gateway=10.0.66.1 gateway-status=10.0.66.1 recursive
        via 192.0.2.229 vlan3 distance=200 scope=40 target-scope=30 bgp-as-path="37482" bgp-local-pref=150
        bgp-origin=igp bgp-communities=64500:1002 received-from=RouterOS_RR1

 1  Db  dst-address=41.217.247.0/24 pref-src=10.0.11.1 gateway=10.0.66.1 gateway-status=10.0.66.1 recursive
        via 192.0.2.229 vlan3 distance=200 scope=40 target-scope=30 bgp-as-path="37482" bgp-local-pref=150
        bgp-origin=igp bgp-communities=64500:1002 received-from=RouterOS_RR2

 2  Db  dst-address=41.217.247.0/24 pref-src=10.0.11.1 gateway=10.0.66.1 gateway-status=10.0.66.1 recursive
        via 192.0.2.229 vlan3 distance=200 scope=40 target-scope=30 bgp-as-path="37482" bgp-local-pref=130
        bgp-med=0 bgp-origin=igp bgp-communities=64500:1002 received-from=FRR_RR1

 3  Db  dst-address=41.217.247.0/24 pref-src=10.0.11.1 gateway=10.0.66.1 gateway-status=10.0.66.1 recursive
        via 192.0.2.229 vlan3 distance=200 scope=40 target-scope=30 bgp-as-path="37482" bgp-local-pref=130
        bgp-med=0 bgp-origin=igp bgp-communities=64500:1002 received-from=FRR_RR2

Regards
David Herselman

2

A few questions:

  1. What version or versions of RouterOS are involved?
  2. Are the RR clients all MikroTIk/RouterOS or are there other NOS?
3

Most reflector clients are RouterOS with the MikroTik route reflectors being 6.45.7. We are in the process of upgrading all core routers to 6.46.2.

The FRRouting route reflectors are running 7.4-dev with all patches applied up until the 21st of January 2020.

It appears to me that RouterOS configured as a route reflectors simply reflect prefixes as they were received and only applied routing filters when installing prefixes in the main routing table.


Regards
David Herselman

4

It looks like you’re applying this on routes learned inbound. Have you tried applying a similar policy to the routes as they are advertised out to the RR clients?

5

I’ve disabled the IPv4 and IPv6 protocol families on the RouterOS route reflectors to exclusively use them for l2vpn whilst FRR route reflectors handle IPv4/6. Convergence is many times faster, most probably simply due to it supporting peer groups, and processes prefixes in a twentieth of the time RouterOS took. I’ll construct a lab in the next couple of days and then log a query with support…

I don’t ever remember reading anywhere that RouterOS would apply filters to prefixes processed locally, but then reflect the same prefixes as they were received originally.


Regards
David Herselman