Hi Ondrej, Thanks for your response. L3VPN feature is cool and thank you for your valuable addition. Please let me know how to set an empty export route target in l3vpn. I tried the options below and I got syntax error. export target [(rt, , )]; export target [()]; export target [ ]; export target [(rt)] When I tried with "export target [(rt, 0, 0)];", route target with 0:0 was advertised. Thanks, Ramanathan On Tue, 13 Jun 2023 at 19:28, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Jun 13, 2023 at 10:47:08AM +0530, Ramanathan Selvamani wrote:
Hi Team,
I configured l3vpn in BIRD and I was able to see the routes are learnt and advertised based on RT.
All the routes in this VRF are advertised with RT (1:11) to neighbors.
Hi
I am glad you tried this MPLS L3VPN branch, i would be interested in your experiences and suggestions with it.
I have a use case in which I want to apply different RT for different routes belonging to the same VRF.
For example, I have the following prefixes in this VRF "vrf2". 101.1.1.0/24 103.1.1.0/24 105.1.1.0/24
I would like to add different "export route target" as below for routes belong to same VRF 101.1.1.0/24 : export RT 1:11 103.1.1.0/24 : export RT 1:20 105.1.1.0/24 : export RT 1:30
Currently, the implicit export RT processing works by removing all RT communitines and then adding ones specified in the export target option.
If you want to set individual route targets, you could just keep the export target set empty and add individual communities ex-post in vpn4 channel import filter (VRF export direction first passes through ipvX channel export filter, then internal processing, then vpnX channel import filter), with something like:
case (net) { 1:11 101.1.1.0/24: bgp_ext_community.add((rt, 1, 11)); 1:11 103.1.1.0/24: bgp_ext_community.add((rt, 1, 20)); 1:11 105.1.1.0/24: bgp_ext_community.add((rt, 1, 30)); }
(note that in vpnX import filter the route is already converted to VPNv4 NLRI, so 'net' is RD + prefix.
There is an alternative approach, which is not yet implemented, but there should be an option with EC set that instead of appriori removing all existing RTs during export, it should keep a defined subset (say [(rt, 1, 10..40)]), and then these RTs could be passed from original IP routes from VRF.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."