G'day Peter, On Wed, 24 Mar 2004, Peter E. Abresch Jr. - at Pepco wrote:
> when I use "ifconfig eth1 up", the eth1 interface comes up but OSPFD never > detects that it is available. Eth1 routes are never injected back into the > routing table. When eth0 goes down, everyone drops even though eth1 is up > and fully functional. The only method to get OSPFD to recognized an > interface once it has gone down is to restart OSPFD which obviously is > disruptive. Does anyone have any recommendations or ideas? Thanks. I have found that the zebra daemon can get in a knot sometimes when it does not set the IP address of the interfaces in question. What I had to do for reliable OSPF operation (this is on a Red Hat 7.2 s390 system, BTW), is to remove all IP address details from the relevant /etc/sysconfig/network-scripts/ifcfg-* files and use the "ip address" syntax in the zebra.conf file to allow zebra to configure the IP address. Since there does not seem to be a way to set physical characteristics like MTU size in zebra.conf, I left these in ifcfg-*. In the same theme, I've also found that using the Linux commands (like ifconfig, route, ip, etc) on a box running zebra can be "unreliable". Zebra really likes to take control and ownership of the routing function, and using the Linux commands to operate on interfaces and routes outside of zebra's control can upset it. It becomes necessary to really think of the box as a router now, and use the router commands from the routing daemon -- yes, this includes the famous Cisco IOS "shutdown" command to deactivate an interface and its inverse to activate the interface, "no shutdown". Use your normal method to get a zebra prompt (telnet to the command port, or the preferred 'vtysh' program), switch to enable mode, and away you go[1]. In your case, since you're using zebra for VIPA (so I'm assuming this is a server system and not a network router image), it might be hard to think of it that way... It could be argued that either set of commands should work; I don't know if Quagga (the routing daemon formerly known as Zebra) will offer any relief on this. Cheers, Vic Cross [1] I remember someone writing about how to set up a userid that runs vtysh as its shell, allowing a router admin to get access to zebra without having to have their own shell account... Oh yeah, that's right, it was me, in the SHARE presentation from last year that I never got around to sending to Mark... D'oh... RSN... :) ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
