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

[Mihai]

No, the export between VRFs is still working:

r3# show routing-instances vrf2
instance-type vrf;
route-distinguisher 1:1;
vrf-import vrf2-import;
vrf-target target:1:1;
routing-options {
     auto-export;
}

r3# run show route table vrf2.inet.0 10/8 detail| match 
"/|\*|table|state|Announcement"

10.0.0.0/8 (1 entry, 1 announced)
         *Aggregate Preference: 130
                 State: <Secondary Active Int Ext>
                 Validation State: unverified
                 Announcement bits (1): 0-KRT
                 Primary Routing Table vrf.inet.0

10.100.100.100/32 (1 entry, 1 announced)
         *Static Preference: 5
                 State: <Secondary Active Int Ext>
                 Validation State: unverified
                 Announcement bits (1): 0-KRT
                 Primary Routing Table vrf.inet.0

10.200.200.200/32 (1 entry, 1 announced)
         *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 (1): 0-KRT
                 Primary Routing Table vrf.inet.0


On 23/06/2020 13:58, Saku Ytti wrote:
> 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.
>>>
> 
> 
>