[quagga-dev 5575] Re: how do I get my new command to execute at startup?

Joakim Tjernlund Joakim.Tjernlund at transmode.se
Tue Jul 8 13:44:22 BST 2008

> -----Original Message-----
> From: Andrew J. Schorr [mailto:aschorr at telemetry-investments.com]
> Sent: den 7 juli 2008 17:11
> To: Joakim Tjernlund
> Cc: 'Parthiparaj.G'; quagga-dev at lists.quagga.net
> Subject: Re: [quagga-dev 5569] Re: how do I get my new command to execute at startup?
> On Mon, Jul 07, 2008 at 04:53:11PM +0200, Joakim Tjernlund wrote:
> > It is a bit tricky to do this, ip ospf cost is easier.
> > Still, someone mentioned that Cisco does it the other way around
> > and to me it makes more sense to do it the Cisco way. Still
> > looking for why it is the other way around in Quagga. Would
> > stuff break if the order was changed?
> I don't know how Cisco does it; are you saying that it rejects the 'ip ospf
> area' interface subcommand if the OSPF routing protocol is not active?  That

No, I am just saying that someone mentioned that Cisco stores the interface part
after the router ospf section. That seemed like a good idea for quagga too.

> seems rather odd.  So if somebody disables OSPF (by entering 'no router ospf'),
> are the 'ip ospf area' interface subcommands purged from the config?  If yes,
> then that's pretty ugly.  And if not, when the ospf protocol is enabled again,
> then it must process the 'ip ospf area' commands at that time, on a deferred
> basis, right?

Don't know and I agree that the above described behavior isn't good.

> My general sense is that the interface subcommands need to be able
> to be processed asynchronously with respect to the routing protocol
> configuration commands.  If you want to implement a command
> that sets the area for an interface but that requires the ospf routing
> protocol to be available, then perhaps you should implement this
> as a router subcommand instead of as an interface subcommand?
> For example:
>    router ospf
>       interface eth0 area 3
> But I don't know whether it's worth it to invent new syntax for
> this feature, it would be nice to maintain compatibility...

Yes, compatibility is good and I guess that quagga impl.
a compatible command interface so Quagga should probably stay compatible.

When I return from vacation I will have another look at the impl.


More information about the Quagga-dev mailing list