On Wed, Jul 26, 2017 at 04:39:10PM -0500, Aaron Gould wrote: > Please let me know what y'all mean by this comment regarding *policing on > LAG's*.
As I understand it, on MX, if you configure a say a 2 Gbps policer on a LAG (ae) interface, each member interface will receive pro-rata share of CIR to meet aggregate rate of 2 Gbps across the whole LAG. On XR platform, by default, application of 2 Gbps policer on Bundle-Ether will replicate the same 2 Gbps on every member 10G interface -- this may or may not give you the desired effect you'd expect. Neverthless, this is a moot point now. As of IOXR 6.0.1, Aggregate Bundled QoS is now supported: "Aggregated Bundle QoS feature allows the shape, bandwidth, police rates and burst values to be distributed between the active members of a bundle, where a QoS policy-map is applied." P/0/RSP0/CPU0:ASR9000(config)# hw-module all qos-mode bundle-qos-aggregate-mode > > "We have refused to use the ASR9000 as an edge router because of how Cisco > implement policing on LAG's, in general. However, we use them quite > extensively as border and peering routers." > My biggest problem of ASR9K on revenue boxes is that it takes a rocket science to SW upgrade the platform if you care about downtime duration. Single homed customers are very sensitive to multi-hour maintenance window, and then there is also that FPD upgrade that you have to run on every line card and reload each. When a TAC confirmed bug behavior is noted and software upgrade is advised, it's a hassle to get change window approved due to the complexities of SW jump. On the flip side, on MX platforms, I'm not a big fan of Juniper BGP implementation myself IMO. Performance seems to be improving noticeably as of recent SW versions, and BGP is all around snappy on the new 64-bit MX RE, but update-group behavior handling seems awful. Why is it that when you de-configure the last remaining peer on a customer facing peer-group, it resets all 175 BGP sessions on the entire chassis when you commit? May be I'm doing something wrong, but best practice seems to be to configure a fake BGP peer to force rpd to operate differently. https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-sessions.html "When, because of a configuration change, BGP transitions from needing two copies of a route to not needing two copies of a route (or the reverse), all sessions over which VPN routes are exchanged go down and then come back up." "The way to prevent these unnecessary session flaps is to configure an extra RR client or EBGP session as a passive session with a neighbor address that does not exist. This example focuses on the EBGP case, but the same workaround works for the RR case." I prefer ASR9K for multi-homed customers that can withstand long outages, but for single-tailed circuits or when I need a "do everything router" in a new market in as compact as possible form, MX480 is a nice fit for us. ASR9K has overall more power hungry requirements IMO, and MX has much better line card product offerings on both low and high ends (MPC3E and MPC7 are great). James _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
