[j-nsp] Using a QFX5100 without QFabric?

[Andrey Kostin]

Vincent Bernat писал 24.10.2017 18:30:
> ❦ 24 octobre 2017 14:29 -0400, Andrey Kostin <ankost at podolsk.ru> :
>
>> QFX5100 are good as L2 devices for aggregation, we use them in
>> virtual-chassis. But be careful with planning any L3 services on
>> them. First, don't put public IPs on them because TCAM for filters 
>> is
>> tiny and programmed in a tricky for understanding way. As a result
>> everything that doesn't fit in TCAM is silently allowed. We observed
>> that lo0 filters were "bypassed" this way and switch was exposed to
>> continuous brute-force attack.
>
> That's scary! I remember having a commit error when I set too many
> filters (in fact, too many source/destination combination, solved by
> removing either source or destination from the filter), so there are
> some checks in place. Which version were you using when you got the
> problem? Is there an easy way to check if we are hit by that?

At that moment (Feb 2016) it was 13.2X51-D35.3.
Is I can see from the link posted in the thread, MPLS on IRB is not 
supported yet, probably hardware limitation.

Here is the conclusion from JTAC case:
Problem Description :

We use common set of filters on all our juniper devices to protect
control plane and it turnes out there is a strange problem with filter
on QFX switches.

When that input filter list is applied then at least ports tcp/22 and
tcp/179 are world-wide open.

Issue: Filter was not getting programmed in TCAM:

Action taken:

As per our latest communication, we have identified two reasons behind
the filters not getting programmed  First, the filter entries exceeded
the maximum TCAM entries. Second, we observed the the QFX platforms do
not support input-list. Although the config gets committed without any
error, only the first filter gets programmed in TCAM. We also provided 
a
sample configuration to demonstrate the ssh filter.

JTAC engineer's examples provided:


I have tried the following configs in the lab under 13.2X51-D35 and 
14.1X53-D30 and have observed the following:

    Config independent of the group:

set interfaces lo0 unit 0 family inet filter input-list [ accept-ftp 
accept-ssh ]

   Config within group:

set groups common:lo-filter interfaces lo0 unit 0 family inet filter 
input-list accept-ftp
set groups common:lo-filter interfaces lo0 unit 0 family inet filter 
input-list accept-ssh
In both cases, the configuration goes through without any error but 
only the first filter (accept-ftp) actually gets programmed in
the PFE programs as can observed  below:



TFXPC0(vty)# show filter
Program Filters:
---------------
    Index     Dir     Cnt    Text     Bss  Name
--------  ------  ------  ------  ------  --------


Term Filters:
------------
    Index    Semantic   Name
--------  ---------- ------
        1  Classic    accept-ftp
        2  Classic    accept-ssh
        3  Classic    lo0.0-i
    17000  Classic    __default_arp_policer__
16777216  Classic    fnp-filter-level-all





TFXPC0(vty)# show filter hw 3 show_term_info
======================
Filter index   : 3
======================


- Filter name  : lo0.0-i
  + Programmed: YES
   + BD ID     : 184
   + Total TCAM entries available: 1528
   + Total TCAM entries needed   : 8
   + Term Expansion:
     - Term    1: will expand to     1 term : Name "accept-ftp-0"
     - Term    2: will expand to     1 term : Name "accept-ftp-1"
   + Term TCAM entry requirements:
     - Term    1: needs     4 TCAM entries: Name "accept-ftp-0"
     - Term    2: needs     4 TCAM entries: Name "accept-ftp-1"
   + Total TCAM entries available: 1528
   + Total TCAM entries needed   : 8


Even the counters only show the counters for the first filter 
(accept-filter)  and not those for the following filters (accept-ssh)
in the input-list. The following is missing count-accept-ssh-lo0.0-i    
.


>
>> Second thing I can recall is that MPLS works only on physical
>> interfaces, not irb. And finally I had very mixed results when tried
>> to PIM multicast routing between irb interfaces and have to give up
>> and pass L2 to a router, didn't try it on physical ports though.
>
> I had also some bad experience with IRB on QFX5100. For example,
> unnumbered interfaces don't work on IRB. Also, I have also already
> related here my troubles with IRB, routing daemons and MC-LAG. For 
> some
> reasons, it seems many features don't play well with IRB (at least on
> 14.1X53 train). I am now using them as L2 switches and as BGP RR (but 
> no
> routing) and so far, no problems.



-- 
Kind regards,

Andrey