[j-nsp] EX4200 filter buggy?

[Phill Jolliffe]

As Chris mentions it is not the number of terms alone but the ordering
and specify logic sequences are tricker implement.

SW upgrade is almost certainly the ultimate fix here. But as a work
around consider trying to optimize your filter term ordering and if
possible address aggregation in terms from clauses. Failing this strip
it down to the bear essentials, example remove any terms that are
purely informational matches to increment counters.

Might get you a working solution the current code.

On Fri, Dec 3, 2010 at 3:34 PM, Chris Morrow <morrowc at ops-netman.net> wrote:
>
>
> On 12/03/10 05:46, Charlie Allom wrote:
>> I have tried 10.0R2.10, 10.0S10.1 and 10.0R4.7 - they are all the
>
> it seems that with the EX you have to play the 'upgrade to the next
> daily image' game, a lot.
>
>> same. We only have 165 terms.
>
> since this is a tcam based platform it's not just 'terms' that matter,
> but the combinatorial effect of the contents of the terms... A that
> references 2 sources & 2 destinations is 4 entries in the TCAM. Add
> ports/protocols and that number can increase, dramatically.
>
>> sw0.cll fpc2 dfw_change_term_filter:1522 H/W cutover failed (no space
>> left on device) for filter (7) change end!
>>
>> that was amongst lots of others.. one "no space left" for each FPC.
>
> there's a rather short set of entries permitted ... and you can't
> allocated specifically to the 'pfe' (the equivalent part on the EX), of
> which there are (I believe) 3 on the 4200.
>
>> I've asked Juniper for an RMA and we will see if that fixes it.
>
> I doubt that'll fix your issue...but who knows :)
>
> -chris
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Phill Jolliffe