Hi Pshem, What did you use as the FRR mechanism, if any, along with the BFD testing please?
> it's threshold based, so once errors reach particular level switchover is > triggered - whilst BFD has to actually lose those packets first. Well, unless you have the expensive modules that can do the FEC you will lose some data either way. adam -----Original Message----- From: Pshem Kowalczyk [mailto:[email protected]] Sent: Wednesday, April 03, 2013 11:13 PM To: Adam Vitkovsky Cc: Scott Granados; [email protected] Subject: Re: [c-nsp] BFD interval on a CRS3 We were told that 20ms is probably the lowest safe value you should run. For those reasons we're moving away from BFD and onto WanPhy and OTU2e encoding on the fibre. I remember testing the actual re-convergence time with BFD (on ASR9k) - with 20ms the actual re-convergence time (measured by a tester/traffic generator sending 1Gb/s stream over L2VPN) was always ~120ms. With WanPhy and OTU2e we could get around ~50ms. I suspect it has to do with the way error detection work in those technologies - it's threshold based, so once errors reach particular level switchover is triggered - whilst BFD has to actually lose those packets first. kind regards Pshem On 3 April 2013 21:48, Adam Vitkovsky <[email protected]> wrote: >> on a cisco CRS what is the lowest / shortest BFD interval that can be >> set > It appears that on all XR platforms the lowest BFD interval is 15ms > unfortunately. > Combined with lowest multiplier of 2 it gives you 30ms detection time. > We use multiplier 3 which only leaves 5ms for the IPFRR to do its magic. > > > adam > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
