Hi, when I was testing BIRD in the lab, I encountered a question. First, this is the topology, which is a very simple one, two computers connect each other via a twisted pair: Laptop(eth0, 192.168.0.1)---------Point-to-Point---------(eth0, 192.168.0.2)Personal Computer(PC) | | | | | | | | | | ----- | ------------- ----- ----- | | | | | tap0 eth1 tap1 tap0 tap1 10.1.1.2/16 10.32.31.239/16 10.2.1.2/16 11.1.1.2/16 11.2.1.2/16 And following is part of the Wireshark capture file(plus my understandings behind "//"): NO. Time Source Destination Proto. Info. 7 14.064842000 192.168.0.2 192.168.0.1 OSPF DB Descr. 8 14.066061000 192.168.0.1 192.168.0.2 OSPF DB Descr. 9 14.067224000 192.168.0.2 192.168.0.1 OSPF DB Descr. 10 14.067619000 192.168.0.1 192.168.0.2 OSPF DB Descr. //Above is the Master/Slave negotiation and the DD packets transferring procedure. 12 17.071181000 192.168.0.2 224.0.0.5 OSPF Hello Packet 13 17.071241000 192.168.0.1 192.168.0.2 OSPF LS Request 14 17.071563000 192.168.0.2 192.168.0.1 OSPF LS Update //Age: 9secs, SeqNum: 0x80000001, Checksum: 0x2351 //After exchanging DD packets, Laptop requires LSA from the PC. And now in Laptop, the conversation between PC and Laptop has been in state FULL. 15 18.073167000 192.168.0.1 224.0.0.5 OSPF LS Update //Age: 1sec, SeqNum: 0x80000002, Checksum: 0x366b //Before PC is going to send LSR packet to Laptop, Laptop has flooded its newly originated LSA. When PC receives this LSU packet, it removes its LSR packet on the list. //And now in PC, the conversation between PC and Laptop has been in state FULL. 18 19.074720000 192.168.0.2 224.0.0.5 OSPF LS Update //Age: 1sec, SeqNum: 0x80000002, Checksum: 0xae33 //So the PC also originates its new LSA and floods it. 19 19.075041000 192.168.0.1 192.168.0.2 OSPF LS Acknowledge //This is for the No.14 LSU packet, delayed. 20 19.077611000 192.168.0.2 192.168.0.1 OSPF LS Acknowledge //This is for the No.15 LSU packet, delayed. 21 20.079119000 192.168.0.1 224.0.0.5 OSPF Hello Packet 24 24.083617000 192.168.0.2 192.168.0.1 OSPF LS Update //Here is the question, why this LSU is sent? 25 25.090754000 192.168.0.1 192.168.0.2 OSPF LS Acknowledge //This is for the No.24 LSU packet. 26 27.093352000 192.168.0.2 224.0.0.5 OSPF Hello Packet 27 30.096506000 192.168.0.1 224.0.0.5 OSPF Hello Packet After checking debugging information in the syslog, I thought the reason might be this: In the PC's syslog, after the PC receiving the No.19 LSAck, here are some lines: (time information, etc.) test-ubuntu bird: testing_ospf: I have: Age: 0, Seqno: 0x80000002, Sum: 44595 (time information, etc.) test-ubuntu bird: testing_ospf: He has: Age: 9, Seqno: 0x80000001, Sum: 9041 It seems that it's comparing the received LSAck with the LSA in the LSDB. PC finds that the LSU that the LSAck acknowledges cannot be found in the LSDB - however there's a newer one. So the PC simply sends another newer LSU(which is the No.24 packet) to Laptop. Is this right? However, where is the corresponding operation described in RFC 2328? I searched the Section 13.7 Receiving link state acknowledgments without any results. Thanks!