Mailing List Archive: Quagga: Bugs

[Bug 330] routes disappear with 'could not determine nexthop' log entry

Index | Next | Previous | View Threaded

bugzilla-daemon at allevil

Jan 3, 2007, 4:50 AM

Post #1 of 25 (4832 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

------- Additional Comments From windo [at] p6drad-teel 2007-01-03 12:50 -------
Created an attachment (id=127)
--> (http://bugzilla.quagga.net/attachment.cgi?id=127&action=view)
ospfd.log around that happening

attaching a log excrept with all sorts of debugging enabled

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 8, 2007, 1:15 PM

Post #2 of 25 (4719 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

windo [at] p6drad-teel changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #127 is|0 |1
obsolete| |

------- Additional Comments From windo [at] p6drad-teel 2007-01-03 13:26 -------
Created an attachment (id=128)
--> (http://bugzilla.quagga.net/attachment.cgi?id=128&action=view)
log excrept around the problem

------- Additional Comments From ajschorr [at] alumni 2007-01-08 21:15 -------
I think it might help to post the output of 'show interface'
and 'show ip ospf interface' so we can get an idea of the
config...

Regards,
Andy

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 11, 2007, 12:51 AM

Post #3 of 25 (4728 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

------- Additional Comments From windo [at] p6drad-teel 2007-01-11 08:51 -------
This time i had to block and reenable the lower-cost link back and forth as
quickly as possible (so that ospf would see that it's gone and come back) to
reproduce this behaviour.

both ends have the same config:

bond0 is up
ifindex 24, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
Internet Address 192.168.36.149/24, Broadcast 192.168.36.255, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 192.168.36.149, Network Type NBMA, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 192.168.36.149, Interface Address 192.168.36.149
No backup designated router on this network
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 7.957s
Neighbor Count is 0, Adjacent neighbor count is 0
bond1 is up
ifindex 25, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
OSPF not enabled on this interface
dummy0 is up
ifindex 4, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,NOARP>
Internet Address 192.168.98.0/24, Broadcast 192.168.98.255, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 192.168.36.149, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 192.168.36.149, Interface Address 192.168.98.0
No backup designated router on this network
Multicast group memberships: OSPFAllRouters OSPFDesignatedRouters
Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
Hello due in 7.957s
Neighbor Count is 0, Adjacent neighbor count is 0
eth0 is up
ifindex 1, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
OSPF not enabled on this interface
eth1 is up
ifindex 2, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST>
OSPF not enabled on this interface
lo is up
ifindex 3, MTU 16436 bytes, BW 0 Kbit <UP,LOOPBACK,RUNNING>
OSPF not enabled on this interface
t-dcl-cpn-tdc is up
ifindex 27, MTU 1500 bytes, BW 0 Kbit <UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>
Internet Address 10.1.0.2/32, Peer 10.1.0.1, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 192.168.36.149, Network Type POINTOPOINT, Cost: 40
Transmit Delay is 1 sec, State Point-To-Point, Priority 1
No designated router on this network
No backup designated router on this network
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 5s, Dead 20s, Wait 20s, Retransmit 5
Hello due in 3.169s
Neighbor Count is 1, Adjacent neighbor count is 1
t-dcl-cpn-tdc-2 is up
ifindex 26, MTU 1500 bytes, BW 0 Kbit <UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>
Internet Address 10.1.0.4/32, Peer 10.1.0.3, Area 0.0.0.0
MTU mismatch detection:enabled
Router ID 192.168.36.149, Network Type POINTOPOINT, Cost: 50
Transmit Delay is 1 sec, State Point-To-Point, Priority 1
No designated router on this network
No backup designated router on this network
Multicast group memberships: OSPFAllRouters
Timer intervals configured, Hello 5s, Dead 20s, Wait 20s, Retransmit 5
Hello due in 3.021s
Neighbor Count is 1, Adjacent neighbor count is 1

Interface bond0 is up, line protocol detection is disabled
index 24 metric 1 mtu 1500
flags: <UP,BROADCAST,RUNNING,MULTICAST>
HWaddr: 00:0e:7f:b4:a9:81
inet 192.168.36.149/24 broadcast 192.168.36.255
31034 input packets (8510 multicast), 6273020 bytes, 0 dropped
0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame
0 fifo, 0 missed
8802 output packets, 617875 bytes, 0 dropped
0 output errors, 0 aborted, 0 carrier, 0 fifo, 0 heartbeat
0 window, 0 collisions
Interface bond1 is up, line protocol detection is disabled
index 25 metric 1 mtu 1500
flags: <UP,BROADCAST,RUNNING,MULTICAST>
HWaddr: 00:0e:7f:b4:89:e3
inet 80.92.84.57/24 broadcast 80.92.84.255
505828 input packets (193 multicast), 44771931 bytes, 0 dropped
0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame
0 fifo, 0 missed
192800 output packets, 29091375 bytes, 0 dropped
0 output errors, 0 aborted, 0 carrier, 0 fifo, 0 heartbeat
0 window, 0 collisions
Interface dummy0 is up, line protocol detection is disabled
index 4 metric 1 mtu 1500
flags: <UP,BROADCAST,RUNNING,NOARP>
HWaddr: 8a:40:a3:6f:73:c6
inet 192.168.98.0/24 broadcast 192.168.98.255
0 input packets (0 multicast), 0 bytes, 0 dropped
0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame
0 fifo, 0 missed
104454 output packets, 8147412 bytes, 0 dropped
0 output errors, 0 aborted, 0 carrier, 0 fifo, 0 heartbeat
0 window, 0 collisions
Interface eth0 is up, line protocol detection is disabled
index 1 metric 1 mtu 1500
flags: <UP,BROADCAST,RUNNING,MULTICAST>
HWaddr: 00:0e:7f:b4:89:e3
505828 input packets (193 multicast), 44771931 bytes, 0 dropped
0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame
0 fifo, 0 missed
192800 output packets, 29091375 bytes, 0 dropped
0 output errors, 0 aborted, 0 carrier, 0 fifo, 0 heartbeat
0 window, 0 collisions
Interface eth1 is up, line protocol detection is disabled
index 2 metric 1 mtu 1500
flags: <UP,BROADCAST,RUNNING,MULTICAST>
HWaddr: 00:0e:7f:b4:a9:81
31034 input packets (8510 multicast), 6273020 bytes, 0 dropped
0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame
0 fifo, 0 missed
8802 output packets, 617875 bytes, 0 dropped
0 output errors, 0 aborted, 0 carrier, 0 fifo, 0 heartbeat
0 window, 0 collisions
Interface lo is up, line protocol detection is disabled
index 3 metric 1 mtu 16436
flags: <UP,LOOPBACK,RUNNING>
inet 127.0.0.1/8
5143981 input packets (0 multicast), 449793261 bytes, 0 dropped
0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame
0 fifo, 0 missed
5143981 output packets, 449793261 bytes, 0 dropped
0 output errors, 0 aborted, 0 carrier, 0 fifo, 0 heartbeat
0 window, 0 collisions
Interface t-dcl-cpn-tdc is up, line protocol detection is disabled
index 27 metric 1 mtu 1500
flags: <UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>
inet 10.1.0.2/32 pointopoint 10.1.0.1
21529 input packets (0 multicast), 2002586 bytes, 0 dropped
0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame
0 fifo, 0 missed
10220 output packets, 950158 bytes, 0 dropped
0 output errors, 0 aborted, 0 carrier, 0 fifo, 0 heartbeat
0 window, 0 collisions
Interface t-dcl-cpn-tdc-2 is up, line protocol detection is disabled
index 26 metric 1 mtu 1500
flags: <UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>
inet 10.1.0.4/32 pointopoint 10.1.0.3
48253 input packets (0 multicast), 3863806 bytes, 0 dropped
0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame
0 fifo, 0 missed
38064 output packets, 4085038 bytes, 0 dropped
0 output errors, 0 aborted, 0 carrier, 0 fifo, 0 heartbeat
0 window, 0 collisions

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 11, 2007, 4:22 AM

Post #4 of 25 (4724 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

bugzilla-daemon at allevil

Jan 11, 2007, 6:36 AM

Post #5 of 25 (4707 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

------- Additional Comments From ajschorr [at] alumni 2007-01-11 14:36 -------
Sorry to be so slow, but can you explain a bit more about the topology?
Which links are you bringing up and down? Is it the
two PtP links t-dcl-cpn-tdc and t-dcl-cpn-tdc-2? What's the output
of 'show ip ospf neighbor' when everything is working normally?

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 11, 2007, 6:44 AM

Post #6 of 25 (4699 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

bugzilla-daemon at allevil

Jan 11, 2007, 6:59 AM

Post #7 of 25 (4704 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

------- Additional Comments From ajschorr [at] alumni 2007-01-11 14:54 -------
What exactly are you doing with iptables to block the packets?
Do you see the same problems if you simply unplug the connection
physically (instead of using iptables)? One of your posts
seems to suggest that traffic is still flowing in one direction
over the link. Are you using iptables to block traffic
in only one direction on the link?

------- Additional Comments From windo [at] p6drad-teel 2007-01-11 14:59 -------
I am not physically near the servers and can't unplug the cable. Traffic is
blocked in both directionsm, but I'll try to see if blocking only one direction
makes a difference.

Here's a script i use to block the traffic:

#!/bin/sh

action=$1
tunnel="t-tdc-lux-dcl"

case $action in
failover)
echo Sleeping until Hello packet
sleep $(vtysh -c "show ip ospf interface ${tunnel}" | grep
'Hello due in' | awk '{print $4}')

echo Dropping connections
iptables -I OUTPUT -o ${tunnel} -j DROP
iptables -I INPUT -i ${tunnel} -j DROP
iptables -I FORWARD -o ${tunnel} -j DROP
iptables -I FORWARD -i ${tunnel} -j DROP
;;
failback)
iptables -D OUTPUT -o ${tunnel} -j DROP
iptables -D INPUT -i ${tunnel} -j DROP
iptables -D FORWARD -o ${tunnel} -j DROP
iptables -D FORWARD -i ${tunnel} -j DROP
;;
*)
echo "usage: $0 <failover | failback>"
;;
esac

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 11, 2007, 7:09 AM

Post #8 of 25 (4702 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

bugzilla-daemon at allevil

Jan 11, 2007, 7:15 AM

Post #9 of 25 (4714 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

------- Additional Comments From ajschorr [at] alumni 2007-01-11 15:15 -------
Given that Hello is 5 and Dead is 20, what's the longest
outage that you see when you take down a link? Is it clear
that there is a bug here, or is this just normal time
for the network to reconverge?

Have you considered using faster timers to get quicker
convergence? You can use fast hellos perhaps...

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 11, 2007, 7:33 AM

Post #10 of 25 (4722 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

bugzilla-daemon at allevil

Jan 14, 2007, 4:31 PM

Post #11 of 25 (4680 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

bugzilla-daemon at allevil

Jan 15, 2007, 3:38 AM

Post #12 of 25 (4696 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

------- Additional Comments From windo [at] p6drad-teel 2007-01-15 11:38 -------
i'm not very good at spf terms. what i meant was: "it does not consider other
ospf links".

Okay, I'll explain what is happening in the code again, tell me if you
understand this so I can move on from that point (because I still get the
feeling you don't see it as I do).

The problem lies in that ospf_nexthop_calculation may succeed or not succeed,
but it does not return anything. So, if you pleas see comment #5, the first log
shows only one "considering link .. link data 10.1.0.2" line followed by "could
not determine nexthop. So, ospf_nexthop_calculation did not succeed, but in
ospf_spf_next, the allocated vertex w is assigned a cost and it is added to the
candidates (line 811). So, ospf_spf_next does not try to calculate nexthop
through 10.1.0.4 (the other link with higher cost) because for it's purposes
there apparently already is a path with a lower cost at place (line 813, the
cost comparisons).

If I apply my patch, then the check for number of parents effectively checks if
ospf_nexthop_calculation did succeed and only adds the vertex to candidates list
if a nexthop was found (so that the ospf links with higher cost are checked
too). So, now the log is like this for the same situation:

2007/01/15 12:21:14 OSPF: ospf_spf_calculate: Start
2007/01/15 12:21:14 OSPF: ospf_spf_calculate: running Dijkstra for area 0.0.0.0
2007/01/15 12:21:14 OSPF: ospf_vertex_new: Created Router vertex 192.168.36.149
2007/01/15 12:21:14 OSPF: found Router LSA 192.168.25.149
2007/01/15 12:21:14 OSPF: The LSA is already in SPF
2007/01/15 12:21:14 OSPF: ospf_vertex_new: Created Router vertex 192.168.25.149
2007/01/15 12:21:14 OSPF: ospf_nexthop_calculation(): Start
2007/01/15 12:21:14 OSPF: V (parent): Router vertex 192.168.36.149 distance 0
flags 0
2007/01/15 12:21:14 OSPF: W (dest) : Router vertex 192.168.25.149 distance 40
flags 0
2007/01/15 12:21:14 OSPF: ospf_nexthop_calculation(): considering link type 1
link_id 192.168.25.149 link_data 10.1.0.2
2007/01/15 12:21:14 OSPF: ospf_nexthop_calculation(): could not determine
nexthop for link
2007/01/15 12:21:14 OSPF: found Router LSA 192.168.25.149
2007/01/15 12:21:14 OSPF: The LSA is already in SPF
2007/01/15 12:21:14 OSPF: ospf_vertex_new: Created Router vertex 192.168.25.149
2007/01/15 12:21:14 OSPF: ospf_nexthop_calculation(): Start
2007/01/15 12:21:14 OSPF: V (parent): Router vertex 192.168.36.149 distance 0
flags 0
2007/01/15 12:21:14 OSPF: W (dest) : Router vertex 192.168.25.149 distance 50
flags 0
2007/01/15 12:21:14 OSPF: ospf_nexthop_calculation(): considering link type 1
link_id 192.168.25.149 link_data 10.1.0.4
2007/01/15 12:21:14 OSPF: ospf_intra_add_router: Start
2007/01/15 12:21:14 OSPF: ospf_intra_add_router: LS ID: 192.168.25.149
2007/01/15 12:21:14 OSPF: ospf_intra_add_router: this router is neither ASBR nor
ABR, skipping it
2007/01/15 12:21:14 OSPF: found Router LSA 192.168.36.149
2007/01/15 12:21:14 OSPF: The LSA is already in SPF
2007/01/15 12:21:14 OSPF: SPF Result: 0 [R] 192.168.36.149
2007/01/15 12:21:14 OSPF: SPF Result: 1 [R] 192.168.25.149

As you can see, this time the connection to the other router is found, although
exacly the same thing happens on the network.

So, timeframe of what is happening. Router 1 and Router 2 are R1 and R2. Without
the patch:

0: Connectivity is stopped in direction R1->R2
15: Connectiviry is stopped in the other direction too
20: Dead timer on one R2 times out, LSA is sent R2->R1, SPF calculation
triggered on R1
20.xx: SPF calculation does not find a route R1->R2 because only one - the one
with the lower cost - of the (OSPF enabled) links is checked because of what i
think is a bug, routes to R2 (and networks connected to R2) are deleted on R1.
35: Dead timer on R1 times out, the other (OSPF enabled) link is tried (because
the first one is dead) and routes from R2 are added on R1.

with the patch:

0: Connectivity is stopped in direction R1->R2
15: Connectiviry is stopped in the other direction too
20: Dead timer on one R2 times out, LSA is sent R2->R1, SPF calculation
triggered on R1
20.xx: SPF calculation checks the lower-cost link but ospf_nexthop_calculation
fails. My "patch" checks and sees that nexthop was not found and does not add
the vertex to candidates list so that when the next higher-cost link is tried
and a nexthop is found, it gets used. Routes from R2 are not deleted but are
routed through the second link.

I agree that this may be a very bad place to check this (or a bad way), but I
also told you I don't know anything about the way the code is organised, so I
can't patch it any better. Any questions about this?

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 15, 2007, 5:58 AM

Post #13 of 25 (4677 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

------- Additional Comments From paul [at] dishone 2007-01-15 13:58 -------
Ah, I understand you now. So another fix would be to make nexthop_calculation
indicate whether it failed or not. See the simple patch I'm about to attach.

Thanks!

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 15, 2007, 6:19 AM

Post #14 of 25 (4673 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

------- Additional Comments From paul [at] dishone 2007-01-15 14:00 -------
Created an attachment (id=129)
--> (http://bugzilla.quagga.net/attachment.cgi?id=129&action=view)
SPF nexthop calculation can fail, caller needs to know

------- Additional Comments From paul [at] dishone 2007-01-15 14:19 -------
Actually, the deeper bug here is some kind of disparity between
ospf_get_next_link and ospf_lsa_has_link. ospf_spf_nexthop_calculation shouldn't
really fail, it shouldn't be called unless it is known V and W are connected.
ospf_spf_next() uses lsa_hsa_link, nexthop_calculation uses get_link. The
failure seems to be because the former indicated a link exists from W to V, and
then the latter can not find it when called from nexthop_calculation.

Hmm...

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 15, 2007, 1:35 PM

Post #15 of 25 (4677 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

bugzilla-daemon at allevil

Jan 15, 2007, 1:52 PM

Post #16 of 25 (4687 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

paul [at] dishone changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Priority|Very High |High

------- Additional Comments From paul [at] dishone 2007-01-15 21:52 -------
Also, I'm going to set this to 'enhancement'. The current behaviour is, I think,
within spec for the RFC. The behaviour occurs during convergence, as Andrew
noted, and the routers do converge correctly. What is being asked for is a
convergence enhancement.

Implementing this cleanly/efficiently will require some re-organisation i think.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 15, 2007, 4:03 PM

Post #17 of 25 (4672 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

paul [at] dishone changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #129 is|0 |1
obsolete| |

------- Additional Comments From paul [at] dishone 2007-01-16 00:01 -------
Created an attachment (id=130)
--> (http://bugzilla.quagga.net/attachment.cgi?id=130&action=view)
Push parent-list flush down into spf_add_parent

Make ospf_spf_add_parent() handle flush of parent-vertex list when shorter path
parent is added. As spf_add_parent() always occurs after nexthop-calculation,
this solves the problems of bug #330.

Patch is untested as of submission.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 15, 2007, 11:15 PM

Post #18 of 25 (4679 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

bugzilla-daemon at allevil

Jan 16, 2007, 1:36 AM

Post #19 of 25 (4682 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

bugzilla-daemon at allevil

Jan 17, 2007, 3:41 AM

Post #20 of 25 (4687 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

------- Additional Comments From windo [at] p6drad-teel 2007-01-17 11:41 -------
the patch does not seem to help. The logs look like without the patch:

2007/01/17 12:39:55 OSPF: SPF: Timer (SPF calculation expire)
2007/01/17 12:39:55 OSPF: ospf_spf_calculate: Start
2007/01/17 12:39:55 OSPF: ospf_spf_calculate: running Dijkstra for area 0.0.0.0
2007/01/17 12:39:55 OSPF: ospf_vertex_new: Created Router vertex 192.168.36.149
2007/01/17 12:39:55 OSPF: found Router LSA 192.168.25.149
2007/01/17 12:39:55 OSPF: The LSA is already in SPF
2007/01/17 12:39:55 OSPF: ospf_vertex_new: Created Router vertex 192.168.25.149
2007/01/17 12:39:55 OSPF: ospf_nexthop_calculation(): Start
2007/01/17 12:39:55 OSPF: V (parent): Router vertex 192.168.36.149 distance 0
flags 0
2007/01/17 12:39:55 OSPF: W (dest) : Router vertex 192.168.25.149 distance 40
flags 0
2007/01/17 12:39:55 OSPF: ospf_nexthop_calculation(): considering link type 1
link_id 192.168.25.149 link_data 10.1.0.2
2007/01/17 12:39:55 OSPF: ospf_nexthop_calculation(): could not determine
nexthop for link
2007/01/17 12:39:55 OSPF: found Router LSA 192.168.25.149
2007/01/17 12:39:55 OSPF: The LSA is already in SPF
2007/01/17 12:39:55 OSPF: ospf_intra_add_router: Start
2007/01/17 12:39:55 OSPF: ospf_intra_add_router: LS ID: 192.168.25.149
2007/01/17 12:39:55 OSPF: ospf_intra_add_router: this router is neither ASBR nor
ABR, skipping it
2007/01/17 12:39:55 OSPF: found Router LSA 192.168.36.149
2007/01/17 12:39:55 OSPF: The LSA is already in SPF
2007/01/17 12:39:55 OSPF: SPF Result: 0 [R] 192.168.36.149

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 17, 2007, 4:04 AM

Post #21 of 25 (4666 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

windo [at] p6drad-teel changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #130 is|0 |1
obsolete| |

------- Additional Comments From windo [at] p6drad-teel 2007-01-17 12:04 -------
Created an attachment (id=131)
--> (http://bugzilla.quagga.net/attachment.cgi?id=131&action=view)
Push parent-list flush down into spf_add_parent + fix

looks like you missed a return in ospf_nexthop_calculation.

i tested it and it fixes the bug AND works for the interesting situation where
the connectivity is assymmetrical.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 19, 2007, 6:49 AM

Post #22 of 25 (4640 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

paul [at] dishone changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #131 is|0 |1
obsolete| |

------- Additional Comments From paul [at] dishone 2007-01-19 14:28 -------
Created an attachment (id=132)
--> (http://bugzilla.quagga.net/attachment.cgi?id=132&action=view)
Proposed final form of patch for testing

redo return argument handling in nexthop_calculation

------- Additional Comments From paul [at] dishone 2007-01-19 14:49 -------
Thanks for spotting that Siim. I think there were two other places which
/potentially/ could incorrectly return positive when no nexthop had actually
been added. I've rejiggled the patch slightly, hopefully this is now ready for
integration.

Could you retest this form of the patch and, if you can, eyeball the returns in
nexthop_calculation?

Thanks!

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 23, 2007, 6:51 AM

Post #23 of 25 (4611 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

bugzilla-daemon at allevil

Jan 23, 2007, 11:00 AM

Post #24 of 25 (4629 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.

http://bugzilla.quagga.net/show_bug.cgi?id=330

paul [at] dishone changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED

------- Additional Comments From paul [at] dishone 2007-01-23 19:00 -------
Hi Siim,

That's great, i'll integrate the patch soon. Thanks for your hard work in
diagnosis and testing on this bug!

The assymetrical case, sorry - that can't work. OSPF requires bi-directional
communication on a link, so ultimately that must prevent asymmetric links from
working. I just speculated about how it would work within SPF (which should, in
abstract concept at least, work with unidirectional di-graph). As I said at the
end of the comment:

"routers with a pair of uni-directional links would never form adjacencies on
those links, and such a pair of links would be easily or better presented as a
single, normal, bi-directional links obviously)"

Sorry if that wasn't clear ;).

Thanks again for your help!

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-bugs

bugzilla-daemon at allevil

Jan 24, 2007, 8:47 AM

Post #25 of 25 (4605 views)
Permalink

[Bug 330] routes disappear with 'could not determine nexthop' log entry [In reply to]

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads