You may use a third VRF dedicated to such static routes.
VRF-special containing one route X next instance VRF A, and another router Y next instance VRF B.
VRF B imports the first one, VRF A imports the second one (always using auto-export).
I did this some years ago, plenty of stuff around this to make it work (including no-vrf-advertise to avoid using such routes to other PEs in my case), but this was the idea. Maybe relevant for you, maybe not.
Original Message:
Sent: 12-02-2023 04:30
From: ERIDANO DI PIETRO
Subject: Import routes from VRF and advertise them
Hi,
let me explain a bit better the scenario.
We are migrating an MPLS network based on a vendor different from Juniper, to MX960. The network is composed of about 40 PEs with around 50 VRFs. In the current situation we have a huge amount of leaking between VRFs realized via static routes having as next-table the target VRFs; this is done in both directions and unfortunately the same thing isn't allowed in Junos.
I used rib-groups to reproduce the same situation and it works, but from a configuration point of view it's a nightmare because I have to define one rib-group for each VRF containing a big set of tables and then apply to static, interfaces, routing-protocols...
For this reason I was thinking to import routes from a VRF to another using the auto-export feature and then export it into MPBGP to the remote PEs. I know there're also other methods, but in my case this would be the quickest one to avoid configurations on other peers when migrating one of them.
The import phase works, so I can see the route in the VRF, but then it's not exported, don't know why, I mean, maybe this is expected but I am not sure.
Following is the configuration of the PE where I import a loopback from VRF_A into VRF_B and then I try to export it.
You can see in show commands how rhe route appears in VRF_B table, but then it's not advertised into BGP.
Thanks in advance for your support.
set interfaces lo0 unit 3 family inet address 1.0.0.3/32
set interfaces lo0 unit 4 family inet address 1.0.0.4/32
set routing-instances VRF_A instance-type vrf
set routing-instances VRF_A interface lo0.3
set routing-instances VRF_A route-distinguisher 64978:3
set routing-instances VRF_A vrf-import VRF_A_vpn_import
set routing-instances VRF_A vrf-export VRF_A_vpn_export
set routing-instances VRF_A vrf-table-label
set routing-instances VRF_A routing-options auto-export
set routing-instances VRF_B instance-type vrf
set routing-instances VRF_B interface lo0.4
set routing-instances VRF_B route-distinguisher 64978:4
set routing-instances VRF_B vrf-import VRF_B_vpn_import
set routing-instances VRF_B vrf-export VRF_B_vpn_export
set routing-instances VRF_B vrf-table-label
set routing-instances VRF_B routing-options auto-export
set policy-options community VRF_A members target:64978:3
set policy-options community VRF_B members target:64978:4
set policy-options policy-statement VRF_B_vpn_import term bgp from protocol bgp
set policy-options policy-statement VRF_B_vpn_import term bgp from community VRF_B
set policy-options policy-statement VRF_B_vpn_import term bgp then accept
set policy-options policy-statement VRF_B_vpn_import term import from community VRF_A
set policy-options policy-statement VRF_B_vpn_import term import from route-filter 1.0.0.3/32 exact
set policy-options policy-statement VRF_B_vpn_import term import then accept
set policy-options policy-statement VRF_B_vpn_import term reject then reject
set policy-options policy-statement VRF_B_vpn_export term accept_all then community add VRF_B
set policy-options policy-statement VRF_B_vpn_export term accept_all then accept
set policy-options policy-statement VRF_A_vpn_import term bgp from protocol bgp
set policy-options policy-statement VRF_A_vpn_import term bgp from community VRF_A
set policy-options policy-statement VRF_A_vpn_import term bgp then accept
set policy-options policy-statement VRF_A_vpn_import term reject then reject
set policy-options policy-statement VRF_A_vpn_export term bgp from protocol bgp
set policy-options policy-statement VRF_A_vpn_export term bgp from protocol static
set policy-options policy-statement VRF_A_vpn_export term bgp from protocol direct
set policy-options policy-statement VRF_A_vpn_export term bgp then community add VRF_A
set policy-options policy-statement VRF_A_vpn_export term bgp then accept
set policy-options policy-statement VRF_A_vpn_export term reject then reject
root> show route table VRF_B
VRF_B.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.0.0.3/32 *[Direct/0] 00:03:57
> via lo0.3
1.0.0.4/32 *[Direct/0] 00:03:57
> via lo0.4
2.0.0.4/32 *[BGP/170] 00:00:33, localpref 100, from 10.150.150.238
AS path: I, validation-state: unverified
> to 1.1.1.2 via ge-0/0/9.0, Push 19
root> show route table VRF_B detail 1.0.0.3/32
VRF_B.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
1.0.0.3/32 (1 entry, 1 announced)
*Direct Preference: 0
Next hop type: Interface, Next hop index: 0
Address: 0xb39f610
Next-hop reference count: 2
Next hop: via lo0.3, selected
State: <Secondary Active Int>
Age: 23:55
Validation State: unverified
Task: IF
Announcement bits (1): 0-KRT
AS path: I
Communities: target:64978:3
Primary Routing Table VRF_A.inet.0
root> show route advertising-protocol bgp 10.150.150.238
VRF_B.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 1.0.0.4/32 Self 100 I
------------------------------
ERIDANO DI PIETRO
Original Message:
Sent: 12-01-2023 13:46
From: Olivier Benghozi
Subject: Import routes from VRF and advertise them
By «distribute to remote PE», you mean advertise VRF routes in i-MP-BGP, right?
So you have to export the route from the exporting VRF (let's say A), not from the importing VFR (let's say B). So make provisions to export the routes toward remote PE inside your AS inside the export vrf policy of VFR A (by example).
------------------------------
Olivier Benghozi
Original Message:
Sent: 11-15-2023 10:01
From: ERIDANO DI PIETRO
Subject: Import routes from VRF and advertise them
Dears,
I need to migrate the routers composing an MPLS/VRFs based network to Juniper MX960.
Routers currently used (I avoid specifying the vendor name) have a lot of leaking between VRFs realized using static route which specify as next-hop the target VRF, so let's say that we have two VRFs, VRF_A and VRF_B, current configuration has many static routes in VRF_A specifying as next-hop VRF_B and also many static routes in VRF_B specifying as next-hop VRF_A, besides to that, these static routes are redistrbuted into BGP so remote PEs can receive them.
I know this is not allowed in Juniper routers where the jump to another VRF can be set only in one way, meaning that if there's static in VRF_A having VRF_ B as next-table, the opposite is not permitted in order to avoid loops.
However, using vrf-import and auto-export I have somehow fixed this, but the problem is that I need to advertise these routes imported from other VRFs and I haven't found a way to do it, for example, once I have the route imported from VRF_A into VRF_B table, I cannot export it into BGP to distribute it to remote PEs: if I configure an export policy specifying the imported route and apply it to BGP, it doesn't work.
Is there a way to redistribute this imported routes?
Thanks in advance for your support.
------------------------------
ERIDANO DI PIETRO
------------------------------