[j-nsp] vrf auto-export rib-group

[Saku Ytti]

I can't tell if this is intended and supported behaviour, sorry.

I wonder if now you are actually breaking local vrf to local vrf
import/export, perhaps the rib-group should have the local vrf in
addition to inet.0.

On Tue, 23 Jun 2020 at 15:53, Mihai <mihaigabriel at gmail.com> wrote:
>
> Hi Saku,
>
> In the example below I can export all routes from VRF into inet.0 just
> by applying the rib-group under auto-export section, which I am happy as
> this is what I want to achieve (aggregate routes are also included), is
> also easier to configure instead of using a rib-group under each protocol.
> I suppose that in this case the auto-export is evaluating its own RT
> import/export and then just copy the routes to another table?
>
> r3# show routing-instances vrf
> instance-type vrf;
> route-distinguisher 3.3.3.3:3;
> vrf-target target:3:3;
> vrf-table-label;
> routing-options {
>      static {
>          route 10.100.100.100/32 discard;
>      }
>      aggregate {
>          route 10.0.0.0/8 discard;
>      }
>      auto-export {
>          family inet {
>              unicast {
>                  rib-group vrf-to-inet;
>              }
>          }
>      }
> }
>
> r3# show routing-options rib-groups
> vrf-to-inet {
>      import-rib inet.0;
> }
>
> r3# run show route table inet.0 10/8 detail| match
> "/|\*|table|state|Announcement"
>
> 10.0.0.0/8 (1 entry, 1 announced)
>          State: <FlashAll>
>          *Aggregate Preference: 130
>                  State: <Secondary Active Int Ext>
>                  Validation State: unverified
>                  Announcement bits (4): 2-LDP 3-Resolve tree 2 4-KRT
> 5-BGP_RT_Background
>                  Primary Routing Table vrf.inet.0
>
> 10.100.100.100/32 (1 entry, 1 announced)
>          State: <FlashAll>
>          *Static Preference: 5
>                  State: <Secondary Active Int Ext>
>                  Validation State: unverified
>                  Announcement bits (4): 2-LDP 3-Resolve tree 2 4-KRT
> 5-BGP_RT_Background
>                  Primary Routing Table vrf.inet.0
>
>
> 10.200.200.200/32 (1 entry, 1 announced)
>          State: <FlashAll>
>          *OSPF   Preference: 10
>                  Next hop: 172.16.0.2 via ge-0/0/1.1010, selected
>                  State: <Secondary Active Int>
>                  Validation State: unverified
>                  Announcement bits (3): 2-LDP 3-Resolve tree 2 4-KRT
> 5-BGP_RT_Background
>                  Primary Routing Table vrf.inet.0
>
>
>
> On 23/06/2020 12:57, Saku Ytti wrote:
> > Hey Mihai,
> >
> >
> >> Is the rib-group configured under VRF auto-export supposed to be a
> >> 'per-table' (instead of per-protocol) rib-group which can also export
> >> routes from VRFs to non-VRF instances, default included?
> >> The example on the link below shows the export to another table within
> >> the same instance:
> >>
> >> https://www.juniper.net/documentation/en_US/junos/topics/example/policy-duplicating-routes.html
> >>
> >> I already tested and confirmed that routes from VRFs can be leaked to
> >> inet.0 by just using the rib-group under auto-export but I am not sure
> >> whether this is officially supported.
> >
> > I'm not sure if auto-export and rib-groups are directly related. The
> > common reason why you need auto-export in Junos (but not in other NOS)
> > is that if you import RT, and that RT in another local VRF,  you don't
> > import it. As import only works on verbatim l3vpn rib. Auto-export
> > allows you to RT import routes from other local VRFs.
> >
> > rib-group is a set of ribs,which you can attach to multiple places and
> > it has different semantics on where you set it. But once a route hitsa
> >   rib-group, instead of it being installed to one specific RIB, it is
> > installed to all of the RIBs in that rib-group.
> >
> > There are some significant behavioural differences on route which
> > arrived 'natively' to RIB and route which arrived via rib-group,
> > namely you might not be able to reflect one in BGP while you are able
> > to reflect another. And sadly it's a feature, not a bug.
> >



-- 
  ++ytti