Some RE-S-1800X4, yeah. ASR9k has RSP440, so quad core x86 as well. Comparable I think.
Not sure about 7600 but definitely something old. 02.12.2015 19:18, Colton Conor пишет:
Stephen, Which RE is that on the MX480? The RE2000 or the quad core one? On Wed, Dec 2, 2015 at 4:42 AM, Stepan Kucherenko <t...@megagroup.ru <mailto:t...@megagroup.ru>> wrote: Should've put it here in the first post, got already asked about it offlist couple of times. I was testing it on MX80 with slow RE, so obviously numbers will change on faster REs but difference will still be there. ~1.5min taking full table from MX480 (nice RE, 85k updates) ~3min from 7600 (old and slow RE, 89k updates) almost 5min from ASR9k (nice RE, 450k updates) It'll be even more noticeable when Junos will be able to run rpd on a dedicated core. Keep in mind that it's still not actual convergence time, Junos is still lagging with FIB updates long after that. Sadly I was unable to find my old convergence test numbers but krt queue was dissipating for at least couple of minutes after BGP converged. I case you're wondering if it was the known rpd bug with low krt priority - no, I tested it after it was fixed. Not that I'd call it "fixed". And that's what I don't like about MX-es :-) Not sure if it's faster or slower on ASR9k though. On 02.12.2015 12:30, James Bensley wrote: On 1 December 2015 at 17:29, Stepan Kucherenko <t...@megagroup.ru <mailto:t...@megagroup.ru>> wrote: My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco stopped grouping BGP prefixes in one update if they have same attributes so it's one prefix per update now (or sometimes two). Transit ISP we tested it with pinged TAC and got a response that it's "software/hardware limitation" and nothing can be done. I don't know when this regression happened but now taking full feed from ASR9k is almost twice as slow as taking it from 7600 with weak RE and 3-4 times slower than taking it from MX. I'm not joking, test it yourself. Just look at the traffic dump. As I understand it, it's not an edge case so you must see it as well. In my case it was 450k updates per 514k prefixes for full feed from ASR9k, 89k updates per 510k prefixes from 7600 and 85k updates per 516k prefixes from MX480. Huge difference. It's not a show stopper but I'm sure it must be a significant impact on convergence time. How long timewise is it taking you to converge? Last time I bounced a BGP session to a full table provider it took sub 1 minute to take in all the routes. I wasn't actually timing so I don't know how long exactly. Cheers, James. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
