Mailing List Archive

vrf auto-export rib-group
Hi,

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.

Thanks!
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: vrf auto-export rib-group [ In reply to ]
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
Re: vrf auto-export rib-group [ In reply to ]
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.
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: vrf auto-export rib-group [ In reply to ]
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@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
Re: vrf auto-export rib-group [ In reply to ]
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@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.
>>>
>
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: vrf auto-export rib-group [ In reply to ]
Hi,

----- On 23 Jun, 2020, at 14:57, Saku Ytti saku@ytti.fi 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.

In addition to the significant behavioural difference between copying routes with rib-groups vs. leaking by RTs that Saku referred above, there are some interesting behaviour when using rib-groups. For example, when a rib-group is attached to a BGP peering, the BGP import policy is effectively applied twice - first when the route is accepted into the "native" table and a second time when the route is copied e.g. to inet.0 or some other table.

Antti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: vrf auto-export rib-group [ In reply to ]
> Mihai
> Sent: Tuesday, June 23, 2020 12:39 PM
>
> Hi,
>
> 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/poli
> cy-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.
>
Maybe Jeff could chime in and shed some light on the peculiar differences of
using rib-groups under auto-export versus the below which I'm sure is
supported:
And how this all changes if the feature to have BGP not restart itself/to
always use l3vpn table for import export (can't recall name just now) is
enabled.
Could really use a "How BGP Works in Junos - Day One Book"

set routing-options rib-groups V4_INTERNET_TO_INET0 import-rib
INTERNET.inet.0
set routing-options rib-groups V4_INTERNET_TO_INET0 import-rib inet.0
set routing-options rib-groups V4_INTERNET_TO_INET0 import-policy
DEFAULT_ROUTE_V4
set routing-options rib-groups V6_INTERNET_TO_INET0 import-rib
INTERNET.inet.0
set routing-options rib-groups V6_INTERNET_TO_INET0 import-rib inet.0
set routing-options rib-groups V6_INTERNET_TO_INET0 import-policy
DEFAULT_ROUTE_V6
set routing-options rib-groups V4_PUBLIC_TO_INTERNET import-rib inet.0
set routing-options rib-groups V4_PUBLIC_TO_INTERNET import-rib
INTERNET.inet.0
set routing-options rib-groups V4_PUBLIC_TO_INTERNET import-policy
AGGREGATES_V4
set routing-options rib-groups V6_PUBLIC_TO_INTERNET import-rib inet6.0
set routing-options rib-groups V6_PUBLIC_TO_INTERNET import-rib
INTERNET.inet6.0
set routing-options rib-groups V6_PUBLIC_TO_INTERNET import-policy
AGGREGATES_V6

adam


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp