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?
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.
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
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?
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
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.
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.
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.