Re: [j-nsp] Merging routes from VRF to inet.0
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 On Fri, Jan 16, 2015 at 9:15 PM, Tobias Heister li...@tobias-heister.de wrote: Hi, Am 16.01.2015 um 20:49 schrieb Tom Eichhorn: 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... 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merging routes from VRF to inet.0
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 On 16/01/2015 20:15, Tobias Heister wrote: Hi, Am 16.01.2015 um 20:49 schrieb Tom Eichhorn: 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... 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-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merging routes from VRF to inet.0
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.
Am 14/01/15 um 17:15 schrieb 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
rib-groups:
http://forums.juniper.net/t5/TheRoutingChurn/Using-rib-groups-or-auto-export-for-route-leaking/ba-p/202349
On Wed, Jan 14, 2015 at 10:52:40AM -0500, Chuck Anderson wrote:
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.
On Wed, Jan 14, 2015 at 04:01:50PM +0100, Tom Eichhorn wrote:
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
Am 14/01/15 um 11:37 schrieb Dave Bell:
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;
}
}
}
}
}
On 14 January 2015 at 09:31, Tom Eichhorn t...@wirkbetrieb.net wrote:
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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merging routes from VRF to inet.0
Hi, Am 16.01.2015 um 20:49 schrieb Tom Eichhorn: 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... 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merging routes from VRF to inet.0
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
Am 14/01/15 um 11:37 schrieb Dave Bell:
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;
}
}
}
}
}
On 14 January 2015 at 09:31, Tom Eichhorn t...@wirkbetrieb.net wrote:
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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merging routes from VRF to inet.0
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.
On Wed, Jan 14, 2015 at 04:01:50PM +0100, Tom Eichhorn wrote:
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
Am 14/01/15 um 11:37 schrieb Dave Bell:
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;
}
}
}
}
}
On 14 January 2015 at 09:31, Tom Eichhorn t...@wirkbetrieb.net wrote:
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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merging routes from VRF to inet.0
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
On Wed, Jan 14, 2015 at 10:52:40AM -0500, Chuck Anderson wrote:
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.
On Wed, Jan 14, 2015 at 04:01:50PM +0100, Tom Eichhorn wrote:
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
Am 14/01/15 um 11:37 schrieb Dave Bell:
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;
}
}
}
}
}
On 14 January 2015 at 09:31, Tom Eichhorn t...@wirkbetrieb.net wrote:
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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merging routes from VRF to inet.0
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;
}
}
}
}
}
On 14 January 2015 at 09:31, Tom Eichhorn t...@wirkbetrieb.net wrote:
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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
