[j-nsp] Merging routes from VRF to inet.0

Discussion:

Tom Eichhorn

2015-01-14 09:31:50 UTC

Hi Guys,

I am currently facing a problem,
to which I do not have currently a clean solution:

I have routes in some L3 VPN vrf, and I need to merge some of them to
inet.0,
but I have no real clue how to do that.

RIB-groups would only merge all, and tbh, I never understood rib-groups
and the
documentation is a little bit unclear how they work.

My current solution is having a lt-interface between the inet.0 and
vrf.inet.0 and speaking BGP,
but that limits the traffic volume to one PFE (yes, I could have
lt-interfaces on each PFE and do ECMP, but
that would be that dirty...)

I tried also instance-import under routing-options, but that doesn't
work for some reason, instance-export
in the vrf is not supported - this only works for virtual routers, but
not VRFs...

I also tried some bad hacks on the bgp configuration, e.g. deleting the
vrf-community before importing etc,
but all of that also did not work :(

Any hint or idea?

Thanks,
Tom

PS: For the other way round, getting the default route to the VRF, I
simply use a next-table inet.0 route in the vrf.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Dave Bell

2015-01-14 10:37:12 UTC

Permalink

rib-groups is indeed the simplest way to do this. Something like this
should work for you:

routing-options {
rib-groups {
import_inet0 {
import-rib inet.0;
import-policy my_pol;
}
}

policy-options {
policy-statement my_pol {
term 10 {
from {
route-filter a.b.c.d/32 exact;
}
then accept;
}
term 30 {
then reject;
}
}
}
routing-instances {
my_instance {
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
auto-export {
family inet {
unicast {
rib-group import_inet0;
}
}
}
}
}

Post by Tom Eichhorn
Hi Guys,
I am currently facing a problem,
I have routes in some L3 VPN vrf, and I need to merge some of them to
inet.0,
but I have no real clue how to do that.
RIB-groups would only merge all, and tbh, I never understood rib-groups and
the
documentation is a little bit unclear how they work.
My current solution is having a lt-interface between the inet.0 and
vrf.inet.0 and speaking BGP,
but that limits the traffic volume to one PFE (yes, I could have
lt-interfaces on each PFE and do ECMP, but
that would be that dirty...)
I tried also instance-import under routing-options, but that doesn't work
for some reason, instance-export
in the vrf is not supported - this only works for virtual routers, but not
VRFs...
I also tried some bad hacks on the bgp configuration, e.g. deleting the
vrf-community before importing etc,
but all of that also did not work :(
Any hint or idea?
Thanks,
Tom
PS: For the other way round, getting the default route to the VRF, I simply
use a next-table inet.0 route in the vrf.
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Tom Eichhorn

2015-01-14 15:01:50 UTC

Permalink

Hi Dave & j-nsp,

I tried your example,
but it does not work - and I am a little bit helpless:

http://0bin.net/paste/lpH6zV8Pk2EXnI9L#F5xzmKZTpl9hA5QjZipHfz83-xdG6qexK4MGyM6SSCU

I also tried having an "accept all" import policy, but that doesn't
changed anything.

Thanks for your help,
Tom

PS: This is a MX running 12.3R5.7

Post by Dave Bell
rib-groups is indeed the simplest way to do this. Something like this
routing-options {
rib-groups {
import_inet0 {
import-rib inet.0;
import-policy my_pol;
}
}
policy-options {
policy-statement my_pol {
term 10 {
from {
route-filter a.b.c.d/32 exact;
}
then accept;
}
term 30 {
then reject;
}
}
}
routing-instances {
my_instance {
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
auto-export {
family inet {
unicast {
rib-group import_inet0;
}
}
}
}
}

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

Chuck Anderson

2015-01-14 15:52:40 UTC

Permalink

I do this with rib-groups directly, not auto-export. You need to
mention both the VRF and inet.0 tables in the rib-group, with the VRF
one first (primary table):

Main routing-options:

routing-options {
rib-groups {
vrf_and_inet0 {
import-rib [ vrf.inet.0 inet.0 ];
import-policy my_pol;
}
}
}

You also need to add the rib-group to the direct routes, and BGP
protocol (and/or OSPF or whatever the PE-CE protocol is) inside the
VRF:

routing-instances vrf {
routing-options {
interface-routes {
rib-group {
inet vrf_and_inet0;
}
}
}
protocols {
bgp {
family inet {
unicast {
rib-group vrf_and_inet0;
}
}
}
}
}

Add other families and/or multicast as needed.

Post by Tom Eichhorn
Hi Dave & j-nsp,
I tried your example,
http://0bin.net/paste/lpH6zV8Pk2EXnI9L#F5xzmKZTpl9hA5QjZipHfz83-xdG6qexK4MGyM6SSCU
I also tried having an "accept all" import policy, but that doesn't
changed anything.
Thanks for your help,
Tom
PS: This is a MX running 12.3R5.7

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

Chuck Anderson

2015-01-14 16:15:18 UTC

Permalink

I just found this excellent post that describes how rib-groups and
auto-export work, including the differences between them. I don't
think auto-export will work for going to the main/default inet.0 table
(it relies on route-distinguishers, so it only works between VRFs),
but "instance-import/export" may work instead if you'd rather not use
rib-groups:

http://forums.juniper.net/t5/TheRoutingChurn/Using-rib-groups-or-auto-export-for-route-leaking/ba-p/202349

Post by Chuck Anderson
I do this with rib-groups directly, not auto-export. You need to
mention both the VRF and inet.0 tables in the rib-group, with the VRF
routing-options {
rib-groups {
vrf_and_inet0 {
import-rib [ vrf.inet.0 inet.0 ];
import-policy my_pol;
}
}
}
You also need to add the rib-group to the direct routes, and BGP
protocol (and/or OSPF or whatever the PE-CE protocol is) inside the
routing-instances vrf {
routing-options {
interface-routes {
rib-group {
inet vrf_and_inet0;
}
}
}
protocols {
bgp {
family inet {
unicast {
rib-group vrf_and_inet0;
}
}
}
}
}
Add other families and/or multicast as needed.

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

Tom Eichhorn

2015-01-16 19:49:41 UTC

Permalink

Hi Guys,

I have found an answer why my rib-groups and everything is not working:
All fiddling with RIB-groups is for PE-CE, and not for PE-PE.
As the primary route is in bgp.l3vpn.0, I cannot leak from vrf.inet.0,
which is the secondary table for the route.

(If somebody asks why I can't do the leaking on the CE-PE router - there
is non. The other side of the
VPN is a contrail controller, which only speaks inet-vpn.).

I also discussed with this my SE, and they didn't had a quick answer but
have to discuss internally,
but I hope that our community here maybe also has an idea howto leak
routes received via inet-vpn to inet.0...

Thanks,
Tom

PS:
No, rib-groups between bgp.l3vpn.0 and inet.0 doesn't work, tried that
already.

Post by Chuck Anderson
I just found this excellent post that describes how rib-groups and
auto-export work, including the differences between them. I don't
think auto-export will work for going to the main/default inet.0 table
(it relies on route-distinguishers, so it only works between VRFs),
but "instance-import/export" may work instead if you'd rather not use
http://forums.juniper.net/t5/TheRoutingChurn/Using-rib-groups-or-auto-export-for-route-leaking/ba-p/202349

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

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

Tobias Heister

2015-01-16 20:15:58 UTC

Permalink

This post might be inappropriate. Click to display it.

Alexander Arseniev

2015-01-17 10:16:51 UTC

Permalink

There is a way but You may not like it :-)
Basically, You need to announce same route twice - as "inet-vpn unicast"
and as "inet unicast" from originating PE.
On receiving PE, you have to do 2 things:
1/ adjust nexthop resolution
set routing-options resolution rib inet.0 resolution-ribs [
L3VPNname.inet.0 inet.0 ]
2/ in BGP import policy, manipulate nexthop for "inet unicast" route in
such a way that it uniquely resolves via
L3VPNname.inet.0, maybe via another MP-BGP route from originating PE.
Also make sure all ordinary inet unicast routes in inet.0 on receiving
PE do not resolve via L3VPNname.inet.0.
Hope this makes sense
Thanks
Alex

Post by Tobias Heister
Hi,

Post by Tom Eichhorn
All fiddling with RIB-groups is for PE-CE, and not for PE-PE.
As the primary route is in bgp.l3vpn.0, I cannot leak from
vrf.inet.0, which is the secondary table for the route.
(If somebody asks why I can't do the leaking on the CE-PE router -
there is non. The other side of the
VPN is a contrail controller, which only speaks inet-vpn.).
I also discussed with this my SE, and they didn't had a quick answer
but have to discuss internally,
but I hope that our community here maybe also has an idea howto leak
routes received via inet-vpn to inet.0...

From my research there is no way to leak routes that were learned via
inet-vpn to inet.0 besides running routing protocols between instances.
I did a dirty hack the other day where i needed to move routes from
inet.0 to vrf.inet.0 and leaking was no option (do not ask) It is the
other way around from your setup but the concept should be similar.
I configured a static route (e.g. something from the documentation
prefix or other "bogus" prefix) with next-table statement (in your
case in inet.0 with next-table vrf.inet.0), setup BGP via lt- between
the instances and used an import policy to change the next-hop to
point to the prefix of the static route configured earlier. The BGP
needs to be multihop or to have the accept-remote-nexthop knob
configured because the next-hop is "remote". You will need to be able
to match the routes you want to leak/export via policy to do so.
This way forwarding is done directly to/from inet.0 (without) using
the lt- interface and all the bandwidth constraints it suffers. Also
1G tunneling is basically always free (on MX) even with DPCs so you
will not loose any interfaces when activating tunnels.
Maybe you can derive something from that for your setup. This will not
work if there is already a static route with next table from
vrf.inet.0 to inet.0 because the config parser will deny it for
possible loops. But maybe you can use rib-groups or other leaking
methods for that direction.

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

Johan Borch

2015-02-26 11:35:41 UTC

Permalink

Hi!

Is it the same if would like to leak routes learned from remote PE between
two VRF's on another PE, or do this "restriction" only exist when you want
to leak between inet.0 and VRF?

Johan

Post by Tobias Heister
Hi,

Post by Tom Eichhorn
All fiddling with RIB-groups is for PE-CE, and not for PE-PE.
As the primary route is in bgp.l3vpn.0, I cannot leak from vrf.inet.0,
which is the secondary table for the route.
(If somebody asks why I can't do the leaking on the CE-PE router - there
is non. The other side of the
VPN is a contrail controller, which only speaks inet-vpn.).
I also discussed with this my SE, and they didn't had a quick answer but
have to discuss internally,
but I hope that our community here maybe also has an idea howto leak
routes received via inet-vpn to inet.0...

From my research there is no way to leak routes that were learned via
inet-vpn to inet.0 besides running routing protocols between instances.
I did a dirty hack the other day where i needed to move routes from inet.0
to vrf.inet.0 and leaking was no option (do not ask) It is the other way
around from your setup but the concept should be similar.
I configured a static route (e.g. something from the documentation prefix
or other "bogus" prefix) with next-table statement (in your case in inet.0
with next-table vrf.inet.0), setup BGP via lt- between the instances and
used an import policy to change the next-hop to point to the prefix of the
static route configured earlier. The BGP needs to be multihop or to have
the accept-remote-nexthop knob configured because the next-hop is "remote".
You will need to be able to match the routes you want to leak/export via
policy to do so.
This way forwarding is done directly to/from inet.0 (without) using the
lt- interface and all the bandwidth constraints it suffers. Also 1G
tunneling is basically always free (on MX) even with DPCs so you will not
loose any interfaces when activating tunnels.
Maybe you can derive something from that for your setup. This will not
work if there is already a static route with next table from vrf.inet.0 to
inet.0 because the config parser will deny it for possible loops. But maybe
you can use rib-groups or other leaking methods for that direction.
--
Kind Regards
Tobias Heister
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Jack.Xu

2015-03-23 02:05:02 UTC

Permalink

Hi Tom:
This is my example. Seem meet your require.
routing-options {
interface-routes {
rib-group inet CT;
}
static {
route 0.0.0.0/0 next-hop 58.215.51.1;
}
rib-groups {
CNC {
import-rib [ inet.0 cnc.inet.0 ];
import-policy test;
}
CT {
import-rib [ inet.0 cnc.inet.0 ];
import-policy test;
}
}
}

policy-options {
policy-statement test {
term 1 {
from {
route-filter 192.168.2.0/24 orlonger;
route-filter 192.168.3.0/24 orlonger;
}
then accept;
}
term default {
then reject;
}
}
}

-----邮件原件-----
发件人: juniper-nsp [mailto:juniper-nsp-***@puck.nether.net] 代表 Tom
Eichhorn
发送时间: 2015年1月14日 17:32
收件人: jnsp
主题: [j-nsp] Merging routes from VRF to inet.0

Hi Guys,

I am currently facing a problem,
to which I do not have currently a clean solution:

I have routes in some L3 VPN vrf, and I need to merge some of them to
inet.0, but I have no real clue how to do that.

RIB-groups would only merge all, and tbh, I never understood rib-groups and
the documentation is a little bit unclear how they work.

My current solution is having a lt-interface between the inet.0 and
vrf.inet.0 and speaking BGP,
but that limits the traffic volume to one PFE (yes, I could have
lt-interfaces on each PFE and do ECMP, but that would be that dirty...)

I tried also instance-import under routing-options, but that doesn't work
for some reason, instance-export in the vrf is not supported - this only
works for virtual routers, but not VRFs...

I also tried some bad hacks on the bgp configuration, e.g. deleting the
vrf-community before importing etc, but all of that also did not work :(

Any hint or idea?

Thanks,
Tom

PS: For the other way round, getting the default route to the VRF, I simply
use a next-table inet.0 route in the vrf.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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