AW: [Xorp-hackers] XORP SH dumps core on FreeBSD 5.4-RELEASE

[Patrick Preuss]

Hello Pavlin,

> Just for the record, the bug (#171) is fixed and committed to CVS. Please
> let me know if it still doesn't work for you.

Thanks I will test it later this day. 

>> is it possible to exened the rtrmrg is aware of all interfaces in the
system
>> preset interfaces and the types of software interfaces witch can
configured.
>> most likely the os configured interfaces in the show interfaces marked as
>> unconfigured or as os-unconfigured/xorp-unconfigured or stm. like that. 

> The rtrmgr doesn't contain (by design) any information about
> the system itself (or any protocol/module specific information). All
> it contains is the configuration, the generic methods as defined
> in the rtrmgr templates to (re)configurure the system whenever the
> configuration is applied or modified, and the status of each running
> module.

> It looks like what you need is the "show interfaces" CLI command to
> show that information. Yes, it is possible and all that needs to be
> done is to modify the fea/tools/show_interfaces binary program to
> show that info.
> Please add a bugzilla "enhancement" entry with the above request.

Yes I will post something but I would prefer to discuss it in advance. 
I have though of something like a daemon "xorp_ifmgr" which does this work,
and not the show interfaces command, because if you hardcode this into the
show command you will have an os specific solution. What is if we have a
distributed system, or we run the xorpsh on a different host witch is only
aware of the rtrmgr? I think you will have problems in simulating routers. 

And for the discussion about the interface naming it will be possible to add
an system or a convention to abstract the hardware interfaces from the
Router so the ifmgr can hold a config, maybe private, witch says eth0 is
FastEthernet0 with build in mac of 00:00:00:00:00:01 and is on pci bus
00:01:f, so if a physical interface changes or is added this can be
reflected in the config and the running processes.  

Last point is, it would be nice that the rib/rtrmgr is aware of the kernel
routes, so it would be possible to check the actual state of our routing
table, like the junipers also do, may be a daemon. 

Regards,
	Patrick