QFX5k question

Hey there,

I am trying to get my hands on some QFX5000s and I have a rather quick question.

In the past, I often used MX + EX where MX did routing and I connected all uplinks/peering and EX, and EX did switching, i connected my servers to ex.

in QFX, I am trying to see if I need EX or not? more importantly (besides from what juniper papers say) are there any known issues people run into for a small scale deployment. (100mbps-1gbps range 1 rack, 20 servers)

my plan is to have QFX to it all, but i am worried, if this is too much for QFX, if you have relative experience on this , feel free to let me know

thanks in advance

mehmet

QFX5100 as a L3 router + L2 switch performed well for us in the past, I don't see why it'd fall over in <1g traffic now.

You should be good to go.

thanks for quick reply. I forgot to mention, 2 x 10G providers with full routing table on each.

thank you…

* mehmet@akcin.net (Mehmet Akcin) [Sat 23 Mar 2019, 20:53 CET]:

thanks for quick reply. I forgot to mention, 2 x 10G providers with full routing table on each.

  -- Niels.

I have 4 QFX51xx switches in a virtual chassis and have no problems pushing that much traffic through them for several hundred servers with 10GB uplinks.

I have Virtual chassis QFX5100’s running as a switching/routing core with about 80k routes (bgp in routing-instances) and no issues. MX’s are on the upstream borders and downstream BNG’s. The only issue I has was I had some MPLS psuedowire switching on them and found a few glitches.

Hey there,

Hi,

in QFX, I am trying to see if I need EX or not? more importantly (besides from what juniper papers say) are there any known issues people run into for a small scale deployment. (100mbps-1gbps range 1 rack, 20 servers)

my plan is to have QFX to it all, but i am worried, if this is too much for QFX, if you have relative experience on this , feel free to let me know

We have a large number of QFX5100s deployed as L3 ToRs. They are running anywhere between 50 G and 150 G through them, depending on the deployment. They work fairly well for us.

I don't know if they can hold a full internet DFZ BGP feed or not. I don't know if that's an issue for you or not.

thanks in advance

You're welcome, and good luck.

Hi,

thanks for quick reply. I forgot to mention, 2 x 10G providers with full routing table on each.

Those QFXs won't be able to hold full routing tables:

Cheers,
Sander

I am trying to get my hands on some QFX5000s and I have a rather quick
question.

First, there is no model named QFX5000. There is QFX5100, QFX5110,
QFX5120, QFX5200 and QFX5210 (and some of them have several submodels,
e.g. QFX5100-48T, QFX5100-48S and QFX5100-24Q).

in QFX, I am trying to see if I need EX or not? more importantly (besides
from what juniper papers say) are there any known issues people run into
for a small scale deployment. (100mbps-1gbps range 1 rack, 20 servers)

my plan is to have QFX to it all, but i am worried, if this is too much for
QFX, if you have relative experience on this , feel free to let me know

Presumably you are then interrested in the QFX5100-48S or QFX5100-48T,
as the other QFX5k models have even more performance available, and
thus cost a bit more. (Cheaper than most MX:es, though.) You might
also consider the EX4600: only 24 SFP+ (10G) ports and 4 QSFP (40G)
ports, but otherwise identical hardware to the QFX5100-48S. I think
there are some features that Juniper has disabled in Junos for the
EX4600, though (VXLAN isn't mentioned in the EX4600 datasheet, for
example).

We have both QFX5100-48S and EX4600, and are quite happy with them.
They can easily handle the traffic volumes you are speaking about,
for both L2 and L3. The Broadcom Trident II chip inside of them is
what has been powering L3 switches at the big cloud providers for
years, and they push much more traffic through them than that.

They do have limited feature set, though. E.g, they only look at
the first 64 octets of each packet (and that includes L2 and L2.5
headers) when deciding what to do with a packet, and can't chase
the IPv6 header chain; thus, if there is an extension header before
the TCP/UDP header, they won't know what TCP/UDP ports are used,
or even if it is TCP, UDP or something else. Dealing with packets
exiting tunnels (MPLS, VXLAN, et.c) is also limited.

However:

thanks for quick reply. I forgot to mention, 2 x 10G providers with full
routing table on each.

As others have told you, and a quick glance at the datasheets from
Juniper will show, no way. 128k routes for IPv4, 64k routes for
IPv6. And several caveats hiding, e.g. you can't reach both limits
at the same time. And even reaching those will require careful
configuration.

First question: do you *need* full Internet DFZ tables? Or can you
get away with just getting, e.g, 10k important prefixes from each
uplink, and punt everything else through a default route? If those
prefixes are chosen well, they might catch 95-99% of all the traffic,
and the remaining 1-5% will just have to suffer sub-optimal routing.

I have heard of people who get a full BGP feed from their providers,
but only program a small portion of the prefixes into FIB, using some
filter list. Then they monitor their outgoing traffic to notice when
significant amounts of traffic go out the wrong way, and then change
their filter lists. I don't know any details about how they do it,
though.

If you *do* need full Internet tables, have you considered using a
Linux or BSD server with a couple of 10G interfaces and running Bird,
Quagga, or any of the other BGP implementations for Unix/Linux? Or
perhaps Junipers virtual MX, which you run on a Linux server? That
is probably quite a bit cheaper than an MX router, and should easily
be able to handle two 10G uplinks.

And by the way, remember that you need to buy an extra license to
use BGP on the QFX5k and EX4600 switches.

Some declared features - do not work.
For example, IPIP termination through filters is claimed, but does not work.
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/ipip-tunnel-services-filter-qfx-series.html
Perhaps "not implemented yet", possibly errata, nevertheless it is very unpleasant when you buy equipment and this is a key necessary function.
Therefore, if any more or less complex (uncommon) features are used, it is better to test them first.