[j-nsp] EX unsupported filter policer and actions on loopback lo0

[Stefan Fouant]

> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Richard A Steenbergen
> Sent: Friday, December 17, 2010 3:09 PM
> To: Chris Morrow
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] EX unsupported filter policer and actions on
> loopback lo0
> 
> FWIW I've already done an epic amount of bitching about this issue, and
> they ARE aware and working on improving it. Its always nice to have
> more
> voices though, so they don't think it's just that ras guy whining about
> something nobody cares about. :)
> 
> > The EX, for some reason, is never required to meet the same
> > functionality testing and results as the other Juniper routing
> platforms
> > are... It's quite sad that Juniper put this product out ignoring ~10
> > years of industry best practices/standards/experience/knowledge.
> 
> Insert standard disclaimer about "it's an enterprise class box, where
> enterprise is codeword for doesn't actually have to work right because
> enterprise people are stupid and don't know any better, and you can
> always pay a lot more money and buy an MX if thats a problem" here. :)

The thing is it completely goes against their main marketing thrust right
now, which is the whole "One Junos" mantra.  They keep talking about how
Junos is Junos, across the board, no matter which platform and it's their
main selling point when compared to Cisco with its many flavors of IOS,
IOS-XR, NX-OS, CatOS, etc...

I wonder if that study by Lake Partners where customers running Junos
averaged a 25% reduction in OpEx took this into consideration.  Performing
control plane filtering by deploying an ingress filter on all your
interfaces on an EX platform, vs. doing it on loopbacks on all the other
platforms means that operators are spending twice as much time to accomplish
the same result...

Stefan Fouant, CISSP, JNCIEx2