Re: [j-nsp] Using a QFX5100 without QFabric?
❦ 24 octobre 2017 14:29 -0400, Andrey Kostin : > 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. That's scary! I remember having a commit error when I set too many filters (in fact, too many source/destination combination, solved by removing either source or destination from the filter), so there are some checks in place. Which version were you using when you got the problem? Is there an easy way to check if we are hit by that? > 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. I had also some bad experience with IRB on QFX5100. For example, unnumbered interfaces don't work on IRB. Also, I have also already related here my troubles with IRB, routing daemons and MC-LAG. For some reasons, it seems many features don't play well with IRB (at least on 14.1X53 train). I am now using them as L2 switches and as BGP RR (but no routing) and so far, no problems. -- Don't go around saying the world owes you a living. The world owes you nothing. It was here first. -- Mark Twain ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EVPN + QinQ, individual bridge-domains for CVID's
This is on MX boxes running 15.1R6 I suspect I am going to end up implementing a hack to get this working ! On Wed, Oct 25, 2017 at 4:16 AM, Alain Hebert wrote: > Hi, > > Depending of your relation with your local JNP resellers. > > You could get vMX, vQFX and vSRX and build yourself a lab using (ESXi in > our case). > > In the past vMX wasn't working correctly for EVPN but 17.x is working > with our MX240+vMX+QFX lab. > > But we're staying away from LS since we had a series of crashes in 16.x. > > TLDR: Good luck =D > > - > Alain Hebertaheb...@pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 > > On 10/24/17 10:47, Aaron Gould wrote: >> >> Since you mentioned it Evpn in lsys ? I don't think that works. If >> so please tell me it does so I can try it. I really would like to know if I >> can run EVPN in LSYS on MX104... let me know if I need to simply change to a >> different version of JUNOS and I'll do it. >> >> [edit] >> r2@lab-mx104:r2# set routing-instances test instance-type ? >> Possible completions: >>forwarding Forwarding instance >>l2backhaul-vpn L2Backhaul/L2Wholesale routing instance >>l2vpnLayer 2 VPN routing instance >>layer2-control Layer 2 control protocols >>mpls-internet-multicast Internet Multicast over MPLS routing instance >>no-forwardingNonforwarding instance >>virtual-router Virtual routing instance >>virtual-switch Virtual switch routing instance >>vpls VPLS routing instance >>vrf Virtual routing forwarding instance >> [edit] >> >> [edit] >> r2@lab-mx104:r2# run show version >> Hostname: lab-mx104 >> Model: mx104 >> Junos: 14.2R7.5 >> >> -Aaron >> >> >> > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using a QFX5100 without QFabric?
Without ASCII art: We have P(MX), a P(vMX), a PE1 (QFX5100), and PE2 (QFX5100), all with ISIS, MPLS, RSVP/LDP, BGP underlay, cluster and multipath. The (EVPN) broadcast is handled by the P's but once that discovery is done, the traffic passes between the PE's without bouncing thru the P's. Good enough for what it is. Must be the same deal with VPLS. Caveats: Can't mix EVPN and/or L2 and/or CCC on the same port. Right now EVPN+CCC works for our lab, but it must be a fluke. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 10/24/17 14:20, Joe Freeman wrote: How do you handle 10G port licensing on the 5048? That gets expensive quickly. I've got about 75 qfx's deployed as PE devices right now because of the 5048 port licenses. The major limitation of the qfx as a PE device is that it doesn't support VPLS. It does however do EVPN over vxlan, which can be stitched to a vpls instance if needed on an MX, at least according to Juniper. I've not yet tried it. On the very few instances where I've absolutely had to deliver a VPLS type service, I've been able to bring L2circuits back to a 480 and stitch them all to a bridge-domain there. Not optimal, but it works. Joe The qfx's do L3vpn and l2circuits nicely, with RSVP/LDP, BGP, and ISIS. On Tue, Oct 24, 2017 at 9:44 AM, Aaron Gould wrote: Not to change subject too much, but, In case you are wanting to extend your mpls cloud (I'm assuming your MX core is mpls-enabled) further out into the aggregation/access edge, you could go with the qfx-5100 cousin... acx5048. I've been pretty pleased with them. I've deployed 30 or 40 of these now in my network with as cisco asr9k core. -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using a QFX5100 without QFabric?
Hi, We have a stub vrf with Transit on them, the solution is a very good set of filters on lo0 input. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 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 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using a QFX5100 without QFabric?
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 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using a QFX5100 without QFabric?
How do you handle 10G port licensing on the 5048? That gets expensive quickly. I've got about 75 qfx's deployed as PE devices right now because of the 5048 port licenses. The major limitation of the qfx as a PE device is that it doesn't support VPLS. It does however do EVPN over vxlan, which can be stitched to a vpls instance if needed on an MX, at least according to Juniper. I've not yet tried it. On the very few instances where I've absolutely had to deliver a VPLS type service, I've been able to bring L2circuits back to a 480 and stitch them all to a bridge-domain there. Not optimal, but it works. Joe The qfx's do L3vpn and l2circuits nicely, with RSVP/LDP, BGP, and ISIS. On Tue, Oct 24, 2017 at 9:44 AM, Aaron Gould wrote: > Not to change subject too much, but, In case you are wanting to extend your > mpls cloud (I'm assuming your MX core is mpls-enabled) further out into the > aggregation/access edge, you could go with the qfx-5100 cousin... acx5048. > I've been pretty pleased with them. > > I've deployed 30 or 40 of these now in my network with as cisco asr9k core. > > -Aaron > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EVPN + QinQ, individual bridge-domains for CVID's
Hi, Depending of your relation with your local JNP resellers. You could get vMX, vQFX and vSRX and build yourself a lab using (ESXi in our case). In the past vMX wasn't working correctly for EVPN but 17.x is working with our MX240+vMX+QFX lab. But we're staying away from LS since we had a series of crashes in 16.x. TLDR: Good luck =D - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 10/24/17 10:47, Aaron Gould wrote: Since you mentioned it Evpn in lsys ? I don't think that works. If so please tell me it does so I can try it. I really would like to know if I can run EVPN in LSYS on MX104... let me know if I need to simply change to a different version of JUNOS and I'll do it. [edit] r2@lab-mx104:r2# set routing-instances test instance-type ? Possible completions: forwarding Forwarding instance l2backhaul-vpn L2Backhaul/L2Wholesale routing instance l2vpnLayer 2 VPN routing instance layer2-control Layer 2 control protocols mpls-internet-multicast Internet Multicast over MPLS routing instance no-forwardingNonforwarding instance virtual-router Virtual routing instance virtual-switch Virtual switch routing instance vpls VPLS routing instance vrf Virtual routing forwarding instance [edit] [edit] r2@lab-mx104:r2# run show version Hostname: lab-mx104 Model: mx104 Junos: 14.2R7.5 -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EVPN + QinQ, individual bridge-domains for CVID's
Since you mentioned it Evpn in lsys ? I don't think that works. If so please tell me it does so I can try it. I really would like to know if I can run EVPN in LSYS on MX104... let me know if I need to simply change to a different version of JUNOS and I'll do it. [edit] r2@lab-mx104:r2# set routing-instances test instance-type ? Possible completions: forwarding Forwarding instance l2backhaul-vpn L2Backhaul/L2Wholesale routing instance l2vpnLayer 2 VPN routing instance layer2-control Layer 2 control protocols mpls-internet-multicast Internet Multicast over MPLS routing instance no-forwardingNonforwarding instance virtual-router Virtual routing instance virtual-switch Virtual switch routing instance vpls VPLS routing instance vrf Virtual routing forwarding instance [edit] [edit] r2@lab-mx104:r2# run show version Hostname: lab-mx104 Model: mx104 Junos: 14.2R7.5 -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using a QFX5100 without QFabric?
Not to change subject too much, but, In case you are wanting to extend your mpls cloud (I'm assuming your MX core is mpls-enabled) further out into the aggregation/access edge, you could go with the qfx-5100 cousin... acx5048. I've been pretty pleased with them. I've deployed 30 or 40 of these now in my network with as cisco asr9k core. -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EVPN + QinQ, individual bridge-domains for CVID's
Expected hack with QFX5100 PE with CVID <-> Trunk Port <-> P or PE with EVPN Or Logical System, but we stop using those on MXs after some crashes in the past. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 10/23/17 23:33, Andrew Thrift wrote: Hello All, I have been working on a scenario that I have not been able to solve. I have an ae interface that has multiple QinQ services coming in, some of these are terminating into l2circuits(CCC) and others are terminating into EVPN routing instances. So far with EVPN I have only been dealing with L2 transport, effectively bridging the outer tag to an EVPN routing-instance, which happily transports all the inner tags across the EVPN transport to the other PE routers. What I am now trying to achieve is to terminate some of the inner-tags (CVID's) to IRB instances. I started by trying to split the inner-cvid's into their own bridge-domains, but JunOS seems to not like mapping inner-vlan's into bridge-domains with EVPN instances. Has anyone else managed to terminate inner tags in an EVPN instance into separate bridge domains? Or is this just an unsupported configuration ? Regards, Andrew ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using a QFX5100 without QFabric?
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 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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Using a QFX5100 without QFabric?
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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
