Mailing List Archive

On Wed, Aug 04, 2004 at 12:34:46PM +1200, Matt Brown wrote:
> 1) Does quagga currently support interface configuration and status
> changing while quagga is running?

I certainly don't claim to be an expert on this, but I do believe that
quagga is intended to support this as currently written. That being
said, I have myself encountered some bugs in this functionality that
I have not had a chance to track down. But, in principle, the zebra daemon
should monitor for kernel-generated events indicating interface configuration
and status changes, and zebra should propagate them to ospfd. Have you
tried "debug zebra kernel" and "debug zebra events" to see what's going
on?

-Andy

On Wed, 4 Aug 2004, Matt Brown wrote:

> Initial testing with Quagga 0.96.4 indicates that it cannot handle
> interfaces being taken up and down while it is running, let alone
> having IP addresses and networks change. When these things happen
> Quagga (perhaps understandably :)) seems to give up and sit there
> doing nothing.

Ah.

> I notice in the changelog for 0.96.5 there were some patches
> applied to deal with dynamic point-to-point interfaces, but a note
> seemed to suggest this support was still not complete.

Well, ospfd should be fine. I'm not aware of any major problem with
interface events in ospfd as of 0.96.4, and if there are, it's a bug.

> My question is twofold.
> 1) Does quagga currently support interface configuration and status
> changing while quagga is running?

It should yes, else it's a bug.

- ospfd should not have issues with dealing with interface events
(reported to it by zebra). If you see inconsistencies between ospfd's
view of interfaces and zebra's, and 'debug ospf zebra' shows that
ospfd is receiving the appropriate events, it's a bug.

- zebra generally does not have issues, however, the netlink method
on linux does. Netlink is unreliable, and (AIUI) requires users to
detect inconsistencies and cope (reissue messages and potentially
resynchronise state with the kernel). zebra does not do this. The
problem occurs if you have lots of netlink events (eg lots of
interfaces, and/or a very high rate of events proportional to # of
interfaces). In this case, zebra will not be consistent with kernel.

This can be worked around bi specifying --disable-netlink as a
configure option, however you lose ECMP cability.

> 2) If not (which I assume is the answer to 1), would it be feasible to
> implement that functionality? what would be required?

Depends, if zebra loses consistency with kernel, then you're hitting
the netlink problem, which requires a good bit of work to fix.

Else, if ospfd becomes inconsistent with zebra, that should fixable,
if you can provide 'debug ospf zebra' logs and other relevant
information.

> With regards to question 2 my thinking is that there must be some
> way to do it as I can reconfigure the router via the VTY interface,
> all I need is some way to do this programmatically.

If I understood your question correctly, you shouldnt need to
externally (manually or programmatically) adjust zebra/ospfd to deal
with kernel interface changes.

> I look forward to receiving your feedback.

see above ;)

> Regards

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Tact, n.:
The unsaid part of what you're thinking.

On Wed, 2004-08-04 at 16:00, Paul Jakma wrote:
<snip>
> Depends, if zebra loses consistency with kernel, then you're hitting
> the netlink problem, which requires a good bit of work to fix.
>
> Else, if ospfd becomes inconsistent with zebra, that should fixable,
> if you can provide 'debug ospf zebra' logs and other relevant
> information.

OK. This is good to know. I haven't had time to sit down and try and
reproduce the behaviour that I was seeing yet, so for know I will assume
that quagga is functioning correctly.

> If I understood your question correctly, you shouldnt need to
> externally (manually or programmatically) adjust zebra/ospfd to deal
> with kernel interface changes.

This however, I am not so sure about. From my understanding of how OSPF
works and the configuration that quagga requires, I need to specify a
network blah/blah area blah
style line for each interface that I want OSPF to be active on. At the
time quagga is started I don't know what this network line needs to be,
and indeed even if I do it may change at some point in the future. This
scenario means that I need a way to update quagga's configuration while
it is running.

Does this make sense?

Regards

--
Matt Brown
Email: matt@mattb.net.nz
GSM: +64 21 611 544

On Fri, 6 Aug 2004, Matt Brown wrote:

> OK. This is good to know. I haven't had time to sit down and try and
> reproduce the behaviour that I was seeing yet, so for know I will assume
> that quagga is functioning correctly.

Well, it mightnt be, but you know what to look for now hopefully.

> This however, I am not so sure about. From my understanding of how
> OSPF works and the configuration that quagga requires, I need to
> specify a network blah/blah area blah style line for each interface
> that I want OSPF to be active on.

Each 'network', not interface - it's an inclusive match too.

> At the time quagga is started I don't know what this network line
> needs to be, and indeed even if I do it may change at some point in
> the future.

Surely you know what networks are assigned to/in-use in your
organisation? See above, you can just specify a very general network
prefix, eg 192.168.0.0/16..

> This scenario means that I need a way to update quagga's
> configuration while it is running.
>
> Does this make sense?

Not once you realise a network statement for x/y will enable OSPF on
all interfaces that fall within x/y. ;)

> Matt Brown

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Where you stand depends on where you sit.
-- Rufus Miles, HEW

On Wed, 2004-08-11 at 15:11, Paul Jakma wrote:
> On Fri, 6 Aug 2004, Matt Brown wrote:
>
> > OK. This is good to know. I haven't had time to sit down and try and
> > reproduce the behaviour that I was seeing yet, so for know I will
> assume
> > that quagga is functioning correctly.
>
> Well, it mightnt be, but you know what to look for now hopefully.

OK. It was a little bit tricky to track down, but I've been able to
reproduce the problem that I was seeing. The problem occurs when running
ospfd on a PCMCIA wireless interface.

* Quagga responds correctly when started after the interface is up

Aug 13 15:29:58 shr ospfd[9394]: old umask 23 95
Aug 13 15:29:58 shr ospfd[9394]: Zebra: interface add lo index 1 flags
73 metric 1 mtu 16436
Aug 13 15:29:58 shr ospfd[9394]: Zebra: interface add shr-int index 3
flags 4675 metric 1 mtu 1500
Aug 13 15:29:58 shr ospfd[9394]: interface 10.1.224.1 join AllSPFRouters
Multicast group.
Aug 13 15:29:58 shr ospfd[9394]: Zebra: interface add shr-uni index 7
flags 4163 metric 1 mtu 1500
Aug 13 15:29:58 shr ospfd[9394]: interface 10.1.250.250 join
AllSPFRouters Multicast group.
Aug 13 15:29:58 shr ospfd[9394]: Zebra: interface add teql0 index 2
flags 128 metric 1 mtu 1500

* Quagga responds correctly to a simple up/down of the interface via
ifconfig

Aug 13 15:33:01 shr ospfd[9394]: Zebra: Interface[shr-uni] state change
to up.
Aug 13 15:33:01 shr ospfd[9394]: interface 10.1.250.250 join
AllSPFRouters Multicast group.
Aug 13 15:33:02 shr ospfd[9394]: Zebra: Route add 10.1.250.0/24 nexthop
10.1.250.0
Aug 13 15:33:02 shr ospfd[9394]: Link State Update: Unknown Neighbor
10.1.250.248 on int: shr-uni:10.1.250.250
Aug 13 15:33:02 shr ospfd[9394]: Link State Update: Unknown Neighbor
10.1.250.251 on int: shr-uni:10.1.250.250
Aug 13 15:33:02 shr ospfd[9394]: Link State Update: Unknown Neighbor
10.1.250.248 on int: shr-uni:10.1.250.250
Aug 13 15:33:02 shr ospfd[9394]: Link State Acknowledgment: Unknown
Neighbor 10.1.250.251.
Aug 13 15:33:03 shr ospfd[9394]: Link State Acknowledgment: Unknown
Neighbor 10.1.250.248.

* Quagga doesn't respond correctly to pcmcia being restarted (interface
removed from system, interface added to system)

Aug 13 15:26:14 shr ospfd[9206]: Zebra: interface add eth0 index 7 flags
4098 metric 1 mtu 1500
Aug 13 15:26:15 shr ospfd[9206]: Zebra: interface add shr-uni index 7
flags 4098 metric 1 mtu 1500
Aug 13 15:26:16 shr ospfd[9206]: Zebra: Interface[shr-uni] state change
to up.
Aug 13 15:26:16 shr ospfd[9206]: can't setsockopt IP_DROP_MEMBERSHIP
(AllSPFRouters): Cannot assign requested address

So from what I can see, the kernel is telling Quagga that the interface
has been added, but quagga is failing to activate on it. The output of
show ospf interface says that ospf is not enabled on the interface that
was removed and added. The following links hopefully contain all of the
debugging information that is required.

General Setup Information:
http://www.wand.net.nz/~mglb1/quagga-config-explanation

Debug info when quagga is started with interface already up (control
case)
http://www.wand.net.nz/~mglb1/quagga-interface-already-up

Debug info when the interface is brought up / down via ifconfig
http://www.wand.net.nz/~mglb1/quagga-interface-up-down

Debug info when the interface is removed / added via a PCMCIA restart
http://www.wand.net.nz/~mglb1/quagga-pcmcia-restart

If you need any more information please let me know.

Oh, bugger, I just realised that I did all this testing on 0.96.4 :(
Well I guess I'll go and check that I can reproduce it with 0.96.5.

> > Does this make sense?
>
> Not once you realise a network statement for x/y will enable OSPF on
> all interfaces that fall within x/y. ;)

Indeed, I didn't realise it was an inclusive match. Knowing this solves
99% of my problems, except for those mentioned above :)

Regards

--
Matt Brown
Email: matt@mattb.net.nz
GSM: +64 21 611 544

Aug 13 15:26:14 shr ospfd[9206]: Zebra: interface add eth0 index 7 flags
4098 metric 1 mtu 1500
Aug 13 15:26:15 shr ospfd[9206]: Zebra: interface add shr-uni index 7
flags 4098 metric 1 mtu 1500
Aug 13 15:26:16 shr ospfd[9206]: Zebra: Interface[shr-uni] state change
to up.
Aug 13 15:26:16 shr ospfd[9206]: can't setsockopt IP_DROP_MEMBERSHIP
(AllSPFRouters): Cannot assign requested address

Quagga should have received a kernel event for the interface going
away; you didn't show the log messages for that.

It isn't clear to me why IP_DROP_MEMBERSHIP is being called on a new
interface.

Note the last line. There is a general issue about how multicast
membership is handled across up/down and remove/insert cycles.
quagga may need to be more tolerant of kernel behavior.

--
Greg Troxel <gdt@ir.bbn.com>

On Sat, 2004-08-14 at 01:47, Greg Troxel wrote:

> Quagga should have received a kernel event for the interface going
> away; you didn't show the log messages for that.

Apologies, I've placed the relevant output at

http://www.wand.net.nz/~mglb1/quagga-pcmcia-stop

Hope it is helpful.

Regards

--
Matt Brown
Email: matt@mattb.net.nz
GSM: +64 21 611 544

Aug 14 02:21:59 shr ospfd[9394]: can't setsockopt IP_DROP_MEMBERSHIP (AllSPFRouters): Cannot assign requested address

So there is an error there as well.
I'd suggest that you test with -current quagga (from CVS), and read
the code in ospfd near AllSPFRouters group membership manipulation,
and perhaps change errors to warnings so that e.g. failing to leave
the group is not an error, and perhaps even failing to join (since a
cause of failing to join can be that the group is already joined).

It isn't clear to me what the right OS behavior is when a socket is
joined to a group on an interface and the interface goes away. All
that's clear is that this case isn't very well thought out and
documented...

On Fri, 13 Aug 2004, Greg Troxel wrote:

> I'd suggest that you test with -current quagga (from CVS),

Err, no with 0.96.5. Current CVS ospfd has some issues on Linux which
I need to fix (due to the sockopt consolidation stuff i checked in
the other week). ;)

> It isn't clear to me what the right OS behavior is when a socket is
> joined to a group on an interface and the interface goes away.
> All that's clear is that this case isn't very well thought out and
> documented...

I've yet to stare properly at Matt's debug logs, but from a glance
they seem strange, eg where's the link-down event?

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Abraham Lincoln didn't die in vain. He died in Washington, D.C.

On Sat, 2004-08-14 at 02:59, Paul Jakma wrote:
> On Fri, 13 Aug 2004, Greg Troxel wrote:
>
> > I'd suggest that you test with -current quagga (from CVS),
>
> Err, no with 0.96.5. Current CVS ospfd has some issues on Linux which
> I need to fix (due to the sockopt consolidation stuff i checked in
> the other week). ;)

Ok. I can confirm that the problem still exists in 0.96.5. The log of
ospfd's debug output while I execute /etc/init.d/pcmcia restart is found
at
http://www.wand.net.nz/~mglb1/quagga-0.96.5-pcmcia-restart

It is pretty much identical to the log for 0.96.4 except I have left the
messages related to pcmcia in for context, and right at the end there
are several errors relating to md5 authentication mismatches.

The output of sho ospf interface, etc is the same as for 0.96.4

root@shr:~# /usr/lib/quagga/ospfd -v
ospfd version 0.96.5 ()
Copyright 1996-2001, Kunihiro Ishiguro

> I've yet to stare properly at Matt's debug logs, but from a glance
> they seem strange, eg where's the link-down event?

Sorry, I didn't include that part in the original logs. You'll see the
link down in the output linked to above, or for 0.96.4 you can find it
at
http://www.wand.net.nz/~mglb1/quagga-pcmcia-stop

Hope this helps.

Regards

--
Matt Brown
Email: matt@mattb.net.nz
GSM: +64 21 611 544

On Sat, 14 Aug 2004, Matt Brown wrote:

> Hope this helps.

hmmm.. what's this shr-uni interface? And why do you get both shr-uni
and eth0 come up when you bring up your wifi link? Are the two
related somehow?

Also, can you redo, but with 'debug zebra kernel' set in the zebra
daemon (and logging to syslog like the rest)?

Also, could I see 'show interface' from zebra, and 'show ip ospf
interface' before and after each state change?

> Regards

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish.
-- Marshall McLuhan

On Sat, 14 Aug 2004, Paul Jakma wrote:

>
> hmmm.. what's this shr-uni interface? And why do you get both
> shr-uni and eth0 come up when you bring up your wifi link? Are the
> two related somehow?

Indeed, they must be:

Zebra: interface add eth0 index 9 flags 4098 metric 1 mtu 1500
Zebra: interface add shr-uni index 9 flags 4098 metric 1 mtu 1500

they have the same index.

unless the state of these interfaces track each other precisely,
including assigned addresses, things will get confused..

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
The pollution's at that awkward stage. Too thick to navigate and too
thin to cultivate.
-- Doug Sneyd

On Sat, 2004-08-14 at 15:34, Paul Jakma wrote:

> Indeed, they must be:
>
> Zebra: interface add eth0 index 9 flags 4098 metric 1 mtu 1500
> Zebra: interface add shr-uni index 9 flags 4098 metric 1 mtu 1500
>
> they have the same index.

Because wireless interfaces can come up in any order via PCMCIA we need
a way to definitively refer to an interface for configuration of various
services such as dhcp etc. To do this we rename interfaces based on
their mac address as they are brought up using the nameif utility. This
occurs in the pcmcia scripts that are run when the wireless cards are
'inserted'.

So basically they are exactly the same interface, the name just changes.
This renaming happens before the interface is configured with an IP
address etc.

Requested debug output is at
http://www.wand.net.nz/~mglb1/quagga-pcmcia-restart-full

Before PCMCIA Restart

shr# show interface
Interface lo is up, line protocol detection is disabled
index 1 metric 1 mtu 16436 <UP,LOOPBACK,RUNNING>
inet 127.0.0.1/8
input packets 1287, bytes 92768, dropped 0, multicast packets 0
input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
output packets 1287, bytes 92768, dropped 0
output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
collisions 0
Interface shr-int is up, line protocol detection is disabled
index 3 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,MULTICAST>
HWaddr: 00:00:24:c2:b2:54
inet 10.1.224.1/24 broadcast 10.1.224.255
input packets 7902927, bytes 2147483647, dropped 0, multicast packets 0
input errors 1, length 0, overrun 0, CRC 0, frame 2, fifo 0, missed 0
output packets 4474938, bytes 511773386, dropped 0
output errors 5, aborted 0, carrier 5, fifo 5, heartbeat 0, window 0
collisions 0
Interface shr-uni is up, line protocol detection is disabled
index 10 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,MULTICAST>
HWaddr: 00:02:2d:70:fe:28
inet 10.1.250.250/24 broadcast 10.1.250.255
input packets 952, bytes 244858, dropped 0, multicast packets 0
input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
output packets 658, bytes 112050, dropped 0
output errors 5, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
collisions 0
Interface teql0 is down
index 2 metric 1 mtu 1500 <NOARP>
input packets 0, bytes 0, dropped 0, multicast packets 0
input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
output packets 0, bytes 0, dropped 0
output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
collisions 0

shr# sho ip ospf interface
lo is up
OSPF not enabled on this interface
shr-int is up
Internet Address 10.1.224.1/24, Area 0.0.0.0
Router ID 10.1.224.1, Network Type BROADCAST, Cost: 5
Transmit Delay is 1 sec, State Backup, Priority 1
Designated Router (ID) 10.1.12.254, Interface Address 10.1.224.254
Backup Designated Router (ID) 10.1.224.1, Interface Address 10.1.224.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Neighbor Count is 1, Adjacent neighbor count is 1
shr-uni is up
Internet Address 10.1.250.250/24, Area 0.0.0.0
Router ID 10.1.224.1, Network Type BROADCAST, Cost: 50
Transmit Delay is 1 sec, State DROther, Priority 1
Designated Router (ID) 10.1.250.248, Interface Address 10.1.250.248
Backup Designated Router (ID) 10.1.250.251, Interface Address 10.1.250.251
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:09
Neighbor Count is 6, Adjacent neighbor count is 2
teql0 is down
OSPF not enabled on this interface

After PCMCIA Restart

shr# sho interface
Interface eth0 is down
index 11 metric 1 mtu 1500 <BROADCAST,MULTICAST>
inet 10.1.250.250/24 broadcast 10.1.250.255 shr-uni
input packets 0, bytes 0, dropped 0, multicast packets 0
input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
output packets 0, bytes 0, dropped 0
output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
collisions 0
Interface lo is up, line protocol detection is disabled
index 1 metric 1 mtu 16436 <UP,LOOPBACK,RUNNING>
inet 127.0.0.1/8
input packets 1396, bytes 100493, dropped 0, multicast packets 0
input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
output packets 1396, bytes 100493, dropped 0
output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
collisions 0
Interface shr-int is up, line protocol detection is disabled
index 3 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,MULTICAST>
HWaddr: 00:00:24:c2:b2:54
inet 10.1.224.1/24 broadcast 10.1.224.255
input packets 7903221, bytes 2147483647, dropped 0, multicast packets 0
input errors 1, length 0, overrun 0, CRC 0, frame 2, fifo 0, missed 0
output packets 4475160, bytes 511809350, dropped 0
output errors 5, aborted 0, carrier 5, fifo 5, heartbeat 0, window 0
collisions 0
Interface shr-uni is up, line protocol detection is disabled
index 11 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,MULTICAST>
HWaddr: 00:02:2d:70:fe:28
input packets 11, bytes 1000, dropped 0, multicast packets 0
input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
output packets 2, bytes 228, dropped 0
output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
collisions 0
Interface teql0 is down
index 2 metric 1 mtu 1500 <NOARP>
input packets 0, bytes 0, dropped 0, multicast packets 0
input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0, missed 0
output packets 0, bytes 0, dropped 0
output errors 0, aborted 0, carrier 0, fifo 0, heartbeat 0, window 0
collisions 0

shr# show ip ospf interface
eth0 is down
OSPF is enabled, but not running on this interface
lo is up
OSPF not enabled on this interface
shr-int is up
Internet Address 10.1.224.1/24, Area 0.0.0.0
Router ID 10.1.224.1, Network Type BROADCAST, Cost: 5
Transmit Delay is 1 sec, State Backup, Priority 1
Designated Router (ID) 10.1.12.254, Interface Address 10.1.224.254
Backup Designated Router (ID) 10.1.224.1, Interface Address 10.1.224.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:05
Neighbor Count is 1, Adjacent neighbor count is 1
shr-uni is up
OSPF not enabled on this interface
teql0 is down
OSPF not enabled on this interface

Hope this helps.

Regards

--
Matt Brown
Email: matt@mattb.net.nz
GSM: +64 21 611 544

On Sat, 14 Aug 2004, Matt Brown wrote:

> Because wireless interfaces can come up in any order via PCMCIA we
> need a way to definitively refer to an interface for configuration
> of various services such as dhcp etc. To do this we rename
> interfaces based on their mac address as they are brought up using
> the nameif utility. This occurs in the pcmcia scripts that are run
> when the wireless cards are 'inserted'.
>
> So basically they are exactly the same interface, the name just
> changes. This renaming happens before the interface is configured
> with an IP address etc.

Aha.. so the problem is we dont deal with the name change.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Real computer scientists like having a computer on their desk, else how
could they read their mail?

On Sat, 2004-08-14 at 16:07, Paul Jakma wrote:

> Aha.. so the problem is we dont deal with the name change.

Indeed, it seems so obvious now that it's been mentioned... :)

So how hard of a problem is this to solve? Does quagga get enough
information from the kernel to detect that the interfaces name has
changed and react appropriately?

The thing that confuses me in the output after PCMCIA has been restarted
(show below) is that quagga thinks OSPF is enabled but not running on
eth0, and that it is not even enabled on shr-uni. If you look at the
ospfd configuration file found at
http://www.wand.net.nz/~mglb1/quagga-config-explanation

you will see that there is a stanza for shr-uni but not for eth0. So if
quagga was going to get confused I would have thought it would be have
been the opposite way around.

shr# show ip ospf interface
eth0 is down
OSPF is enabled, but not running on this interface
lo is up
OSPF not enabled on this interface
shr-int is up
Internet Address 10.1.224.1/24, Area 0.0.0.0
Router ID 10.1.224.1, Network Type BROADCAST, Cost: 5
Transmit Delay is 1 sec, State Backup, Priority 1
Designated Router (ID) 10.1.12.254, Interface Address 10.1.224.254
Backup Designated Router (ID) 10.1.224.1, Interface Address 10.1.224.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:05
Neighbor Count is 1, Adjacent neighbor count is 1
shr-uni is up
OSPF not enabled on this interface
teql0 is down
OSPF not enabled on this interface


Thanks very much for all your help so far in debugging this problem.

Regards

--
Matt Brown
Email: matt@mattb.net.nz
GSM: +64 21 611 544

On Sat, 14 Aug 2004, Matt Brown wrote:

> So how hard of a problem is this to solve?

I'm just looking at it now.

> Does quagga get enough information from the kernel to detect that
> the interfaces name has changed and react appropriately?

Well, the information is there but, annoyingly, the name change is
implied. Nice thing about rtnetlink was, I thought, that everything
was explicit, no hidden rules to have to worry about or bite you in
the rear-end. But apparently not so.. rtnetlink hack #1.

> The thing that confuses me in the output after PCMCIA has been
> restarted (show below) is that quagga thinks OSPF is enabled but
> not running on eth0, and that it is not even enabled on shr-uni. If
> you look at the ospfd configuration file found at
> http://www.wand.net.nz/~mglb1/quagga-config-explanation
>
> you will see that there is a stanza for shr-uni but not for eth0.
> So if quagga was going to get confused I would have thought it
> would be have been the opposite way around.

Ah well, no, it does make sense. Before the restart, everything is
fine. Upon the restart, we get eth0, create ifp, we get the shr-uni
newlink and create the ifp for that. When we get the newlink/link-up
message we lookup by name and get shr-uni and set it up, when we get
the newaddr message we lookup by index, get eth0 and add the address
there. so you get eth0, down with address and shr-uni, up but no
address. The OSPF enabling is done by searching for addresses, so we
enable eth0 (but its down).

> Thanks very much for all your help so far in debugging this problem.

Try the attached patch against 0.96.5. It's a quick hack[1], only
compile tested and I'm tired so it probably wont work.. but if it
runs i'd be interested in same kernel<->zebra and zebra<->ospfd debug
output as well as zebra and ospfd interface command output
before/after each state change for the restart and rename case.

> Regards

1. for real fix, i'll make rename explicit in the Zserv protocol.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
A free society is one where it is safe to be unpopular.
-- Adlai Stevenson

On Sat, 2004-08-14 at 17:27, Paul Jakma wrote:

> Try the attached patch against 0.96.5. It's a quick hack[1], only
> compile tested and I'm tired so it probably wont work.. but if it
> runs i'd be interested in same kernel<->zebra and zebra<->ospfd debug
> output as well as zebra and ospfd interface command output
> before/after each state change for the restart and rename case.

It breaks :( See the URL below for the output
http://www.wand.net.nz/~mglb1/quagga-patched-output

If I get a chance later today I'll see if I can make head or tail of why
it isn't working. I've never looked at the quagga/zebra source before
however so my contribution may not be too helpful!

Regards

--
Matt Brown
Email: matt@mattb.net.nz
GSM: +64 21 611 544

On Mon, 16 Aug 2004, Matt Brown wrote:

> It breaks :( See the URL below for the output
> http://www.wand.net.nz/~mglb1/quagga-patched-output

Hmm... but notice the zebra side of it seems to have worked. ;)

> If I get a chance later today I'll see if I can make head or tail
> of why it isn't working. I've never looked at the quagga/zebra
> source before however so my contribution may not be too helpful!

Sure, I'll have another look myself too.

> Regards
>
> --
> Matt Brown

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
If God had really intended men to fly, he'd make it easier to get to the
airport.
-- George Winters

On Fri, 13 Aug 2004, Paul Jakma wrote:

> Err, no with 0.96.5. Current CVS ospfd has some issues on Linux which I need

Now fixed.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
If you continually give you will continually have.