[j-nsp] Using a QFX5100 without QFabric?

[Alain Hebert]

     Hi,

     We have a stub vrf with Transit on them, the solution is a very 
good set of filters on lo0 input.

-----
Alain Hebert                                ahebert at pubnix.net
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 <karl_gerh at gmx.at> 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 juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp