[j-nsp] QFX3500-48S4Q-ACR

[Jeff Wheeler]

On Thu, Sep 27, 2012 at 9:15 PM, Julien Goodwin
<jgoodwin at studio442.com.au> wrote:
>> some hard-coded CoPP "accept" rules that you cannot override by
> I know Trident+ (which this uses) has some weird limitations around this
> area, any idea if this actually is one?

No, I believe it is a choice by Juniper not to change it, because they
think it will give customers "too much rope."  I really doubt the chip
is hard-wired to punt all BGP packets but that's basically what
happens.

Also the ACL TCAM is relatively small and CoPP rules use up a lot of
TCAM rows.  There are some Juniper KB entries on this.  So if you
configure say, like this:
interface lo0.0 family inet filter input [ MYCOPP ]
interface xe24.0 family inet filter input [ CUSTOMER1FILTER ]
interface xe25.0 family inet filter input [ CUSTOMER2FILTER ]

and MYCOPP uses up 30 TCAM rows (easily possible) then it will
actually use 30, then 30 more (on top of whatever CUSTOMER1FILTER
needs) for xe24, and yet 30 more for xe25 (plus that customer's filter
rows.)  So you can exhaust your available ACL TCAM rather quickly if
you are doing much on it.

>> I think QFabric is brain-damaged and doubt we will ever try it.
>
> Really? Any reasons why? (other than the whole locked optics thing)

I think their whole concept for the control-plane is bad and
unreliable.  If you are considering QFabric I think you should buy
enough hardware for testing and reboot the control-plane switches a
few times and watch how long it takes to start working right again.

They say they will/have fix the optics lock-in but I have not tested
this recently.

Just my $0.02 but I think QFX is good for L2, not so good for other
things at this time.
-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts