<div dir="ltr"><div><div><div><div>Hi, Boris.<br></div>Why do you use both protocol (OSPF and BGP) between the core router and the border router?<br></div>I think you have at least two ways to solve your issue.<br></div>First way is pretty simple - don't use OSPF between the core router and the border. It will make your setup is pretty simple: the core router advertise only aggregated prefix (from static protocol) to the border, then this prefix is being advertised with eBGP into upstream domain; the border advertise all prefixes from upstream to the core router; the core router advertise default router through itself into the OSPF domain. Obviously, you don't need redistribute the iBGP into OSPF and vice versa.<br></div>Second way: you can separate the routes from OSPF and iBGP with different routing tables (RIB) inside bird, and advertise the aggregated route into upstream domain with eBGP. Also, you can use the route leaking with the pipe protocol between RIBs.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-27 15:07 GMT+03:00 Борис Коваленко <span dir="ltr"><<a href="mailto:b.ju.kovalenko@gmail.com" target="_blank">b.ju.kovalenko@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ok, Martin. Let speak in general. The topology is very simple:<div>There is set of "area" routers speaking with "core" router by ospf. Core router has "supernet" routed to null (ip route X.X.X.X/20 null0) to avoid forwading loops to unallocated IPs. And it also injects this route into ospf and bgp with "redistribute static". When route is injected into bgp it gets some communities for further processing. Core router is speaking to border router by ospf and bgp. So on border router we get two routes X.X.X.X/20 ospf E2 type, and X.X.X.X/20 ibgp. OSPF wins, and route can not be announced to ebgp peers. What do You suggest? Change preference for OSPF - so we break igp?</div><div><br></div><div>This is my knowlegde from cisco/quagga world. And it does not work with bird. Where is my mistake?</div><div><br></div><div>Regards,</div><div>Boris</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">пн, 27 февр. 2017 г. в 16:50, Martin Mares <<a href="mailto:mj@ucw.cz" target="_blank">mj@ucw.cz</a>>:<br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br class="m_-4952965573093983217gmail_msg">
<br class="m_-4952965573093983217gmail_msg">
> I'm newbie to bird. Used cisco/quagga before. But filter language of bird<br class="m_-4952965573093983217gmail_msg">
> is very nice, so I want to try it. But I have one big misunderstanding.<br class="m_-4952965573093983217gmail_msg">
> With other vendors each protocol has it own routing table. So OSPF may work<br class="m_-4952965573093983217gmail_msg">
> only with ospf prefixes, BGP with bgp and so on. If we need protocol to get<br class="m_-4952965573093983217gmail_msg">
> access to other routing tables there are redistribute XXX commands.<br class="m_-4952965573093983217gmail_msg">
><br class="m_-4952965573093983217gmail_msg">
> Unfortunatelly in bird there is one "super" table by default. So i get<br class="m_-4952965573093983217gmail_msg">
> sutiation where I have to prefixes on router, one from static protocol, and<br class="m_-4952965573093983217gmail_msg">
> one from ibgp. Prefix from ibgp has some communities on it, and I use this<br class="m_-4952965573093983217gmail_msg">
> communities in filters to ebgp. But static prefix always win. By some<br class="m_-4952965573093983217gmail_msg">
> reason I can't remove static prefix and use ibgp prefix and also can't add<br class="m_-4952965573093983217gmail_msg">
> communities to static prefix as they are changed by other router.<br class="m_-4952965573093983217gmail_msg">
<br class="m_-4952965573093983217gmail_msg">
Generally speaking, what you export to other routers should be a subset of<br class="m_-4952965573093983217gmail_msg">
what you really use for forwarding packets. Otherwise you are inviting routing<br class="m_-4952965573093983217gmail_msg">
loops and other problems. (There are exceptions to this rule, for example when<br class="m_-4952965573093983217gmail_msg">
you are running a BGP route reflector, but I suspect it is not your case.)<br class="m_-4952965573093983217gmail_msg">
<br class="m_-4952965573093983217gmail_msg">
>From this point of view, it does make much sense to me what you are trying<br class="m_-4952965573093983217gmail_msg">
to accomplish. If you use the static route for forwarding, you should export<br class="m_-4952965573093983217gmail_msg">
it via eBGP. If the static route is merely a backup for cases when iBGP is<br class="m_-4952965573093983217gmail_msg">
down, adjust its preference so that the iBGP route will be preferred.<br class="m_-4952965573093983217gmail_msg">
<br class="m_-4952965573093983217gmail_msg">
                                Have a nice fortnight<br class="m_-4952965573093983217gmail_msg">
--<br class="m_-4952965573093983217gmail_msg">
Martin `MJ' Mares                          <<a href="mailto:mj@ucw.cz" class="m_-4952965573093983217gmail_msg" target="_blank">mj@ucw.cz</a>>   <a href="http://mj.ucw.cz/" rel="noreferrer" class="m_-4952965573093983217gmail_msg" target="_blank">http://mj.ucw.cz/</a><br class="m_-4952965573093983217gmail_msg">
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth<br class="m_-4952965573093983217gmail_msg">
"It is easier to port a shell than a shell script." -- Larry Wall<br class="m_-4952965573093983217gmail_msg">
</blockquote></div></div></div><div class="HOEnZb"><div class="h5"><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><p dir="ltr">С уважением, <br>
Борис Коваленко </p>
</div></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Anton.</div>
</div>