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 <mihaigabr...@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp