[j-nsp] Helo Juniper, your docs need work..
morrowc at ops-netman.net
Thu Feb 12 20:01:02 EST 2015
On 02/12/2015 04:08 PM, Olivier Benghozi wrote:
> By the way in current JunOS 12.3 it looks there's at least one fix; in:
> http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html <http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html>
> they write that "You can apply port, VLAN, or router firewall filters to both IPv4 and IPv6 traffic on these switches:"
> • EX3300 switch
> • EX6200 switch
that's nice... still unhappy (though it's not purely a docs problem,
clearly) with the fact that the commit is silently death, AND fixing
that requires on/off the interface gymnastics.
>> Le 12 févr. 2015 à 22:55, Chris Morrow <morrowc at ops-netman.net> a écrit :
>> read this:
>> The maximum number of terms allowed per firewall filter for EX Series
>> switches is:
>> 512 for EX2200 switches
>> 1,436 for EX3300 switches
>> Uhm.. 1436 looks like the number of TCAM entries, NOT the number of
>> terms. great. thanks.
>> "Note: On EX3300 switches, if you add and delete filters with a large
>> number of terms (on the order of 1000 or more) in the same commit
>> operation, not all the filters are installed. You must add filters in
>> one commit operation, and delete filters in a separate commit operation."
>> Really?? it silently doesn't work?? what?? and this is probably not
>> 'terms' but 'tcam entries' I bet, which the average user probably
>> doesn't know either. Great.
>> This also is stellar:
>> "You can apply port, VLAN, or router firewall filters to both IPv4 and
>> IPv6 traffic on these switches:
>> EX2200 switch
>> EX3200 switch
>> EX4200 switch
>> EX4500 switch
>> EX8200 switch
>> You can apply port, VLAN, or router firewall filters to only IPv4
>> traffic on these switches:
>> EX3300 switch
>> EX6200 switch"
>> Uhm, this is the year 2015, the device was built and designed in ~2013 ?
>> and no ipv6 ? WHAT?
>> Also, in case that your firewall filter is over-spec and can't be
>> committed to TCAM the user has zero idea of this... Then once you fix it
>> (if you figured it out) you have to remove the filter from the interface
>> THEN reapply it?
>> This is ... very, very poor. The docs need work, the operational model
>> is broken ... Do you operate your own gear in actual networks and NOT
>> see these as problems? Could you ask your IT folks about this sort of
>> operational model and see how they react?
> juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp