[j-nsp] Helo Juniper, your docs need work..

[Chris Morrow]

http://www.juniper.net/documentation/en_US/junos12.1/topics/concept/firewall-filter-ex-series-overview.html

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.

Also:
"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?

-chris
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Olivier Benghozi]

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
[...]

Post by Chris Morrow
http://www.juniper.net/documentation/en_US/junos12.1/topics/concept/firewall-filter-ex-series-overview.html
The maximum number of terms allowed per firewall filter for EX Series
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.
"You can apply port, VLAN, or router firewall filters to both IPv4 and
EX2200 switch
EX3200 switch
EX4200 switch
EX4500 switch
EX8200 switch
You can apply port, VLAN, or router firewall filters to only IPv4
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?
-chris

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.ne

[Chris Morrow]

Post by Olivier Benghozi
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.

Post by Olivier Benghozi

Post by Chris Morrow
http://www.juniper.net/documentation/en_US/junos12.1/topics/concept/firewall-filter-ex-series-overview.html
The maximum number of terms allowed per firewall filter for EX Series
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.
"You can apply port, VLAN, or router firewall filters to both IPv4 and
EX2200 switch
EX3200 switch
EX4200 switch
EX4500 switch
EX8200 switch
You can apply port, VLAN, or router firewall filters to only IPv4
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?
-chris

_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-

[Bjørn Mork]

Post by Olivier Benghozi
http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html

Yes, if there is one lesson I've learned the hard way about Juniper
docs: They never correct errors in old documentation. At least it looks
that way from the outside. Which means that you always should read the
docs for the latest release no matter what version you actually use.

You will of course have to keep your eyes open wrt actual feature
changes. But that's much easier and less frustrating than stumbling
through lots of already known and fixed doc bugs. There rarely are that
many new features ;-) And the important ones tend to be flagged in a way
that makes it obvious that they are new.

So forget about the 12.1 and 12.3 docs. Read the 14.1 or whatever is
the latest release for these things.


Bjørn

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether

[Phil Mayers]

Post by Olivier Benghozi
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 an extremely misleading bit of text that I had a very grumpy
conversation with Juniper about.

You can indeed apply the firewall filters to IPv6 traffic. But you can't
specify any IPv6 protocols fields as matches.

So w00t a default deny or ethertype deny will apply to IPv6 as opposed
to skipping it entirely.

EX3300 apparently has no IPv6 field matching capability in hardware.
Which is almost unbelievable for a current-gen switch, but that's what
Juniper told us, repeatedly.

Cheers,
Phil
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://pu

[Olivier Benghozi]

Well, they write in http://www.juniper.net/techpubs/en_US/junos12.3/topics/reference/general/firewall-filter-ex-series-match-conditions-support.html#jd0e2022 <http://www.juniper.net/techpubs/en_US/junos12.3/topics/reference/general/firewall-filter-ex-series-match-conditions-support.html#jd0e2022> that you could use next-header on EX including 3300, but only on layer3 interfaces, not port or vlan...

By the way next-header is crappy, payload-protocol on MX Trio platform is the only proper way to go, if only it wasn't so buggy (like logs "match on payload protocol is not supported on ae0").

That's an extremely misleading bit of text that I had a very grumpy conversation with Juniper about.
You can indeed apply the firewall filters to IPv6 traffic. But you can't specify any IPv6 protocols fields as matches.
So w00t a default deny or ethertype deny will apply to IPv6 as opposed to skipping it entirely.
EX3300 apparently has no IPv6 field matching capability in hardware. Which is almost unbelievable for a current-gen switch, but that's what Juniper told us, repeatedly.

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Phil Mayers]

Post by Olivier Benghozi
that you could use next-header on EX including 3300, but only on
layer3 interfaces, not port or vlan...

Sure - no "family ethernet-switching" support.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Phil Mayers]

Post by Chris Morrow
EX3300 switch
EX6200 switch"
Uhm, this is the year 2015, the device was built and designed in ~2013 ?
and no ipv6 ? WHAT?

Yes, we shouted at them about that. Hardware limitation. Can't be fixed,
we were told. Made the EX3300 unsuitable for our needs since you can't
do any form of RA guard, which is unfortunate as it's otherwise a nice box.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Harald]

Post by Phil Mayers
Yes, we shouted at them about that. Hardware limitation. Can't be
fixed, we were told. Made the EX3300 unsuitable for our needs since
you can't do any form of RA guard, which is unfortunate as it's
otherwise a nice box.

RA-guard was implemented in 14.1X53D10 on EX2200 and EX3300 along with
ND-inspection, IPv6 source-guard and DHCPv6 guard/snooping.

[Phil Mayers]

Post by Harald

Post by Phil Mayers
Yes, we shouted at them about that. Hardware limitation. Can't be
fixed, we were told. Made the EX3300 unsuitable for our needs since
you can't do any form of RA guard, which is unfortunate as it's
otherwise a nice box.

RA-guard was implemented in 14.1X53D10 on EX2200 and EX3300 along with
ND-inspection, IPv6 source-guard and DHCPv6 guard/snooping.

I vaguely recall them saying they were going to do this. Have you tried
it? Does it work ok?

If that was all we needed, that might be sufficient, but we were
reluctant to buy a device which would be in service for 3 years or more
without the ability to block on IPv6 address / UDPv6/TCPv6 ports.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Harald]

Post by Phil Mayers

Post by Harald
RA-guard was implemented in 14.1X53D10 on EX2200 and EX3300 along with
ND-inspection, IPv6 source-guard and DHCPv6 guard/snooping.

I vaguely recall them saying they were going to do this. Have you
tried it? Does it work ok?

I haven't tried it on EX3300 yet, but I have tested it on EX2200 and
judging from the tests I did it is working fine there.

[Chris Morrow]

Post by Harald

Post by Phil Mayers

Post by Harald
RA-guard was implemented in 14.1X53D10 on EX2200 and EX3300 along with
ND-inspection, IPv6 source-guard and DHCPv6 guard/snooping.

I vaguely recall them saying they were going to do this. Have you
tried it? Does it work ok?

I haven't tried it on EX3300 yet, but I have tested it on EX2200 and
judging from the tests I did it is working fine there.

my guess is that this works because it's implemented as a loopback
filter... so really it's a filter on the CPU on the ex3300 and NOT done
in the hardware at the forwarding parts.

also, is traceroute through an EX fixed for loopback filtering yet? no.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Phil Mayers]

Post by Chris Morrow
my guess is that this works because it's implemented as a loopback
filter... so really it's a filter on the CPU on the ex3300 and NOT done
in the hardware at the forwarding parts.

If it claims to be RA/ND guard, it can't be.

My guess is that they're punting based on layer2 MAC range, which has
interesting implications for CPU performance.

Cheers,
Phil
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp