On Mon, 22 Jun 2015, Ondrej Zajicek wrote:

Well, IMHO the bogus behavior is right at the begginging of the LSA req/update history - e. g. 2nd, 3rd and 5th LSAs (requests are ignored and retransmitted after RxmtInterval - 5s):

Ah, yeah.

There's some weird ones here. E.g. 93 gets the LS-Req at 59.447131, but doesn't reply. 66 responds first, having been sent an LS-Req at 59.447165 and 64.448653 and replying at 64.450376:

   10.255.192.4 #   91.202.135.60 :
req: 192.168.255.72  -->  192.168.255.93         59.447131
req: 192.168.255.72  -->  192.168.255.66         59.447165
req: 192.168.255.72  -->  192.168.255.66         64.448653
req: 192.168.255.72  -->  192.168.255.93         64.448685
upd: 192.168.255.66  -->       224.0.0.5         64.450376 seq 0x80000064
ack: 192.168.255.72  -->       224.0.0.6         67.113794 seq 0x80000064

Was 93 too busy? But, another LSA:

   10.255.192.4 #  91.202.134.233 :
req: 192.168.255.72  -->  192.168.255.93         59.447131
req: 192.168.255.72  -->  192.168.255.66         59.447165
upd: 192.168.255.93  -->       224.0.0.5         59.448580 seq 0x80000007
ack: 192.168.255.72  -->       224.0.0.6         60.364653 seq 0x80000007

So 72 asked for that LSA in the same LS-Req, and so that LS-Req at 59.447131 contained requests for both those LSAs. 93 responded near instantly with an LS-Update containing at least one of them. The LS-Update packet was full, so presumably 93 sent another packet with the other.

However, no trace of that is seen.

So the question is, did Quagga send that packet?

Is this a weird bug in Quagga that its dropping some LSAs (the pcap contains fragmented IPs though - so the user-space fragmentation in Quagga ospfd is working [why, oh why, is there no way to enable the kernel IP fragmentation code on raw sockets?]). The only other way is that ospfd has an LSA that doesn't fit in an IP packet - which is not possible for AS-External LSAs.

So, either something weird is going on in Quagga, or 93 and 66, or the else the problem is that the link between 66, 93 and 72 is lossy and regularly dropping packets.

Andrew, can you run a trace from both sides at the same time?

regards,
--
Paul Jakma      [email protected]  @pjakma Key ID: 64A2FF6A
Fortune:
The sooner you fall behind, the more time you have to catch up.

_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to