On Fri, Jun 26, 2015 at 01:57:39PM +0100, Paul Jakma wrote: > On Thu, 25 Jun 2015, Ondrej Zajicek wrote: > >> BIRD 1.4.5 initialized faster, because it used 'shotgun' approach to >> LSREQ packets - send a new one when any LSUPD bringing at least one new >> LSA was received, so it did not matter when 2/3 of LSUPDs were >> eliminated, but it may create several times more traffic > > Presumably you're still removing the LSAs given in the LSA Update > received from your ls-req list first?
Yes > If pumping LS-Req on receipt of an LSA Update: The other side could be > preparing to send the remaining LSAs anyway in another LSA Update, or > those packets might already be in flight, or even already in the local > receive buffers still to be processed. In which case, sending new LS-Reqs > on any new LS-Update would lead the remote side to have to resend LSAs > already sent and received? Yes, it was stupid strategy. > So that could well lead to a good bit more traffic, especially if there > were a lot of LSAs, I'd agree. > >> But i wonder why Quagga-Quagga links were not affected by this rate >> limited. Is the rate limiter specific to just the one port where only >> BIRD was tested? Or Quagga is using some other strategy when >> constructing or sending LSREQs than the current BIRD? > > Yeah, I'm curious on this too. Could be the above, if I understood your > LS-Req strategy correctly? The described strategy was used in BIRD 1.4.5 (and older versions), which did not have problems in this case (probably because there were still enough LSUPD packets passing through). The new BIRD 1.5.0 (affected by the problem) uses more sane approach - send the new LSREQ packet when all LSAs requests in the last LSREQ packets were received by LSUPDs (and therefore removed from the LS request list). And also retransmit LSREQ after RxmtInterval (default 5 s). I presume that is more-or-less the same approach as Quagga? If i understand Andrew correctly, the Quaggas were not affected as they run on different machines connected to different switch ports without configured rate limitation. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
