[quagga-dev 5575] Re: how do I get my new command to execute at startup?
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