On Tue, Jun 23, 2015 at 02:12:39PM +0300, Andrew wrote: > Hm, you're right. I have a multicast flood rate limiter on switch > between core and testpoint PC. It seems that fresh BIRD just sends > packets faster than 1.4.5, so rate limiter drops some of answers...
Interesting. But your explanation is not exactly correct, as BIRD in this exchange was sending mostly unicasts (DBDES and LSREQ packets). So they were Quagga multicast LSUPD packets that got rate limited. 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 on non-filtered links. (Perhaps that was the reason why the rate limiter was set-up in the first time?) 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? > After disabling rate limits, negotiation is done much faster (10-20 > secs). So, it's false alert. Sorry for your spent time. BTW, could you also send me the BIRD log for the current situation when the convergence is OK? -- 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
