OSPF generate default route - again

Ondrej Zajicek santiago at crfreenet.org
Thu Oct 11 14:20:01 CEST 2018


On Wed, Oct 10, 2018 at 04:07:01PM +0200, Piotr Marciniak wrote:
> Hello,
> 
> I’ve spent some time trying to find any option to make our border BGP router to announce itself as defaul router by OSPF to our network switches. No luck.
> 
> This discussion was rised fe. 5 years ago but with no answer
> (https://bird-users.network.narkive.com/AD6KOk8b/ospf-generate-default-route).
> All docs end examples I found touch only redistribute aspect of the
> problem. I think it is not optimal for such implementations.

Hello

Thanks for your comments, i agree that BIRD needs mechanism that could
be used to generate the default route based on received BGP routes. Our
inability to already deliver it is generally a result of consecutive
generalization and moving goalposts. The idea started as simple
aggregation protocol, developed over time to conditional route protocol,
then to conditional route extension to static protocol and finally to
conditional extensions to filters, leaving behind several batches of
partially written code, postponed several time when more pressing issues
appeared.

I still have some notes / minor objections to your mail (below)


> OK – let draw simple example.
> 
> Step 1.
> 
> Let’s have just 2 border backbone BGP routers with a few peers and full tables. Let’s name them just simple BGP1 and BGP2.
> Of course they talk one to another by iBGP as well. In fact – they know everything about Internet, so they do not need any 0/0 routes – external or static.
> If any peer fails – they will just recalculate tables and everything will work fine.
,,,
> Step 7.
> 
> Theoretically we may imagine that in my example OSPF10 will act as ‘default originate always’ router and forwards packets by static route to BGP1... What a waste. How to secure redundancy supported by BGP2?

There are several cases how BGP1 and BGP2 can be connected. They can be
connected directly (in L3 sense), through intermediate routers having
full BGP table by IBGP, or through intermediate OSPF-only routers. Third
case is problematic in many ways even with proper default route generator
based on BGP state, so i will ignore that case, and the first two cases
are generally the same, so for simplicity i assume that BGP1 and BGP2 are
directly connected.


First remark - suggested setup is that both BGP1 and BGP2 is part of OSPF
domain, do not propagate BGP routes, but both propagate default route,
locally configured as 'unreachable'.

In such setup if e.g. BGP1 (as router) fails, traffic get redirected to
BGP2 by OSPF. If both BGP1 and BGP2 are running, but on BGP1 fails
upstream BGP session, then BGP1 still originates default route and
attracts local traffic, but it has full BGP table received from BGP2 by
iBGP, so received local traffic is forwarded to BGP2 and delivered to
Internet. While there may be an additional hop, there is no blackholing
or broken routing, so it not a big issue that default route is originated
unconditionally.

While in this setup a conditional default route is not a necessary feature,
there are other setups where it is required for redundancy, e.g. if BGP
border routers use BGP only to propagate their range, do not keep full BGP
table and only have default routes to their upstream eBGP neighbors.


Second remark - you seems to mix two independent issues - whether a
default route is originated conditionally or unconditionally and whether
it is originated by an external protocol (e.g. static) or originated
internally by OSPF. While i agree with usefulness of conditional
origination, i do not see a reason for doing it internally by OSPF
instead of externally as regular route. I see several reasons for do
it by e.g. conditional static route:

1) Default route may be necessary outside of OSPF, e.g. in example above
with low-end BGP speakers having conditional default route in FIB.

2) No need to do it independently for OSPF, RIP, Babel and other IGPs.

3) Fits more in BIRD design, uniform way to handle it like other routes,
for e.g. attribute setting.

4) More general tool, could be used to generate not only default route
but also other conditional routes for other purposes.


> This announcement should be based on simple rule that Bird may know from other protocols (like BGP but not only)

BTW, what kind of conditions would you expect to be able to express in
the mentioned simple rule?


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20181011/3f5576ae/attachment.sig>


More information about the Bird-users mailing list