Hi,
We have a stub vrf with Transit on them, the solution is a very
good set of filters on lo0 input.
-----
Alain Hebert [email protected]
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On 10/24/17 14:29, Andrey Kostin wrote:
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. 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.
Kind regards,
Andrey Kostin
Matt Freitag писал 24.10.2017 09:26:
Karl, we're also looking at QFX5100-48S switches for our aggregation. I
actually have one in place doing aggregation and routing and the only
"big"
change I found is the DHCP forwarder config is not remotely similar
to the
forwarding-options helpers bootp config we've been using to forward
DHCP on
our MX480 core. But that only counts if you do routing and DHCP
forwarding
at the QFX.
But, if you want to do routing and DHCP forwarding on this, any
forwarding
in the default routing instance goes under forwarding-options dhcp-relay
and any DHCP forwarding in a non-default routing instance goes under
routing-instances INSTANCE-NAME forwarding-options dhcp-relay.
There are a ton of DHCP relay options but we found we just need a server
group that contains all our DHCP servers and an interface group that
ties
an interface to a server group.
Again I only bring the DHCP relay stuff up because we've been using
forwarding-options helpers bootp on our MX's to do DHCP forwarding
and the
QFX explicitly disallows that in favor of the dhcp-relay.
Other than that initial confusion we've not had a problem and I'm very
interested in any issues you hear of. This QFX I'm talking about runs
Junos 14.1X53-D40.8.
I'm also very interested in any other issues people have had doing this.
Matt Freitag
Network Engineer
Information Technology
Michigan Technological University
(906) 487-3696 <%28906%29%20487-3696>
https://www.mtu.edu/
https://www.mtu.edu/it
On Tue, Oct 24, 2017 at 8:41 AM, Karl Gerhard <[email protected]> wrote:
Hello
we're thinking about buying a few QFX5100 as they are incredibly
cheap on
the refurbished market - sometimes even cheaper than a much older
EX4550.
Are there any caveats when using the QFX5100-48S as a normal
aggregation
switch without QFabric? We have a pretty basic setup of Access (EX),
Aggregation (EX or QFX) and Core (MX). We're only switching at our
aggregation layer but we would like to have options for the future.
Regards
Karl
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
