The community post "Route leaking between VRFs using RIB group" and its r/Juniper sibling "New to Junos, what am I missing to leak connected routes?" represent the two halves of this topic: leaking IGP/connected routes needs rib-groups, while leaking VPN/BGP routes between instances is cleaner with instance-import. Using the wrong tool is why most first attempts leak nothing.

Tool 1: Rib-Groups — for Connected, Static and IGP Routes

A rib-group copies routes as they are installed from one routing table into another. It attaches where the routes are learned:

routing-options {
    rib-groups {
        LEAK-CONNECTED {
            import-rib [ VR-CUST.inet.0 inet.0 ];
            import-policy LEAK-ONLY-LAN;
        }
    }
}
routing-instances {
    VR-CUST {
        instance-type virtual-router;
        interface ge-0/0/1.0;
        routing-options {
            interface-routes {
                rib-group inet LEAK-CONNECTED;
            }
        }
    }
}

The import policy decides which copied routes survive — without it, the group copies everything, including paths you may not want in the global table. This is the technique behind the Juniper community rib-group leak guide, and the reason the r/Juniper connected-routes leak thread needed an interface-routes rib-group stanza rather than a BGP export policy: connected routes never pass through BGP at all.

Tool 2: instance-import — for VRF and BGP Routes

For routes that arrive via BGP (for example an L3VPN vrf.inet.0 table), rib-groups work but are clunky; instance-import is the purpose-built path:

policy-statement VRF-TO-GLOBAL {
    from instance VRF-CUST;
    from route-filter 10.50.0.0/16 exact;
    then accept;
}
routing-options {
    instance-import VRF-TO-GLOBAL;
}

Applied under the receiving instance's routing-options (or the global one, depending on direction), it imports the policy-matching routes from the named instance. The stack exchange thread on leaking VRF to global contrasts exactly these two approaches — rib-group vs instance-import — with the same conclusion.

Direction and Next-Hop Reachability: the Two Classic Failures

  • Half-duplex leaks. A copied route is only usable if its next hop is reachable in the receiving table. Leaking a LAN route from VRF to global while the connecting interface lives only in the VRF produces routes that appear but never forward. Leak the interface route too (rib-group), or give the next hop a path in both tables.
  • Unexpected overlap. Leaking everything floods the receiving table and can shadow routes — the leak you added yesterday becomes the black hole of tomorrow. Always scope with an import policy, and verify with show route table inet.0 protocol <x> after each change.

Verification Commands

show route table VR-CUST.inet.0
show route table inet.0 10.50.0.0/16 detail
show route hidden table inet.0

The route detail output names the protocol and, for copied routes, shows the rib-group or import policy responsible. If a route is hidden instead of installed, it is almost always the next-hop reachability issue above.

Where This Fits the Broader Toolkit

Route leaking is the plumbing behind several situations covered elsewhere on this site: the shared-services design in our OSPF on MX working example, the service-separation logic when zones must talk across VRFs (see the SRX zone and policy guide), and the BGP side of leaking VPN routes described in the BGP troubleshooting series. And if your platform is running EVPN, note that leak-to-target route targets do the equivalent job for MAC/VNI routes — the multi-vendor details are in the EVPN-VXLAN interop guide.