Hello, On Mon, Oct 15, 2018 at 2:49 PM Claudio Jeker <cje...@diehard.n-r-g.com> 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 <neighbor> 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 >
