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?
We don't trigger LS-Reqs on LS-Updates coming in though. Retransmits of any requested LSAs not received are left to an LS-Req timer (configurable, default 5s).
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?
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?
regards, -- Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A Fortune: I tell ya, I was an ugly kid. I was so ugly that my dad kept the kid's picture that came with the wallet he bought. -- Rodney Dangerfield _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
