Re: Redistributing between bgpd and ospfd
Henry Bonath(he...@thebonaths.com) on 2018.10.27 19:21:15 -0400: > Claudio - > > One use case where I personally ran into this need in the past is in an > MPLS PE-CE where OSPF is running between the Provider and Customer. (L3VPN) > One would want to redistribute the Customers OSPF routes into BGP as VPNv4 > prefixes into the customers VRF in the provider network. > > We typically run Cisco on our CPE's and do exactly this with our customers, > with a redistribute ospf statement under "address-family vpnv4 vrf > cusomerVRF" > I'd *love* to be able to do the same with OpenBSD and not have to fork out > Cisco money at the customer premise. This should already be possible (as described my mail) with network inet priority 32 > That being said, EIGRPD would also benefit here, as I have customers that > run EIGRP and want to use that on their CE's. same there, use priority 28 /Benno > Thanks for everything that you do, and keep up the great work! > > On Mon, Oct 15, 2018 at 8:37 AM Claudio Jeker > wrote: > > > On Mon, Oct 15, 2018 at 02:48:31PM +0300, Gregory Edigarov wrote: > > > On 15.10.18 12:58, Sebastian Benoit wrote: > > > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: > > > > > Hello, > > > > > > > > > > I am trying to get bgpd and ospfd play nicely with route > > redistribution. > > > > > > > > > > So far the only way I have found that suits my need is to use > > > > > bgpd.conf network statements and rtlabels. > > > > > > > > > > So, to make ospfd learn route from bgpd I use rtlabels. So in > > bgpd.conf: > > > > > match from set rtlabel from_bgpd > > > > > > > > > > And in ospfd.conf: > > > > > redistribute rtlabel from_bgpd > > > > > > > > > > > > > > > So far so good. But the other way around, to bake bgpd learn from > > > > > ospfd it becomes a bit more tedious. The only way I have found to > > make > > > > > bgpd announce ospf originated routes (to its bgp peers) is via > > network > > > > > statements in bgpd.conf. These network statements are not conditional > > > > > on the availability of such a route in ospf though so they are not > > > > > very dynamic anymore. > > > > > > > > > > I understand that it according to standard > > > > > (https://tools.ietf.org/html/rfc1364) should be something that is > > > > > explicit for type 1 and 2 LSAs. > > > > > > > > > > What is the recommended way to achieve dynamic explicit route > > > > > redistribution in both directions? > > > > Network statements are the correct way. > > > > > > > > You can use > > > > > > > > network (inet|inet6) priority ... > > > > network (inet|inet6) rtlabel ... > > > > > > > > So with > > > > > > > >network inet priority 32 > > > > > > > > you should be able to redistribute all ospf routes into bgp. > > > > > > > > If this does not help, please explain your problem further (and > > include your > > > > config). > > > > > > > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot) > > for > > > > this as there was at least a bugfix for route-labels.) > > > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer > > > setting them per area, or per interface where a route was learned. > > > just wondering why is it not implemented yet. is that too complex > > change? or > > > just not necessary? > > > > > > > Until now there has not been a need for this. In general and probably best > > common practice is to not mix BGP and OSPF. Instead OSPF is building the > > underlaying network to run BGP on top of. This is why benno@ was asking > > for the use case. > > > > By the way, because of the nature of OSPF it does not make sense to tag > > routes by interface, doing it by area could be an option but that comes > > with some edge cases that need further inspection. > > > > -- > > :wq Claudio > > > > > --
Re: Redistributing between bgpd and ospfd
Claudio - One use case where I personally ran into this need in the past is in an MPLS PE-CE where OSPF is running between the Provider and Customer. (L3VPN) One would want to redistribute the Customers OSPF routes into BGP as VPNv4 prefixes into the customers VRF in the provider network. We typically run Cisco on our CPE's and do exactly this with our customers, with a redistribute ospf statement under "address-family vpnv4 vrf cusomerVRF" I'd *love* to be able to do the same with OpenBSD and not have to fork out Cisco money at the customer premise. That being said, EIGRPD would also benefit here, as I have customers that run EIGRP and want to use that on their CE's. Thanks for everything that you do, and keep up the great work! On Mon, Oct 15, 2018 at 8:37 AM Claudio Jeker wrote: > On Mon, Oct 15, 2018 at 02:48:31PM +0300, Gregory Edigarov wrote: > > On 15.10.18 12:58, Sebastian Benoit wrote: > > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: > > > > Hello, > > > > > > > > I am trying to get bgpd and ospfd play nicely with route > redistribution. > > > > > > > > So far the only way I have found that suits my need is to use > > > > bgpd.conf network statements and rtlabels. > > > > > > > > So, to make ospfd learn route from bgpd I use rtlabels. So in > bgpd.conf: > > > > match from set rtlabel from_bgpd > > > > > > > > And in ospfd.conf: > > > > redistribute rtlabel from_bgpd > > > > > > > > > > > > So far so good. But the other way around, to bake bgpd learn from > > > > ospfd it becomes a bit more tedious. The only way I have found to > make > > > > bgpd announce ospf originated routes (to its bgp peers) is via > network > > > > statements in bgpd.conf. These network statements are not conditional > > > > on the availability of such a route in ospf though so they are not > > > > very dynamic anymore. > > > > > > > > I understand that it according to standard > > > > (https://tools.ietf.org/html/rfc1364) should be something that is > > > > explicit for type 1 and 2 LSAs. > > > > > > > > What is the recommended way to achieve dynamic explicit route > > > > redistribution in both directions? > > > Network statements are the correct way. > > > > > > You can use > > > > > > network (inet|inet6) priority ... > > > network (inet|inet6) rtlabel ... > > > > > > So with > > > > > >network inet priority 32 > > > > > > you should be able to redistribute all ospf routes into bgp. > > > > > > If this does not help, please explain your problem further (and > include your > > > config). > > > > > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot) > for > > > this as there was at least a bugfix for route-labels.) > > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer > > setting them per area, or per interface where a route was learned. > > just wondering why is it not implemented yet. is that too complex > change? or > > just not necessary? > > > > Until now there has not been a need for this. In general and probably best > common practice is to not mix BGP and OSPF. Instead OSPF is building the > underlaying network to run BGP on top of. This is why benno@ was asking > for the use case. > > By the way, because of the nature of OSPF it does not make sense to tag > routes by interface, doing it by area could be an option but that comes > with some edge cases that need further inspection. > > -- > :wq Claudio > >
Re: Redistributing between bgpd and ospfd
On Wed, Oct 17, 2018 at 01:07:32PM +0200, Sebastian Benoit wrote:
> open...@kene.nu(open...@kene.nu) on 2018.10.17 12:44:02 +0200:
> > Hello,
> >
> > On Tue, Oct 16, 2018 at 4:56 PM Sebastian Benoit
> > wrote:
> > >
> > > Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200:
> > > > On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote:
> > > > > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote:
> > > > > > Hello,
> > > > > >
> > > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its
> > > > > > keepalives. I will ponder the value of transporting the underlay in
> > > > > > OSPF, effectively transporting loopback peering addresses for BGP in
> > > > > > OSPF. I am not sure that it will make my life easier but will
> > > > > > consider
> > > > > > it.
> > > > >
> > > > > OSPF is generally faster at converging after reroute and it is
> > > > > possible to
> > > > > set the router-dead-time to minimal which will give you a 1 second
> > > > > timeout. Also the default of 40sec is lower than the 90sec of BGP.
> > > > > Additionally OSPF may give you multipath routes so the failover for
> > > > > BGP
> > > > > may be not noticable. Also GRE has a way to emulate link state but to
> > > > > be
> > > > > honest if I use OSPF on a GRE link I will not turn it on (unless
> > > > > requested).
> > > >
> > > > I guess the brewing BFD support would speed this up for BGP when it
> > > > arrives
> > > > and make OSPF less useful if speed is the thing that needs to be solved.
> > > >
> > > > Also I've been thinking about the following config in ospfd
> > > >
> > > > rtlabel label external-tag number
> > > > Map route labels to external route tags and vice versa.
> > > > The
> > > >external route tag is a non-negative 32-bit number
> > > >attached to AS-external OSPF LSAs.
> > > >
> > > > What exactly does this mean? As I understand it is to map rtlabels to
> > > > LSA
> > > > Type 5 tags. But what do you do with it then? Could this be used for
> > > > what
> > > > this thread is talking about or is it totally off?
> > >
> > > If you do this on two (or more routers) you distribute the routes and they
> > > end up in the fib with that rtlabel (note the "and vice versa").
> > >
> > > You can do all the things you can do with route labels, for example use
> > > them in pf filters.
> > >
> > > And yes, you could also use it to redistribute them into bgp (although
> > > that
> > > needs to happen on another router i think):
> > >
> > > ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ...
> > > hostA hostB hostBhostB
> > >
> > > /Benno
> >
> > I might be wrong here but in prder to have ospfd generate type 5 LSAs
> > one needs both a BGP speaker that announces the prefix in question
> > into ospf and two different ospf areas in your network?
>
> No need for a bgp speaker: a route in the routing table with the label is
> enough.
>
> So here is a rough description of how ospfd and bgpd announce new prefixes
> (i.e. the ones not learned from other routers).
>
> ospfd looks at whats in the kernel routing table (FIB), and depending on its
> configuration (the interface statements _and_ redistribute commands) it adds
> routes into its ospfd internal RIB. That RIB is then propagated into the
> ospf network (skip ospf protocol details here).
>
> ospfd needs routes in the FIB to inject new routes into OSPF.
>
> By inject, i mean "add a new network to the routes in the RIB".
>
> BGPD on the other hand has the "network " statement.
>
> It adds the prefix given there to its RIB ("injects it into BGP") without
> the need for a route in the FIB.
>
> The additional options (network priority ..., network rtlabel ...) are
> only there for convinience and special cases, they are not really needed
> for standard bgp setups.
>
> > Or can I make ospfd generate type5 LSAs in some other way? I see that
> > rtlabels would do it but that implies I have an already existing route
> > in the fib which preemptively I tag in some way. In my case the routes
> > are generated by interface statements in ospfd.conf (so type1 and 2
> > LSAs).
>
> If you use interface statements, those interfaces have IPs on them, which you
> will find have routes in the routing table.
>
> Also, there is "ifconfig rtlabel ..."
>
> I don't know if ospfd will pick those route-labels up (with the rtlabel
> statement). I think it should, but havent used that or looked at the code.
>
The rtlabel / external-tag mapping only works for Type-5 LSA which are
prefixes ospfd picked up via any of the redistribute statements. Any prefix
covered by interface statements end up as non Type-5 LSA and so will not
use the mapping. This includes stub networks.
I have not tried to use "ifconfig rtlabel ..." with ospfd together
but I see no reason why it should not work if used with redistribute
connected for example.
--
:wq Claudio
Re: Redistributing between bgpd and ospfd
open...@kene.nu(open...@kene.nu) on 2018.10.17 12:44:02 +0200:
> Hello,
>
> On Tue, Oct 16, 2018 at 4:56 PM Sebastian Benoit wrote:
> >
> > Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200:
> > > On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote:
> > > > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote:
> > > > > Hello,
> > > > >
> > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its
> > > > > keepalives. I will ponder the value of transporting the underlay in
> > > > > OSPF, effectively transporting loopback peering addresses for BGP in
> > > > > OSPF. I am not sure that it will make my life easier but will consider
> > > > > it.
> > > >
> > > > OSPF is generally faster at converging after reroute and it is possible
> > > > to
> > > > set the router-dead-time to minimal which will give you a 1 second
> > > > timeout. Also the default of 40sec is lower than the 90sec of BGP.
> > > > Additionally OSPF may give you multipath routes so the failover for BGP
> > > > may be not noticable. Also GRE has a way to emulate link state but to be
> > > > honest if I use OSPF on a GRE link I will not turn it on (unless
> > > > requested).
> > >
> > > I guess the brewing BFD support would speed this up for BGP when it
> > > arrives
> > > and make OSPF less useful if speed is the thing that needs to be solved.
> > >
> > > Also I've been thinking about the following config in ospfd
> > >
> > > rtlabel label external-tag number
> > > Map route labels to external route tags and vice versa. The
> > >external route tag is a non-negative 32-bit number
> > >attached to AS-external OSPF LSAs.
> > >
> > > What exactly does this mean? As I understand it is to map rtlabels to LSA
> > > Type 5 tags. But what do you do with it then? Could this be used for what
> > > this thread is talking about or is it totally off?
> >
> > If you do this on two (or more routers) you distribute the routes and they
> > end up in the fib with that rtlabel (note the "and vice versa").
> >
> > You can do all the things you can do with route labels, for example use
> > them in pf filters.
> >
> > And yes, you could also use it to redistribute them into bgp (although that
> > needs to happen on another router i think):
> >
> > ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ...
> > hostA hostB hostBhostB
> >
> > /Benno
>
> I might be wrong here but in prder to have ospfd generate type 5 LSAs
> one needs both a BGP speaker that announces the prefix in question
> into ospf and two different ospf areas in your network?
No need for a bgp speaker: a route in the routing table with the label is
enough.
So here is a rough description of how ospfd and bgpd announce new prefixes
(i.e. the ones not learned from other routers).
ospfd looks at whats in the kernel routing table (FIB), and depending on its
configuration (the interface statements _and_ redistribute commands) it adds
routes into its ospfd internal RIB. That RIB is then propagated into the
ospf network (skip ospf protocol details here).
ospfd needs routes in the FIB to inject new routes into OSPF.
By inject, i mean "add a new network to the routes in the RIB".
BGPD on the other hand has the "network " statement.
It adds the prefix given there to its RIB ("injects it into BGP") without
the need for a route in the FIB.
The additional options (network priority ..., network rtlabel ...) are
only there for convinience and special cases, they are not really needed
for standard bgp setups.
> Or can I make ospfd generate type5 LSAs in some other way? I see that
> rtlabels would do it but that implies I have an already existing route
> in the fib which preemptively I tag in some way. In my case the routes
> are generated by interface statements in ospfd.conf (so type1 and 2
> LSAs).
If you use interface statements, those interfaces have IPs on them, which you
will find have routes in the routing table.
Also, there is "ifconfig rtlabel ..."
I don't know if ospfd will pick those route-labels up (with the rtlabel
statement). I think it should, but havent used that or looked at the code.
/Benno
Re: Redistributing between bgpd and ospfd
Hello, On Tue, Oct 16, 2018 at 4:56 PM Sebastian Benoit wrote: > > Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200: > > On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote: > > > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote: > > > > Hello, > > > > > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its > > > > keepalives. I will ponder the value of transporting the underlay in > > > > OSPF, effectively transporting loopback peering addresses for BGP in > > > > OSPF. I am not sure that it will make my life easier but will consider > > > > it. > > > > > > OSPF is generally faster at converging after reroute and it is possible to > > > set the router-dead-time to minimal which will give you a 1 second > > > timeout. Also the default of 40sec is lower than the 90sec of BGP. > > > Additionally OSPF may give you multipath routes so the failover for BGP > > > may be not noticable. Also GRE has a way to emulate link state but to be > > > honest if I use OSPF on a GRE link I will not turn it on (unless > > > requested). > > > > I guess the brewing BFD support would speed this up for BGP when it arrives > > and make OSPF less useful if speed is the thing that needs to be solved. > > > > Also I've been thinking about the following config in ospfd > > > > rtlabel label external-tag number > > Map route labels to external route tags and vice versa. The > >external route tag is a non-negative 32-bit number > >attached to AS-external OSPF LSAs. > > > > What exactly does this mean? As I understand it is to map rtlabels to LSA > > Type 5 tags. But what do you do with it then? Could this be used for what > > this thread is talking about or is it totally off? > > If you do this on two (or more routers) you distribute the routes and they > end up in the fib with that rtlabel (note the "and vice versa"). > > You can do all the things you can do with route labels, for example use > them in pf filters. > > And yes, you could also use it to redistribute them into bgp (although that > needs to happen on another router i think): > > ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ... > hostA hostB hostBhostB > > /Benno I might be wrong here but in prder to have ospfd generate type 5 LSAs one needs both a BGP speaker that announces the prefix in question into ospf and two different ospf areas in your network? Or can I make ospfd generate type5 LSAs in some other way? I see that rtlabels would do it but that implies I have an already existing route in the fib which preemptively I tag in some way. In my case the routes are generated by interface statements in ospfd.conf (so type1 and 2 LSAs). >
Re: Redistributing between bgpd and ospfd
Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200: > On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote: > > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote: > > > Hello, > > > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its > > > keepalives. I will ponder the value of transporting the underlay in > > > OSPF, effectively transporting loopback peering addresses for BGP in > > > OSPF. I am not sure that it will make my life easier but will consider > > > it. > > > > OSPF is generally faster at converging after reroute and it is possible to > > set the router-dead-time to minimal which will give you a 1 second > > timeout. Also the default of 40sec is lower than the 90sec of BGP. > > Additionally OSPF may give you multipath routes so the failover for BGP > > may be not noticable. Also GRE has a way to emulate link state but to be > > honest if I use OSPF on a GRE link I will not turn it on (unless > > requested). > > I guess the brewing BFD support would speed this up for BGP when it arrives > and make OSPF less useful if speed is the thing that needs to be solved. > > Also I've been thinking about the following config in ospfd > > rtlabel label external-tag number > Map route labels to external route tags and vice versa. The >external route tag is a non-negative 32-bit number >attached to AS-external OSPF LSAs. > > What exactly does this mean? As I understand it is to map rtlabels to LSA > Type 5 tags. But what do you do with it then? Could this be used for what > this thread is talking about or is it totally off? If you do this on two (or more routers) you distribute the routes and they end up in the fib with that rtlabel (note the "and vice versa"). You can do all the things you can do with route labels, for example use them in pf filters. And yes, you could also use it to redistribute them into bgp (although that needs to happen on another router i think): ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ... hostA hostB hostBhostB /Benno
Re: Redistributing between bgpd and ospfd
On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote: > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote: > > Hello, > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its > > keepalives. I will ponder the value of transporting the underlay in > > OSPF, effectively transporting loopback peering addresses for BGP in > > OSPF. I am not sure that it will make my life easier but will consider > > it. > > OSPF is generally faster at converging after reroute and it is possible to > set the router-dead-time to minimal which will give you a 1 second > timeout. Also the default of 40sec is lower than the 90sec of BGP. > Additionally OSPF may give you multipath routes so the failover for BGP > may be not noticable. Also GRE has a way to emulate link state but to be > honest if I use OSPF on a GRE link I will not turn it on (unless > requested). I guess the brewing BFD support would speed this up for BGP when it arrives and make OSPF less useful if speed is the thing that needs to be solved. Also I've been thinking about the following config in ospfd rtlabel label external-tag number Map route labels to external route tags and vice versa. The external route tag is a non-negative 32-bit number attached to AS-external OSPF LSAs. What exactly does this mean? As I understand it is to map rtlabels to LSA Type 5 tags. But what do you do with it then? Could this be used for what this thread is talking about or is it totally off? -- Tommy Nevtelen
Re: Redistributing between bgpd and ospfd
On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote: > Hello, > > Only relying on OSPF hellos effectively makes it mimic BGP with its > keepalives. I will ponder the value of transporting the underlay in > OSPF, effectively transporting loopback peering addresses for BGP in > OSPF. I am not sure that it will make my life easier but will consider > it. OSPF is generally faster at converging after reroute and it is possible to set the router-dead-time to minimal which will give you a 1 second timeout. Also the default of 40sec is lower than the 90sec of BGP. Additionally OSPF may give you multipath routes so the failover for BGP may be not noticable. Also GRE has a way to emulate link state but to be honest if I use OSPF on a GRE link I will not turn it on (unless requested). > Thanks for the quick replies everyone. You confirmed that I am not > entirely a moron. > > Still, having the ability to set rtlabels in ospfd would be nice. > On Mon, Oct 15, 2018 at 5:59 PM Stuart Henderson wrote: > > > > On 2018-10-15, open...@kene.nu wrote: > > > in theory. But when WAN links are composed of IPSEC and GRE (which > > > does not have link state) OSPF falls to pieces as the core idea of is > > > link-state. > > > > OSPF primarily uses hellos. Link-state is also used to speed up failover > > up but is not required. > > > > There was a bug in ospfd with DR selection that results in problems > > (specifically multiple routers thinking they were all DR) after a > > netsplit if there was no link-state change. This was already fixed > > though so if you are running 6.3+ and still seeing problems, please > > send a bug report with some information. > > > > > -- :wq Claudio
Re: Redistributing between bgpd and ospfd
On 2018-10-16, open...@kene.nu wrote: > Only relying on OSPF hellos effectively makes it mimic BGP with its > keepalives. I will ponder the value of transporting the underlay in > OSPF, effectively transporting loopback peering addresses for BGP in > OSPF. I am not sure that it will make my life easier but will consider > it. I like being able to run BGP sessions between loopback addresses (rather than normal interface addresses which can go down), it makes it fairly easy to handle multiple paths between routers (I'm not sure how you would do that without an IGP unless you rely on lower-layer mechanisms like switch failover and loop-avoidance protocols).
Re: Redistributing between bgpd and ospfd
Hello, Only relying on OSPF hellos effectively makes it mimic BGP with its keepalives. I will ponder the value of transporting the underlay in OSPF, effectively transporting loopback peering addresses for BGP in OSPF. I am not sure that it will make my life easier but will consider it. Thanks for the quick replies everyone. You confirmed that I am not entirely a moron. Still, having the ability to set rtlabels in ospfd would be nice. On Mon, Oct 15, 2018 at 5:59 PM Stuart Henderson wrote: > > On 2018-10-15, open...@kene.nu wrote: > > in theory. But when WAN links are composed of IPSEC and GRE (which > > does not have link state) OSPF falls to pieces as the core idea of is > > link-state. > > OSPF primarily uses hellos. Link-state is also used to speed up failover > up but is not required. > > There was a bug in ospfd with DR selection that results in problems > (specifically multiple routers thinking they were all DR) after a > netsplit if there was no link-state change. This was already fixed > though so if you are running 6.3+ and still seeing problems, please > send a bug report with some information. > >
Re: Redistributing between bgpd and ospfd
On 2018-10-15, open...@kene.nu wrote: > in theory. But when WAN links are composed of IPSEC and GRE (which > does not have link state) OSPF falls to pieces as the core idea of is > link-state. OSPF primarily uses hellos. Link-state is also used to speed up failover up but is not required. There was a bug in ospfd with DR selection that results in problems (specifically multiple routers thinking they were all DR) after a netsplit if there was no link-state change. This was already fixed though so if you are running 6.3+ and still seeing problems, please send a bug report with some information.
Re: Redistributing between bgpd and ospfd
Hello, On Mon, Oct 15, 2018 at 2:49 PM Claudio Jeker wrote: > > On Mon, Oct 15, 2018 at 02:48:31PM +0300, Gregory Edigarov wrote: > > On 15.10.18 12:58, Sebastian Benoit wrote: > > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: > > > > Hello, > > > > > > > > I am trying to get bgpd and ospfd play nicely with route redistribution. > > > > > > > > So far the only way I have found that suits my need is to use > > > > bgpd.conf network statements and rtlabels. > > > > > > > > So, to make ospfd learn route from bgpd I use rtlabels. So in bgpd.conf: > > > > match from set rtlabel from_bgpd > > > > > > > > And in ospfd.conf: > > > > redistribute rtlabel from_bgpd > > > > > > > > > > > > So far so good. But the other way around, to bake bgpd learn from > > > > ospfd it becomes a bit more tedious. The only way I have found to make > > > > bgpd announce ospf originated routes (to its bgp peers) is via network > > > > statements in bgpd.conf. These network statements are not conditional > > > > on the availability of such a route in ospf though so they are not > > > > very dynamic anymore. > > > > > > > > I understand that it according to standard > > > > (https://tools.ietf.org/html/rfc1364) should be something that is > > > > explicit for type 1 and 2 LSAs. > > > > > > > > What is the recommended way to achieve dynamic explicit route > > > > redistribution in both directions? > > > Network statements are the correct way. > > > > > > You can use > > > > > > network (inet|inet6) priority ... > > > network (inet|inet6) rtlabel ... > > > > > > So with > > > > > >network inet priority 32 > > > > > > you should be able to redistribute all ospf routes into bgp. > > > > > > If this does not help, please explain your problem further (and include > > > your > > > config). > > > > > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot) for > > > this as there was at least a bugfix for route-labels.) > > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer > > setting them per area, or per interface where a route was learned. > > just wondering why is it not implemented yet. is that too complex change? or > > just not necessary? > > > > Until now there has not been a need for this. In general and probably best > common practice is to not mix BGP and OSPF. Instead OSPF is building the > underlaying network to run BGP on top of. This is why benno@ was asking > for the use case. I tend to agree, but reality does not agree with me. My reality is that running OSPF over unstable WAN links is not preferred over BGP, which is arguably more suited for this. So in essence building the underlay on OSPF, that BGP relies upon, is good in theory. But when WAN links are composed of IPSEC and GRE (which does not have link state) OSPF falls to pieces as the core idea of is link-state. Here BGP, which is not relying on link-state, is the better option design wise. I could run BGP everywhere and scrap OSPF all together, but OSPF is VERY convenient when you have link state. The simplicity and robustness compared to explicit neighbors in BGP is nothing that one should overlook. So for me the best tool for the job is in some cases OSPF and in some cases BGP. Making them play nicely together would be nice. Either that or scrap one of the protocols all together. That is my use-case. > > By the way, because of the nature of OSPF it does not make sense to tag > routes by interface, doing it by area could be an option but that comes > with some edge cases that need further inspection. > > -- > :wq Claudio >
Re: Redistributing between bgpd and ospfd
I agree, it would, be very nice. For my case the "network inet priority 32"-hack could work, even though it only exists in 6.4 so upgrading everything that needs it is necessary. But as far as the future goes, rtlabels tagging of routes in ospfd would be ideal. Having only the above hack to rely on can go wrong in so many ways. On Mon, Oct 15, 2018 at 1:57 PM Gregory Edigarov wrote: > > On 15.10.18 12:58, Sebastian Benoit wrote: > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: > >> Hello, > >> > >> I am trying to get bgpd and ospfd play nicely with route redistribution. > >> > >> So far the only way I have found that suits my need is to use > >> bgpd.conf network statements and rtlabels. > >> > >> So, to make ospfd learn route from bgpd I use rtlabels. So in bgpd.conf: > >> match from set rtlabel from_bgpd > >> > >> And in ospfd.conf: > >> redistribute rtlabel from_bgpd > >> > >> > >> So far so good. But the other way around, to bake bgpd learn from > >> ospfd it becomes a bit more tedious. The only way I have found to make > >> bgpd announce ospf originated routes (to its bgp peers) is via network > >> statements in bgpd.conf. These network statements are not conditional > >> on the availability of such a route in ospf though so they are not > >> very dynamic anymore. > >> > >> I understand that it according to standard > >> (https://tools.ietf.org/html/rfc1364) should be something that is > >> explicit for type 1 and 2 LSAs. > >> > >> What is the recommended way to achieve dynamic explicit route > >> redistribution in both directions? > > Network statements are the correct way. > > > > You can use > > > > network (inet|inet6) priority ... > > network (inet|inet6) rtlabel ... > > > > So with > > > >network inet priority 32 > > > > you should be able to redistribute all ospf routes into bgp. > > > > If this does not help, please explain your problem further (and include your > > config). > > > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot) for > > this as there was at least a bugfix for route-labels.) > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer > setting them per area, or per interface where a route was learned. > just wondering why is it not implemented yet. is that too complex > change? or just not necessary? > > thank you. >
Re: Redistributing between bgpd and ospfd
On Mon, Oct 15, 2018 at 02:48:31PM +0300, Gregory Edigarov wrote: > On 15.10.18 12:58, Sebastian Benoit wrote: > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: > > > Hello, > > > > > > I am trying to get bgpd and ospfd play nicely with route redistribution. > > > > > > So far the only way I have found that suits my need is to use > > > bgpd.conf network statements and rtlabels. > > > > > > So, to make ospfd learn route from bgpd I use rtlabels. So in bgpd.conf: > > > match from set rtlabel from_bgpd > > > > > > And in ospfd.conf: > > > redistribute rtlabel from_bgpd > > > > > > > > > So far so good. But the other way around, to bake bgpd learn from > > > ospfd it becomes a bit more tedious. The only way I have found to make > > > bgpd announce ospf originated routes (to its bgp peers) is via network > > > statements in bgpd.conf. These network statements are not conditional > > > on the availability of such a route in ospf though so they are not > > > very dynamic anymore. > > > > > > I understand that it according to standard > > > (https://tools.ietf.org/html/rfc1364) should be something that is > > > explicit for type 1 and 2 LSAs. > > > > > > What is the recommended way to achieve dynamic explicit route > > > redistribution in both directions? > > Network statements are the correct way. > > > > You can use > > > > network (inet|inet6) priority ... > > network (inet|inet6) rtlabel ... > > > > So with > > > >network inet priority 32 > > > > you should be able to redistribute all ospf routes into bgp. > > > > If this does not help, please explain your problem further (and include your > > config). > > > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot) for > > this as there was at least a bugfix for route-labels.) > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer > setting them per area, or per interface where a route was learned. > just wondering why is it not implemented yet. is that too complex change? or > just not necessary? > Until now there has not been a need for this. In general and probably best common practice is to not mix BGP and OSPF. Instead OSPF is building the underlaying network to run BGP on top of. This is why benno@ was asking for the use case. By the way, because of the nature of OSPF it does not make sense to tag routes by interface, doing it by area could be an option but that comes with some edge cases that need further inspection. -- :wq Claudio
Re: Redistributing between bgpd and ospfd
On 15.10.18 12:58, Sebastian Benoit wrote: open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: Hello, I am trying to get bgpd and ospfd play nicely with route redistribution. So far the only way I have found that suits my need is to use bgpd.conf network statements and rtlabels. So, to make ospfd learn route from bgpd I use rtlabels. So in bgpd.conf: match from set rtlabel from_bgpd And in ospfd.conf: redistribute rtlabel from_bgpd So far so good. But the other way around, to bake bgpd learn from ospfd it becomes a bit more tedious. The only way I have found to make bgpd announce ospf originated routes (to its bgp peers) is via network statements in bgpd.conf. These network statements are not conditional on the availability of such a route in ospf though so they are not very dynamic anymore. I understand that it according to standard (https://tools.ietf.org/html/rfc1364) should be something that is explicit for type 1 and 2 LSAs. What is the recommended way to achieve dynamic explicit route redistribution in both directions? Network statements are the correct way. You can use network (inet|inet6) priority ... network (inet|inet6) rtlabel ... So with network inet priority 32 you should be able to redistribute all ospf routes into bgp. If this does not help, please explain your problem further (and include your config). (Note that you should run OpenBSD 6.4 (just use the latest snapshot) for this as there was at least a bugfix for route-labels.) wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer setting them per area, or per interface where a route was learned. just wondering why is it not implemented yet. is that too complex change? or just not necessary? thank you.
Re: Redistributing between bgpd and ospfd
open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200: > Hello, > > I am trying to get bgpd and ospfd play nicely with route redistribution. > > So far the only way I have found that suits my need is to use > bgpd.conf network statements and rtlabels. > > So, to make ospfd learn route from bgpd I use rtlabels. So in bgpd.conf: > match from set rtlabel from_bgpd > > And in ospfd.conf: > redistribute rtlabel from_bgpd > > > So far so good. But the other way around, to bake bgpd learn from > ospfd it becomes a bit more tedious. The only way I have found to make > bgpd announce ospf originated routes (to its bgp peers) is via network > statements in bgpd.conf. These network statements are not conditional > on the availability of such a route in ospf though so they are not > very dynamic anymore. > > I understand that it according to standard > (https://tools.ietf.org/html/rfc1364) should be something that is > explicit for type 1 and 2 LSAs. > > What is the recommended way to achieve dynamic explicit route > redistribution in both directions? Network statements are the correct way. You can use network (inet|inet6) priority ... network (inet|inet6) rtlabel ... So with network inet priority 32 you should be able to redistribute all ospf routes into bgp. If this does not help, please explain your problem further (and include your config). (Note that you should run OpenBSD 6.4 (just use the latest snapshot) for this as there was at least a bugfix for route-labels.)
