BGP/MPLS: Filter out routes originating from OSPF for some VRFs

[ivarstrandberg]

Hi.

I have some VRFs that are doing some leaking to each other.

VRF A redistributes OSPF and connected routes to VRFs B and C.

VRF B needs to learn them all, but VRF C must not learn VRF A's OSPF routes.

There are too many routes to simply filter them out using a prefix-list/route-map used as an import map under VRF C's address-family.

I tried making a route-map that tags the routes. Then I attached that route-map to the "redistribute ospf" statement under the BGP address-family of VRF A.

The router complained that "% "TAG-TEST-RM" used as redistribute ospf into bgp route-map, set tag not supported".

So, I instead tried to attach "TAG-TEST-RM" as an export map under VRF A's VRF address-family.

I changed the route-map so that it matches "source-protocol ospf <process ID>", and then tags the routes.

I then tried to check the BGP routes received by VRF C, but I can't see any tags. So I'm guessing this is not working as I intended either. Probably the routes are already converted from OSPF to BGP by the time the route-map kicks in.

I think setting a tag would be the safest way to mark these routes. Is is possible to tag just the OSPF routes?
Or are there some other methods that should be used instead?

[Giuseppe Larosa]

Hello Ivar,

the route tags are not propagated over the MP BGP.

What you can do is to use multiple route-targets in exporting from VRF A:

Using an export-map in VRF A you should be able to set a differente route-target for export of OSPF originated routes.

Example:

rt 100:100    ! standard for VRF A export as per  VRF A configuration

rt 100:101  ! value to be set in the export-map for routes originated in OSPF

On VRF B you will be importing both route targets values so that you receive all the routes

On VRF C you will be importing only a single route target value from VRF A rt 100:100

route-targets are BGP extended communities one or more the one can be associated to a VPNv4 NLRI.

Hope to help

Giuseppe

[Hector Gustavo Serrano Gutierrez]

Hi @ivarstrandberg,

What about setting a specific Route-Target (RT) for the OSPF routes on VRF A you want to import only on VRF B and not on VRF_C?

For instance:

route-map EXPORT_VRF_A permit 10
 match tag 123                  !or match source-protocol ospf <OSPF_ID>
 set extcommunity rt 123:123
!
route-map EXPORT_VRF_A permit 20
 match source-protocol connected
 set extcommunity rt 456:456
!
vrf definition VRF_A
 rd 1:1
 !
 address-family ipv4
  export map EXPORT_VRF_A
 exit-address-family
!  
vrf definition VRF_B
 rd 2:2
 !
 address-family ipv4
  route-target import 123:123
 exit-address-family
!
vrf definition VRF_C
 rd 3:3
 !
 address-family ipv4
  route-target import 456:456
 exit-address-family

or

route-map EXPORT_VRF_A permit 10
 match tag 123                   !or match source-protocol ospf <OSPF_ID>
 set extcommunity rt 123:123
!
route-map EXPORT_VRF_A permit 20
 match source-protocol connected
 set extcommunity rt 456:456
!
ip vrf VRF_A
 rd 1:1
 export map EXPORT_VRF_A
!  
ip vrf VRF_B
 rd 2:2
 route-target import 123:123
!  
ip vrf VRF_C
 rd 3:3
 route-target import 456:456

All routes should be redistributed/advertised into BGP for the purpose of the VRF leak but only the OSPF routes go with RT 123:123 which is imported in VRF_B and not in VRF_C.

Note that in route-map EXPORT_VRF_A you can do match source-protocol ospf <OSPF_ID> or match tag 123. The latter in case your OSPF routes are already coming with a specific Tag.

Tags are not supported in BGP since the concept of Communities is used instead. That is the reason your route-map with the set tag statement triggered a notification.

route-map SET
 set tag 123
!
router bgp 64512
 redistribute ospf 1 route-map SET
% "SET" used as redistribute ospf into bgp route-map, set tag not supported

HTH

DISCLAIMER:

The configurations discussed in this post can be merely templates and may not be final configurations that can be just copied & pasted to any network device in a production environment. It is responsibility of whoever follows this suggestions to review, evaluate and modify the configurations at convenience. Ensure that you understand the potential impact of any command. In all cases, make sure not to lose remote management access to the device. It is highly suggested to introduce changes to live networks only during maintenance windows. The author of this post is not responsible of unintended consequences by failing to follow this disclaimer note.

[ivarstrandberg]

Hi.
I tried this now:

route-map ADD-EXTCOMM-RM permit 10
match source-protocol connected
set extcommunity rt 1:1
!
route-map ADD-EXTCOMM-RM permit 20
match source-protocol ospf 2 vrf TEST
set extcommunity rt 1:2

But, for some reason, all routes are now changed to RT 1:1, even though only connected routes should be changed.
No routes are changed to RT1:2.

[Hector Gustavo Serrano Gutierrez]

Hi,

I have not tested it thoroughly.

If the route-map with match source-protocol is not working in this context (it may work only some other context like with the redistribute command) you may need to match based on a different criteria. Try to match based on a different criteria like prefix-list or match tag.

Still, the concept is the same.

Also, just for the sake of argument, try without any route-target export under the VRF configuration only if you are testing in a lab or safe environment.

HTH.