[Xorp-hackers] Soft-wiring RIB

[Pavlin Radoslavov]

> Now that there's some semblance of route redistribution happening via 
> the RIB, it's become apparent that there is a start up ordering issue 
> when one protocol process imports routes from another.  There's also a 
> potential source of confusion in table names.  I believe adding 
> additional RIB configuration can solve both problems.
> 
> In the template files we specify dependencies.  The RIB depends on the 
> FEA, protocols typically depend on the RIB.  We typically don't have 
> routing protocols depending on each other.  Using RIP and static routes 
> as an example, RIP does not depend on the static routes process.  
> However, if the RIP configuration specifies importing routes from the 
> static routes process, it implicitly depends on it.  As the rtrmgr is 
> now, RIP ends up being configured before the static routes process so 
> when RIP requests the RIB to redistribute routes from the static routes 
> table it fails because the static routes table has not yet been created 
> by the static routes process.
> 
> One solution would be to change the code so that a redistribution 
> request creates the protocol origin table in the RIB if it does not 
> exist already.  So RIP asking for static routes, would create the 
> static routes table in the RIB.  This has potential for hiding errors.
> 
> A more elegant solution might be to explicitly state protocols and in 
> the RIB section of the configuration file.  So when the RIB starts, 
> origin tables are added for named protocols and administrative 
> distances associated with the protocols too.  This would make the table 
> names visible in the configuration file and make it easier to enable 
> redistribution (since one doesn't have to guess or know existing table 
> names) and we would no longer have to have hard-coded admin distances 
> in the RIB.

You have my vote for the latter solution. I know of at least one
case when a XORP hacker had to modify rib.cc just to add support for
another protocol. I had to do the same thing with the "fib2mrib"
module.
Moving that info to the template/config files would be much nicer.

> We could go one step further by having protocol sections state which 
> origin tables they will provide routes to.  This makes the RIB origin 
> table relations explicit.

I am missing some of the details here, hence can you provide an
example (e.g., a sample config section) so it can become clearer to
me.

Pavlin

> 
> Does this seem reasonable?
> 	Orion
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers