[c-nsp] Nexus 7707 as Internet Edge Router?

[James Jun]

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