[j-nsp] Any sort of EVPN Success with: vMX 16.x and QFX5100
Hi, We've been working on a lab re-creating a Juniper whitepaper on the subject of EVPN, but we cannot figure out where we messed up =D Everything show up correctly in the core, spines/leafs, but L2 broadcast's are not propagated/managed as expected by the Core. aka: cannot ping between test devices on access ports for the Tenant since ARP broadcast are not answered. Anyone got any success? Or do we have the wrong white paper? Thank for your time. -- PS: I wish Juniper would adopt the standard to list the devices and their firmware to those whitepapers. Took 1/2 a day to figure out we needed 16.x for the vMX part of the equation. Oh and some peer review =D White paper in question: https://www.juniper.net/assets/us/en/local/pdf/whitepapers/2000606-en.pdf - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EVPN -VXLAN in production
Hi, Contrary to earlier feedback I received, this works. Lab of 6 x QFX. 5 in a VCF, 1 standalone, connected thru EVPN/VXLAN. And a pair of MX. QFX5100 14.1D5x and vMX (16.x), we decided not to use our production MX yet; irb routing for the VLAN's spanning the EVPN/VXLAN between the 2 stacks need to use the MX; local irb routing is available locally to the stack if needed; Drawback: I couldn't test it yet, but you shouldn't be able to pass your customer LACP natively across the EVPN. There is a new image that should be out this month that greatly help. Check for Licensing, I have BGP+VCF+VXLAN. As always check your JRep first =D Be sure to use the IP of the lo0 for the EVPN sessions, we where stalled on that one for a few days. And if your spending $$$ on the QFX10k, that should be the same as having the MXs Good luck. - 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 11/25/16 11:51, Alexander Bochmann wrote: > ...on Tue, Nov 22, 2016 at 03:28:44PM +, Jackson, William wrote: > > > On 22/11/2016, 15:02, "juniper-nsp on behalf of Amos Rosenboim" > <juniper-nsp-boun...@puck.nether.net on behalf of a...@oasis-tech.net> wrote: > >> We are considering EVPN-VXLAN for extending L2 between rows (we > failed convincing the server guys that they don’t need this). > >> We are wondering if anyone has any experience with this technology in > production yet ? > >> Specifically with QFX5100 and with QFX10002. > > Yes I have two small pods setup using VXLAN/EVPN with IP Fabric. ( eBGP > underlay/iBGP overlay ) > > D40 is the place to be on code and seems to have fixed most of the > problems I had. > > I assume you're using QFX10002s since I had the impression that the > QFX5100 can not do egress VXLAN routing (due to Trident II limitations)? > > Or has there been some development in that regard that I have missed? > > Alex. > > ___ > 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] QFX 5100 and Q-in-Q
Well, We're having all sort of massive failure making Q-in-Q works in our QFX5100 in standard and VCF mode... and that with 14.x, 15x, 16.x, 17.x Such a simple thing should not take 1 week of back & forth with JTAC. Anyone have some experience to share on that subject? Thank. -- ----- 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RES: RES: QFX 5100 and Q-in-Q
Hi, Yes same configuration. We pretty much received a confirmation from the JTAC about the limitation about PVST+. ( Hopefully a Jman could be clearer on the "why", for the enlightenment of the list ) We deployed those QFX5100 for customers in need of >1Gbps QinQ. l2circuits works perfectly thou. - 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 03/25/17 14:00, Alexandre Guimaraes wrote: Chuck, The way that are you doing works well (I call it as dot1q tagging services), The way that I need to use, L2TP doesn't works. (QinQ services) Due the limited "QinQ", I need to keep CPE at customers to deal with QinQ/L2TP services. Att. AŁexandre De: Chuck Anderson Enviado: sábado, 25 de março 09:28 Assunto: Re: [j-nsp] RES: RES: QFX 5100 and Q-in-Q Para: juniper-nsp@puck.nether.net I'm using Q-in-Q as a tap aggregation function. Port mirrors and/or optical taps from other devices are connected to QFX5100 ports which encapsulate the foreign traffic with Q-in-Q, then flood the traffic to all ports in the same outer VLAN. Analyzers are connected to the output ports. It may be that L2 protocols like PVST+ are not passing through, but that doesn't matter much for my use case: set interfaces xe-0/0/0 description "MIRROR1 INPUT from device foo" set interfaces xe-0/0/0 flexible-vlan-tagging set interfaces xe-0/0/0 native-vlan-id 2 set interfaces xe-0/0/0 mtu 9216 set interfaces xe-0/0/0 encapsulation extended-vlan-bridge set interfaces xe-0/0/0 unit 2 vlan-id-list 1-4094 set interfaces xe-0/0/0 unit 2 input-vlan-map push set interfaces xe-0/0/0 unit 2 input-vlan-map vlan-id 2 set interfaces xe-0/0/0 unit 2 output-vlan-map pop set interfaces xe-0/0/0 unit 2 family ethernet-switching filter output DISCARD set interfaces xe-0/0/24 description "MIRROR1 OUTPUT to analyzer bar" set interfaces xe-0/0/24 flexible-vlan-tagging set interfaces xe-0/0/24 mtu 9216 set interfaces xe-0/0/24 encapsulation extended-vlan-bridge set interfaces xe-0/0/24 unit 2 vlan-id-list 1-4094 set interfaces xe-0/0/24 unit 2 input-vlan-map push set interfaces xe-0/0/24 unit 2 input-vlan-map vlan-id 2 set interfaces xe-0/0/24 unit 2 output-vlan-map pop set interfaces xe-0/0/24 unit 2 family ethernet-switching filter input DISCARD set vlans MIRROR1 interface xe-0/0/0.2 set vlans MIRROR1 interface xe-0/0/24.2 set vlans MIRROR1 switch-options no-mac-learning On Sat, Mar 25, 2017 at 12:22:40AM +, Alexandre Guimaraes wrote: > Chuck, > > > Could you please share portion of your QinQ configuration? In my tests, facing customer side, used: > > set vlans S-VLAN-200 vlan-id 200 > set vlans S-VLAN-200 interface ge-0/0/14.200 > > set interfaces ge-0/0/14 flexible-vlan-tagging > set interfaces ge-0/0/14 native-vlan-id 200 > set interfaces ge-0/0/14 mtu 6000 > set interfaces ge-0/0/14 encapsulation extended-vlan-bridge > set interfaces ge-0/0/14 unit 200 vlan-id-list 10-30 > set interfaces ge-0/0/14 unit 200 input-vlan-map push > set interfaces ge-0/0/14 unit 200 output-vlan-map pop > > > Even you can encapsulates customer vlan inside a service vlan, all layer 2 protocols will not pass. > > > > > De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Chuck Anderson [c...@wpi.edu] > Enviado: sexta-feira, 24 de março de 2017 18:33 > Para: juniper-nsp@puck.nether.net > Assunto: Re: [j-nsp] RES: QFX 5100 and Q-in-Q > > I had to load 14.1X53-D40 to have a basic working Q-in-Q config. D35 > was broken in some fundamental way. > > On Fri, Mar 24, 2017 at 04:31:56PM +, Alexandre Guimaraes wrote: > > Alain, > > > > As far i know, QinQ - L2TP does not work at QFX5100. > > > > Att., > > Alexandre > > > > > > De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Alain Hebert [aheb...@pubnix.net] > > Enviado: sexta-feira, 24 de março de 2017 13:07 > > Para: juniper-nsp@puck.nether.net > > Assunto: [j-nsp] QFX 5100 and Q-in-Q > > > > Well, > > > > We're having all sort of massive failure making Q-in-Q works in our > > QFX5100 in standard and VCF mode... and that with 14.x, 15x, 16.x, 17.x > > > > Such a simple thing should not take 1 week of back & forth with JTAC. > > > > Anyone have some experience to share on that subject? > > > > Thank. ___ 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] RES: QFX 5100 and Q-in-Q
Hi, Thank you for the feedback. I'll have to confirm with the other engineer, but for sure, with 14.1X53-D42.3, PVST+ is not working. Packets comes out untagged at the other end :( Even with the knob documented in JunOS for QFX5100. - 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 03/24/17 17:33, Chuck Anderson wrote: I had to load 14.1X53-D40 to have a basic working Q-in-Q config. D35 was broken in some fundamental way. On Fri, Mar 24, 2017 at 04:31:56PM +, Alexandre Guimaraes wrote: Alain, As far i know, QinQ - L2TP does not work at QFX5100. Att., Alexandre De: juniper-nsp [juniper-nsp-boun...@puck.nether.net] em nome de Alain Hebert [aheb...@pubnix.net] Enviado: sexta-feira, 24 de março de 2017 13:07 Para: juniper-nsp@puck.nether.net Assunto: [j-nsp] QFX 5100 and Q-in-Q Well, We're having all sort of massive failure making Q-in-Q works in our QFX5100 in standard and VCF mode... and that with 14.x, 15x, 16.x, 17.x Such a simple thing should not take 1 week of back & forth with JTAC. Anyone have some experience to share on that subject? Thank. ___ 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] QFX 5100 Q-in_Q + mac rewrite in the same switch or VCF
Well, with 14.1X53.D40.8 For some reason it strip VLANs from PVST+ frames. We captured the output from a Cisco ME3400 which has the VLAN, And when we capture on the other end of the QFX everything is right BUT for PVST+ packets which lose their encap. Curious bug... -- - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Any sort of EVPN Success with: vMX 16.x and QFX5100
Place a sniffer between the vMX and the QFX, you'll see: the ARP go from vMX to QFX and get an answer; the ARP go from QFX to the vMX and you wont get an answer, 99.% of the time; ( It worked once for me and only for a while, but at this point I pretty much feel like I'm getting trolled by J. That whole QFX+L2TP+VCF really didn't help ) PS: We pretty much gave up on that whole none of the whitepaper from J work in a lab setting since they forgot to list the hardware and the Junos version they used. - 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 07/27/17 05:47, Anand Beedi wrote: Hello, I am facing similar problem with EVPN over MPLS. I am using 17.1R1.8 Junos build. The control plane, mac table looks fine. I see ARP resolved on one-end but other is not happening Issues with both instance-type as EVPN or Virtual-switch with EVPN. No IRB configured. Any help Output of Ping and tcpdump on both sides ** Ping f=> 21.1.1.1 ** root@cuttack> ping 21.1.1.1 interface ge-2/0/4.2345 PING 21.1.1.1 (21.1.1.1): 56 data bytes ++ root@cuttack:~ # tcpdump -i ge-2/0/4.2345 -s 1500 Listening on ge-2/0/4.2345, capture size 1500 bytes 09:58:38.787719 Out arp who-has 21.1.1.1 tell 21.1.1.2 09:58:39.588860 Out arp who-has 21.1.1.1 tell 21.1.1.2 09:58:40.388273 Out arp who-has 21.1.1.1 tell 21.1.1.2 09:58:41.188860 Out arp who-has 21.1.1.1 tell 21.1.1.2 root@kochin% tcpdump -i ge-0/0/6.2345 -s 1500 Listening on ge-0/0/6.2345, capture size 1500 bytes arp who-has 21.1.1.1 tell 21.1.1.2 arp reply 21.1.1.1 is-at 80:71:1f:16:38:06 arp who-has 21.1.1.1 tell 21.1.1.2 arp reply 21.1.1.1 is-at 80:71:1f:16:38:06 arp who-has 21.1.1.1 tell 21.1.1.2 arp reply 21.1.1.1 is-at 80:71:1f:16:38:06 arp who-has 21.1.1.1 tell 21.1.1.2 ** Ping => 21.1.1.2 ** root@kochin> ping 21.1.1.2 PING 21.1.1.2 (21.1.1.2): 56 data bytes root@kochin% tcpdump -i ge-0/0/6.2345 -s 1500 IP 21.1.1.1 > 21.1.1.2: ICMP echo request, id 26512, seq 4, length 64 IP 21.1.1.1 > 21.1.1.2: ICMP echo request, id 26512, seq 5, length 64 IP 21.1.1.1 > 21.1.1.2: ICMP echo request, id 26512, seq 6, length 64 IP 21.1.1.1 > 21.1.1.2: ICMP echo request, id 26512, seq 7, length 64 root@cuttack:~ # tcpdump -i ge-2/0/4.2345 -s 1500 Listening on ge-2/0/4.2345, capture size 1500 bytes ^C 0 packets received by filter 0 packets dropped by kernel Cheers, Anand Anand Beedi o +91 80 612 10427 m +91 97396 77746 abe...@juniper.net www.juniper.net -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Alexander Marhold Sent: Friday, October 7, 2016 20:46 To: aheb...@pubnix.net; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Any sort of EVPN Success with: vMX 16.x and QFX5100 Hi As far as I know the paper deals with EVPN over VXLAN And As far as I know the vMX 16.1 does NOT support EVPN over VXLAN ( at least that I was told by some Juniper SEs and by the PLM manager for EVPN) Regards Alexander INDC -Ursprüngliche Nachricht- Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von Alain Hebert Gesendet: Freitag, 7. Oktober 2016 16:24 An: juniper-nsp@puck.nether.net Betreff: [j-nsp] Any sort of EVPN Success with: vMX 16.x and QFX5100 Hi, We've been working on a lab re-creating a Juniper whitepaper on the subject of EVPN, but we cannot figure out where we messed up =D Everything show up correctly in the core, spines/leafs, but L2 broadcast's are not propagated/managed as expected by the Core. aka: cannot ping between test devices on access ports for the Tenant since ARP broadcast are not answered. Anyone got any success? Or do we have the wrong white paper? Thank for your time. -- PS: I wish Juniper would adopt the standard to list the devices and their firmware to those whitepapers. Took 1/2 a day to figure out we needed 16.x for the vMX part of the equation. Oh and some peer review =D
Re: [j-nsp] MX240+QFX5100 using Fusion - Any positive experience
Hi, Can you provide a "show version" and "show chassis satellite softwar" Might be faster just to match your version. - 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 08/10/17 14:34, santiago martinez wrote: Hi there, which MPC are you using. We have fusion edge on our lab with mx104 and no problem so far. We have a mx240 , if we have the same MPC I guess I can give it a try. Can you share your chassis config / show chassis satellite output / show interface ge-102/0/20 Santi Sent from my iPhone On 10 Aug 2017, at 13:08, Alain Hebert <aheb...@pubnix.net> wrote: Hi, I'm thinking our local Juniper vendor is taking us for his personal Q Another tech sold to us instead of VCF: Fusion. Anyone got it working on MX240+QFX5100... Config: < basic satellite config > set interfaces ge-102/0/20 unit 0 family inet address 10.25.1.13/31 Test: Every time I try to ping .12, I get this log. Aug 10 07:49:56 fpc2 KERNEL/PFE APP=NH OUT OF SYNC: error code 3 REASON: NH add received for an ifl that does not exist ERROR-SPECIFIC INFO: nh_id=684 , type = Hold, ifl index 348 does not exist TYPE-SPECIFIC INFO: none What we looked at: 1. Yes everything was rebooted; 2. Yes The satellite look fine; 3. Yes the latest firmware is on the MX and the QFX; MX: junos-install-mx-x86-32-17.2R1.13.tgz QFX: satellite-3.1R1.3-signed.tgz since satellite-3.1R1.4.tgz is not signed so it cannot be installed. 4. Yes the optic are the same that those working in our QFX Junos native; And no amount of GoogleFu could find a solution. Our next step is JTAC. -- - 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 ___ 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] MX240+QFX5100 using Fusion - Any positive experience
Hi, I'm thinking our local Juniper vendor is taking us for his personal Q Another tech sold to us instead of VCF: Fusion. Anyone got it working on MX240+QFX5100... Config: < basic satellite config > set interfaces ge-102/0/20 unit 0 family inet address 10.25.1.13/31 Test: Every time I try to ping .12, I get this log. Aug 10 07:49:56 fpc2 KERNEL/PFE APP=NH OUT OF SYNC: error code 3 REASON: NH add received for an ifl that does not exist ERROR-SPECIFIC INFO: nh_id=684 , type = Hold, ifl index 348 does not exist TYPE-SPECIFIC INFO: none What we looked at: 1. Yes everything was rebooted; 2. Yes The satellite look fine; 3. Yes the latest firmware is on the MX and the QFX; MX: junos-install-mx-x86-32-17.2R1.13.tgz QFX: satellite-3.1R1.3-signed.tgz since satellite-3.1R1.4.tgz is not signed so it cannot be installed. 4. Yes the optic are the same that those working in our QFX Junos native; And no amount of GoogleFu could find a solution. Our next step is JTAC. -- - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX240+QFX5100 using Fusion - Any positive experience
CoS queues : 8 supported, 8 maximum usable queues Schedulers : 0 Current address: f4:b5:2f:44:48:04, Hardware address: f4:b5:2f:44:48:04 Last flapped : 2017-08-10 08:03:30 EDT (07:23:44 ago) Input rate : 0 bps (0 pps) Output rate: 0 bps (0 pps) Active alarms : None Active defects : None Interface transmit statistics: Disabled Logical interface xe-102/0/22.0 (Index 351) (SNMP ifIndex 555) Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2 Input packets : 0 Output packets: 85 Protocol inet, MTU: 1500 Max nh cache: 75000, New hold nh limit: 75000, Curr nh cnt: 0, Curr new hold cnt: 0, NH drop cnt: 0 Flags: Sendbcast-pkt-to-re, Is-Primary Addresses, Flags: Is-Default Is-Preferred Is-Primary Destination: 9.9.9/24, Local: 9.9.9.9, Broadcast: 9.9.9.255 Protocol multiservice, MTU: Unlimited - 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 08/10/17 14:34, santiago martinez wrote: Hi there, which MPC are you using. We have fusion edge on our lab with mx104 and no problem so far. We have a mx240 , if we have the same MPC I guess I can give it a try. Can you share your chassis config / show chassis satellite output / show interface ge-102/0/20 Santi Sent from my iPhone On 10 Aug 2017, at 13:08, Alain Hebert <aheb...@pubnix.net> wrote: Hi, I'm thinking our local Juniper vendor is taking us for his personal Q Another tech sold to us instead of VCF: Fusion. Anyone got it working on MX240+QFX5100... Config: < basic satellite config > set interfaces ge-102/0/20 unit 0 family inet address 10.25.1.13/31 Test: Every time I try to ping .12, I get this log. Aug 10 07:49:56 fpc2 KERNEL/PFE APP=NH OUT OF SYNC: error code 3 REASON: NH add received for an ifl that does not exist ERROR-SPECIFIC INFO: nh_id=684 , type = Hold, ifl index 348 does not exist TYPE-SPECIFIC INFO: none What we looked at: 1. Yes everything was rebooted; 2. Yes The satellite look fine; 3. Yes the latest firmware is on the MX and the QFX; MX: junos-install-mx-x86-32-17.2R1.13.tgz QFX: satellite-3.1R1.3-signed.tgz since satellite-3.1R1.4.tgz is not signed so it cannot be installed. 4. Yes the optic are the same that those working in our QFX Junos native; And no amount of GoogleFu could find a solution. Our next step is JTAC. -- - 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 ___ 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] J-NSP list working ?
Or we gave up =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 07/08/17 14:58, Job Snijders wrote: I got this message! The silence just means that Junos is perfect now and there is nothing left to do ;-) Kind regards, Job ___ 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] MX240 (orMX960) with QFX5100 in Fusion
Hi, Anyone has feedback about Fusion when MX240-MX960 and QFX5100 are concerned. Our foray into QFX5100/VCF only was not very successful. :( -- - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper QFX 5100 - Second source of QSFP -and- VCF issues resolved... for now.
Hi, As for a bit before 14.1X53-D42.3 (sorry I do not have the exact version) NSSU worked on the 6 members fab with 2 re, all QFX 5100. That's a plus. - 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 05/02/17 11:09, Sebastian Wiesinger wrote: * Alain Hebert <aheb...@pubnix.net> [2017-05-02 13:18]: Hi, Beside Juniper, anyone have some successful experience to share about a second source of QSFP+-40-LR4? All the optics tested from our usual rock solid providers ended up flapping or spamming log message :( Hi, we use Flexoptix Q.1640G.10 (and for anything else as well). I don't think we have them in QFX right now but they work fine in EX4300. PS: Our QFX5100 VCF Fabric (6) is finally stable with the preferred release of Junos, TLDR: You cannot get out of the Spine/Leaf paradigm (contrary to initial documentation which also showed full mesh and linked routing engines). Also there was an issue with 1 forwarding-options. Did you try NSSU? :> Regards Sebastian ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper QFX 5100 - Second source of QSFP -and- VCF issues resolved... for now.
Little update on this. While a lot of people reported excellent result with the same FS model, while we're very confident in FS products, I can get that link stable... Here our lab notes so far - Our 2 Fiberstore QSFPP-40GBASE-LR4. Connected back to back With -10db/-12db pads to make sure to not burn them (still required? we had auto-adjusting 10Gb in the past) And 0 traffic. -- Model: qfx5100-48s-6q Junos: 14.1X53-D42.3 -- Xcvr 48 REV 01 740-032986 JU49170311013 QSFP+-40G-LR4 Laser output power: 0.437 mW / -3.60 dBm Laser receiver power : 0.040 mW / -14.03 dBm Laser output power: 0.758 mW / -1.21 dBm Laser receiver power : 0.048 mW / -13.22 dBm Laser output power: 0.743 mW / -1.29 dBm Laser receiver power : 0.043 mW / -13.62 dBm Laser output power: 0.646 mW / -1.89 dBm Laser receiver power : 0.036 mW / -14.38 dBm Xcvr 49 REV 01 740-032986 JU49170311014 QSFP+-40G-LR4 Laser output power: 0.992 mW / -0.04 dBm Laser receiver power : 0.048 mW / -13.19 dBm Laser output power: 1.315 mW / 1.19 dBm Laser receiver power : 0.098 mW / -10.08 dBm Laser output power: 1.094 mW / 0.39 dBm Laser receiver power : 0.109 mW / -9.62 dBm Laser output power: 0.945 mW / -0.25 dBm Laser receiver power : 0.061 mW / -12.13 dBm -- In between those log entries, the sync is stable 4x10Gbps. May 5 04:42:04 lab-evpn fpc0 UPDN msg to kernel for ifd:et-0/0/49, flag:2, speed: 0, duplex:0 May 5 04:42:04 lab-evpn fpc0 UPDN msg to kernel for ifd:et-0/0/48, flag:2, speed: 0, duplex:0 May 5 04:42:05 lab-evpn fpc0 UPDN msg to kernel for ifd:et-0/0/49, flag:1, speed: 0, duplex:0 May 5 04:42:05 lab-evpn fpc0 UPDN msg to kernel for ifd:et-0/0/48, flag:1, speed: 0, duplex:0 May 5 08:57:41 lab-evpn fpc0 UPDN msg to kernel for ifd:et-0/0/49, flag:2, speed: 0, duplex:0 May 5 08:57:41 lab-evpn fpc0 UPDN msg to kernel for ifd:et-0/0/48, flag:2, speed: 0, duplex:0 May 5 08:57:42 lab-evpn fpc0 UPDN msg to kernel for ifd:et-0/0/49, flag:1, speed: 0, duplex:0 May 5 08:57:42 lab-evpn fpc0 UPDN msg to kernel for ifd:et-0/0/48, flag:1, speed: 0, duplex:0 - Alain hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911http://www.pubnix.net Fax: 514-990-9443 On 05/02/17 07:18, Alain Hebert wrote: Hi, Beside Juniper, anyone have some successful experience to share about a second source of QSFP+-40-LR4? All the optics tested from our usual rock solid providers ended up flapping or spamming log message :( Thank you for your time. PS: Our QFX5100 VCF Fabric (6) is finally stable with the preferred release of Junos, TLDR: You cannot get out of the Spine/Leaf paradigm (contrary to initial documentation which also showed full mesh and linked routing engines). Also there was an issue with 1 forwarding-options. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] A wierd problem with QinQ at QFX5100
And PFE crashing when de-provisioning some IP customer in VCP with a CCC customer near by =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 06/01/17 15:45, Roger Wiklund wrote: Hi Try 14.1X53-D43, it has some fixes for L2PT. /Roger On Sat, May 27, 2017 at 9:50 PM, Giuliano C. Medalha <giuli...@wztech.com.br> wrote: Andrew Good afternoon. Q-in-Q works fine here for us in our production networks and in our labs. Do you need the a sample config ? We need to umderstand the topology to help. You can contact us in private. Can you share with us ? The problem is not qinq itself ... the problem is the limited numbers of protocols supported by L2PT in Junos ELS ( for qfx5100 ) My sugestion is to buy the EDGE license and use MPLS L2circuit to transport protocols PDUs ... only if you need it. But if you does not need the pdu transport and need point to multipoint solutions ... another way is to use VXLAN / EVPN config. Works fine for the QFX family We have this solutions implemented in some service providers and DC environments ... and they use an access switch ( like ex2200 ) to encapsulate pdu using qinq before the qfx5100. Works fine and we can automate it with a tool that we developed ( in cloud ) to provision the vxlan tunnel on each qfx5100 interface. Hope this helps Att, Giuliano C. Medalha WZTECH NETWORKS +55 (17) 98112-5394 giuli...@wztech.com.br<mailto:giuli...@wztech.com.br> From: juniper-nsp <juniper-nsp-boun...@puck.nether.net> on behalf of Andrew Osnach <and...@osnach.kiev.ua> Sent: Wednesday, May 24, 2017 11:33:20 AM To: Alexandre Guimaraes; Allan Eising Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] A wierd problem with QinQ at QFX5100 Hi guys, Thank you for the answers. It's really sad to hear about it and there're two equally unsatisfactory solutions: vlan mapping or vlan ranges reservation.. Thanks again for the explanation! On 23.05.17 14:52, Alexandre Guimaraes wrote: Andrew Unfortunately, Allan is correct... don't expect use QinQ in ELS system, will be very annoying trying to find a way the let the packets flow inside. And they don't flow gracefully A friend told to me: QFX are Ferraris I answer him: then Juniper, don't knows how to drive. :) att Alexandre Em 23 de mai de 2017, às 06:00, Allan Eising <eis...@nordu.net> escreveu: Excerpts from Andrew Osnach's message of May 23, 2017 10:31 am: Hello, I have a mixed VC (QFX5100 and 3500, if it means) with 14.1X53-D40.8. There's an interface that incapsulates C-VLANs into S-VLAN: set interfaces ae31 flexible-vlan-tagging set interfaces ae31 mtu 9216 set interfaces ae31 encapsulation extended-vlan-bridge set interfaces ae31 unit 3174 vlan-id-list 21-22 set interfaces ae31 unit 3174 input-vlan-map push set interfaces ae31 unit 3174 input-vlan-map vlan-id 3174 set interfaces ae31 unit 3174 output-vlan-map pop The other side: set interfaces ae0 flexible-vlan-tagging set interfaces ae0 mtu 9216 set interfaces ae0 encapsulation extended-vlan-bridge set interfaces ae0 unit 3174 vlan-id 3174 S-VLAN configured like this: set vlans sv3174-qinq interface ae0.3174 set vlans sv3174-qinq interface ae31.3174 At this point everything works fine, but if I create a VLAN with the same ID as a C-VLAN (21 or 22): set vlans v21-user vlan-id 21 the traffic in the C-VLAN 21 stops. When I delete v21-user the traffic in C-VLAN 21 restores. What's wrong with it and how can I fix it? Hi, QinQ on the QFX and all the other boxes running the ELS style is a bit of an abomination. VLANs configured with extended-vlan-bridge interfaces are forwarded using a different daemon than VLANs forwarded using the classic ethernet-switching daemon. It's quite likely that you cannot share VLAN IDs between the two methods of forwarding. I would bug Juniper about this, but I wouldn't expect them to be able to fix it. Best regards, Allan Eising ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper QFX 5100 - Second source of QSFP -and- VCF issues resolved... for now.
Hi, Beside Juniper, anyone have some successful experience to share about a second source of QSFP+-40-LR4? All the optics tested from our usual rock solid providers ended up flapping or spamming log message :( Thank you for your time. PS: Our QFX5100 VCF Fabric (6) is finally stable with the preferred release of Junos, TLDR: You cannot get out of the Spine/Leaf paradigm (contrary to initial documentation which also showed full mesh and linked routing engines). Also there was an issue with 1 forwarding-options. -- - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5048 - 40 gbps ER 40 km optic
Well, We had a few issues with FS.com devices in our QFX's. We're still looking if its the platform or FS.com. Although we replaced them with Juniper certified devices from optic.ca and its going better for the past 3 weeks. - 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/13/17 00:59, Gustavo Santos wrote: Because of the possibility of out of order packet issues "on per packet" load balance and a with flow based load balance, a 10Gbps limit per flow. 2017-10-11 22:57 GMT-03:00 Colton Conor <colton.co...@gmail.com>: So why go with this then? You could litterally do a passive mux and 4 10G colored optics for much much less than that. Check out FS.com On Tue, Oct 10, 2017 at 4:41 PM, Gustavo Santos <gustkil...@gmail.com> wrote: Here in Brazil where everything costs a lot more than US because of taxes, about U$2485 per module. 2017-10-09 23:53 GMT-03:00 Colton Conor <colton.co...@gmail.com>: How much do those cost? We have used many of the 10KM optics in out ACX5048, but never the 40KM due to cost. It seems much cheaper to use 4 colored SFP+'s? On Mon, Oct 9, 2017 at 8:16 AM, Gustavo Santos <gustkil...@gmail.com> wrote: Hi, It's an ER4 , LR4 is just the label precision coded for compatibility. The module part name is PRE-QSFP-ER4 2017-10-04 19:57 GMT-03:00 Aaron Gould <aar...@gvtc.com>: Hey that’s good to know Gustavo… but LR4 , is that shorter than 40 km ? -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] QFX 5100 can you mix vlan-ccc + vlan-bridge on the same interface with 14.1X53-D43.7
Well problem[S],
That why I'm looking to see if our lab is working out of luck,
because we're mixing vlan-bridge and vlan-ccc units on the same ae0 and
xe-*, and everything is fine for over a month of burn testing.
Thanks for your time.
-
The context,
Our 17.x lab of QFX with a MX240 and vMX is working fine.
We got a pretty good MPLS alphabet soup recipe ready for
production. MPLS+ISIS+BGP Underlay, aeX + vlan-bridge + ccc mixing
together, EVPN+VXLAN on their own port, VRFs, without any data plane
drama, etc.
So taking from that success...
The problem,
We're running some QFX5100 in VCF in production, with 14.x, and
added a VLAN-CCC on a port with other unit's in VLAN-BRIDGE which pretty
much made the data plane hate us about 10h later, when we tried to
figure out why there was no data thru that circuit.
And by hating, I mean spewing ~300k/pps of unknowned traffic badly
encapsulated.
( The fix was delete the port configuration, commit, rollback 2,
commit )
Jeff pretty much pointed us to a PR mentioning that type of
behavior on 14.x train...
The solution,
Was to hairpin 2 ports on the QFX5100/VCF stack. 1 port being only
the 2 vlan-ccc and the other being the 2 vlan-bridge of the VLANs we
wanted to CCC out of that aeX.
-
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 09/28/17 12:47, Pavel Lunin wrote:
I really doubt that it's supported on QFX5100. Not 100% sure though.
But what's your problem? It does not work in this combination or does
not work at all?
IIRC, ex4600/qfx5100 do not support control word on pseudowires as
well (like ex4500/4550). So if you have something like an MX on the
other side, Martini signaling comes up but you see no traffic, try
no-control-word.
Kind regards,
Pavel
28 сент. 2017 г. 4:12 ПП пользователь "Alain Hebert"
<aheb...@pubnix.net <mailto:aheb...@pubnix.net>> написал:
Been crashing hard on google this morning... Cannot find any hint
of limitations on the QFX platform for this case.
Sample config
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 111 {
encapsulation vlan-ccc;
vlan-id 111;
input-vlan-map pop;
output-vlan-map push;
}
unit 222 {
encapsulation vlan-ccc;
vlan-id 222;
input-vlan-map pop;
output-vlan-map push;
}
unit 333 {
encapsulation vlan-bridge
vlan-id 333;
}
Just no input / output with:
Model: qfx5100-48s-6q
Junos: 14.1X53-D43.7
But it works in our lab
Model: qfx5100-48s-6q
Junos: 17.2R1.13
--
-
Alain Hebert aheb...@pubnix.net <mailto:aheb...@pubnix.net>
PubNIX Inc.
50 boul. St-Charles
<https://maps.google.com/?q=50+boul.+St-Charles=gmail=g>
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911 http://www.pubnix.net Fax:
514-990-9443
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
<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] QFX 5100 can you mix vlan-ccc + vlan-bridge on the same interface with 14.1X53-D43.7
Been crashing hard on google this morning... Cannot find any hint
of limitations on the QFX platform for this case.
Sample config
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 111 {
encapsulation vlan-ccc;
vlan-id 111;
input-vlan-map pop;
output-vlan-map push;
}
unit 222 {
encapsulation vlan-ccc;
vlan-id 222;
input-vlan-map pop;
output-vlan-map push;
}
unit 333 {
encapsulation vlan-bridge
vlan-id 333;
}
Just no input / output with:
Model: qfx5100-48s-6q
Junos: 14.1X53-D43.7
But it works in our lab
Model: qfx5100-48s-6q
Junos: 17.2R1.13
--
-
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX 5100 and VLAN-CCC Unicast SNMP Counter wraping
Hi, Is it common knowledge that the Unicast Packets (Both In & Out) COUNTER32 for VLAN-CCC wrap at 0x3fff instead of 0x? Model: qfx5100-48s-6q Junos: 17.2R1.13 I have plenty of example from snmpget (sample taken every 10s) that show the counter around 0x3fff. aka: 1,073,640,642 (0x3ffe74c2) before wrapping down into the 200k region. Which match my iperf of 80k pps running on that VLAN-CCC PS: Wasn't fun trying to explain that to JNP Level 1 JTAC guy. I was really expecting that he would understand basic computer science concept as what is hex and what's wraping. -- ----- 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MIC-3D-4XGE-XFP in a MX104?
Hi, The 2 port / 4 ports are in the list, but only the 2 ports show up under MX80/104 and not the 4 ports. https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/general/mic-mx-series-supported.html 10-Gigabit Ethernet - 10-Gigabit Ethernet MICs with XFP - *MIC-3D-2XGE-XFP* - 2 - 10.2 - 13.2R2 By ya, at the end of the day, they is place for improvement. PS: We have 2 x 4GXE in stock for our future MX240+ because of this. - 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 12/04/17 05:26, Eric Van Tol wrote: Seems odd they would choose the same form factor for incompatible designs, but that explains why the 2-port card is more expensive. Also seems odd the 4-port MIC is listed as compatible on the MX80/MX104 on the Hardware Compatibility List. This is why I put zero trust in these sorts of tools when building systems. I can confirm that the MIC doesn't even show up in the hardware listing if you install it into an MX80. -evt ___ 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] Copper transcievers in QFX5100, EX4600 and ACX5048
Hi, We had issues with port 1 of 3 switches, it was more power related than a physical issue in our case. Once we replaced then with SRs the issue went away but only 1 set lasted, and it was the 0,2 aeX. - 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 12/05/17 10:59, Benoit Plessis wrote: Le 05/12/2017 à 16:40, Alain Hebert a écrit : Rofl, That's why!!! We where wondering why 0 & 2 worked but not 0 & 1. Did you mean you were able to plug them in and they didn't work ? ___ 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] QFX5100 ACLs
Hi, Odd. Model: qfx5100-48s-6q Junos: 17.2R1.13 I've verified with both the "pfe shell" and a Nessus scan TCP+UDP+Ports 1 thru 65535 and this input-list [ ICMP-FI OSPF-PEERS-FI LDP-PEERS-FI BGP-PEERS-FI BFD-PEERS-FI VRRP-FI DHCP-FI -MGMT-FI DROP-FI ] Worked as advertised (for once). ----- 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 12/10/17 12:39, Andrey Kostin wrote: Hi Brendan, If you use filter-list on Lo0 interface as per "securing RE guide" then it's not supported. Only first filter in list is programmed and everything else is ignored. We ran into the same issue and had to pull it out from JTAC to confirm. Brendan Mannella писал 04.12.2017 15:51: + Programmed: YES + Total TCAM entries available: 1788 + Total TCAM entries installed : 516 Brendan Mannella TeraSwitch Inc. Main - 1.412.945.7045 Direct - 1.412.945.7049 eFax - 1.412.945.7049 Colocation . Cloud . Connectivity This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this On Mon, Dec 4, 2017 at 11:57 AM, Saku Ytti <s...@ytti.fi> wrote: Hey Brendan, This is news to me, but plausible. Can you do this for me start shell pfe network fpc0 show filter show filter hw show_term_info Compare how many TCAM entries are needed, and how many are available. Also if you can take a risk of reloading the FPC run: show filter hw show_terms_brcm This may crash your PFE, if you actually did not have all of the entries programmed in HW. commit will succeed if you build filter which will not fit in HW, there should be syslog entry, but no complain during commit. You will end up having no filter or some mangled version of it. So it's just alternative theory on why you may be accepting something you thought you aren't. On 4 December 2017 at 18:02, Brendan Mannella <bmanne...@teraswitch.com> wrote: > Hello, > > So i have been testing QFX5100 product for use as a core L3 switch/router > with BGP/OSPF. I have my standard RE filter blocking various things > including BGP from any unknown peer. I started to receive errors in my logs > showing BGP packets getting through from hosts that weren't allowed. After > digging around i found that Juniper apparently has built in ACL to allow > BGP, which bypasses my ACLs, probably for VCF or something.. Is there any > way to disable this behavior or does anyone have any other suggestions? > > root@XXX% cprod -A fpc0 -c "show filter hw dynamic 47 show_terms" > > Filter name : dyn-bgp-pkts > Filter enum : 47 > Filter location : IFP > List of tcam entries : [(total entries: 2) > Entry: 37 > - Unit 0 > - Entry Priority 0x7FFC > - Matches: > PBMP 0x0001fffc > PBMP xe > L4 SRC Port 0x00B3 mask 0x > IP Protocol 0x0006 mask 0x00FF > L3DestHostHit 1 1 > - Actions: > ChangeCpuQ > ColorIndependent param1: 1, param2: 0 > CosQCpuNew cosq: 30 > Implicit Counter > Entry: 38 > - Unit 0 > - Entry Priority 0x7FFC > - Matches: > PBMP 0x0001fffc > PBMP xe > L4 DST Port 0x00B3 mask 0x > IP Protocol 0x0006 mask 0x00FF > L3DestHostHit 1 1 > - Actions: > ChangeCpuQ > ColorIndependent param1: 1, param2: 0 > CosQCpuNew cosq: 30 > Implicit Counter > ] > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- ++ytti ___ 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] What is your experience with the EX2200
Rofl, smell like my QFX5100 experience. PS: And I think its more of a platform issue than a software issue. - 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 12/09/17 14:29, Christian Scholz wrote: I would only buy the EX2300 if somebody points a Gun in my Face - seriously! Anyone recommending a Device that purely relies on 15.1 Software does not even closely know what he is talking about... The 2300 is a Joke so far - We have 7 PR's open and weekly Core-Dumps... Stick with the EX2200 since the EX2200 is not EOL and the EX2300 is unusable until a fine Release (17.3 onwards) is available, fixing all the critical things. 15.1 is the new Windows Vista - unstable, unreliable and just a big joke - never ever ever ever use a 15.X in Production until you want to watch the World burn... Just my 2 cents... ___ 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] What is your experience with the EX2200
Well, At budget of $200k+ for 2 sites, I'm expecting more than having to road test Lada's. - 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 12/11/17 10:34, adamv0...@netconsultings.com wrote: Smells like everyone's me3600 experience, The competition is fierce nowadays forcing release of new platforms without proper regression testing. Kind of makes sense right? Allows vendors to get to market on time while saving capex related to testing, Operators test internally anyways so why to bother right? Think about it, having market converge on set of use cases and code versions and basically test for you is always more efficient than you trying to come up with a test case for every possible combination of use cases and code versions. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Alain Hebert Sent: Monday, December 11, 2017 1:18 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] What is your experience with the EX2200 Rofl, smell like my QFX5100 experience. PS: And I think its more of a platform issue than a software issue. - 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 12/09/17 14:29, Christian Scholz wrote: I would only buy the EX2300 if somebody points a Gun in my Face - seriously! Anyone recommending a Device that purely relies on 15.1 Software does not even closely know what he is talking about... The 2300 is a Joke so far - We have 7 PR's open and weekly Core-Dumps... Stick with the EX2200 since the EX2200 is not EOL and the EX2300 is unusable until a fine Release (17.3 onwards) is available, fixing all the critical things. 15.1 is the new Windows Vista - unstable, unreliable and just a big joke - never ever ever ever use a 15.X in Production until you want to watch the World burn... Just my 2 cents... ___ 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] QFX5100 ACLs
I highly recommend to not use VCF for any L3/MPLS/etc. We had a year long battle with it. And it won. Now that we're back into MPLS territory they're working fine as hell. And it will only cost us some training for the juniors. -- But I can confirm that the input-list works with a non VCF setup, using the entire MPLS Alphabet stack (IS-IS and OSPF based) - 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 12/11/17 09:45, Saku Ytti wrote: Someone pointed this to me - https://kb.juniper.net/InfoCenter/index?page=content=KB24145 No es bueno. On 4 December 2017 at 18:02, Brendan Mannella <bmanne...@teraswitch.com> wrote: Hello, So i have been testing QFX5100 product for use as a core L3 switch/router with BGP/OSPF. I have my standard RE filter blocking various things including BGP from any unknown peer. I started to receive errors in my logs showing BGP packets getting through from hosts that weren't allowed. After digging around i found that Juniper apparently has built in ACL to allow BGP, which bypasses my ACLs, probably for VCF or something.. Is there any way to disable this behavior or does anyone have any other suggestions? root@XXX% cprod -A fpc0 -c "show filter hw dynamic 47 show_terms" Filter name : dyn-bgp-pkts Filter enum : 47 Filter location : IFP List of tcam entries : [(total entries: 2) Entry: 37 - Unit 0 - Entry Priority 0x7FFC - Matches: PBMP 0x0001fffc PBMP xe L4 SRC Port 0x00B3 mask 0x IP Protocol 0x0006 mask 0x00FF L3DestHostHit 1 1 - Actions: ChangeCpuQ ColorIndependent param1: 1, param2: 0 CosQCpuNew cosq: 30 Implicit Counter Entry: 38 - Unit 0 - Entry Priority 0x7FFC - Matches: PBMP 0x0001fffc PBMP xe L4 DST Port 0x00B3 mask 0x IP Protocol 0x0006 mask 0x00FF L3DestHostHit 1 1 - Actions: ChangeCpuQ ColorIndependent param1: 1, param2: 0 CosQCpuNew cosq: 30 Implicit Counter ] ___ 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] QFX5100 ACLs
Hi, FYI, using the command from the PR, it seem right. PS: There was an issue with mixed mode that needed to be set to NO, but the exact context is eluding me right now. But it is not relevant to input-list. - Model: qfx5100-48s-6q Junos: 17.2R1.13 - Xyz> show virtual-chassis Virtual Chassis ID: Virtual Chassis Mode: Enabled Mstr Mixed Route Neighbor List Member ID Status Serial No Model prio Role Mode Mode ID Interface 0 (FPC 0) Prsnt qfx5100-48s-6q 128 Master* N VC -- + BD ID : 230 + Total TCAM entries available: 431 + Total TCAM entries needed : 80 + Term Expansion: - Term 1: will expand to 1 term : Name "ICMP-FI-NO-ICMP-Fragments" - Term 2: will expand to 7 terms: Name "ICMP-FI-ACCEPT" - Term 3: will expand to 2 terms: Name "BGP-UNDERLAY-FI-ACCEPT" - Term 4: will expand to 1 term : Name "BGP-UNDERLAY-FI-DENY" - Term 5: will expand to 2 terms: Name "LDP-UNDERLAY-FI-ACCEPT" - Term 6: will expand to 1 term : Name "LDP-UNDERLAY-FI-DENY" - Term 7: will expand to 5 terms: Name "-MGMT-FI-ACCEPT" - Term 8: will expand to 1 term : Name "DISCARD-ALL-FI-DISCARD" + Term TCAM entry requirements: - Term 1: needs 4 TCAM entries: Name "ICMP-FI-NO-ICMP-Fragments" - Term 2: needs 28 TCAM entries: Name "ICMP-FI-ACCEPT" - Term 3: needs 8 TCAM entries: Name "BGP-UNDERLAY-FI-ACCEPT" - Term 4: needs 4 TCAM entries: Name "BGP-UNDERLAY-FI-DENY" - Term 5: needs 8 TCAM entries: Name "LDP-UNDERLAY-FI-ACCEPT" - Term 6: needs 4 TCAM entries: Name "LDP-UNDERLAY-FI-DENY" - Term 7: needs 20 TCAM entries: Name "-MGMT-FI-ACCEPT" - Term 8: needs 4 TCAM entries: Name "DISCARD-ALL-FI-DISCARD" + Total TCAM entries available: 431 + Total TCAM entries needed : 80 - 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 12/11/17 13:28, Andrey Kostin wrote: Hi Alain, Good to know that now it works. It was way back in February 2016 with 13.2X51-D35.3 and below is the exempt from TAC case. We haven't been told however that a PR was raised to address the issue or there are plans to resolve it. Problem Description : We use common set of filters on all our juniper devices to protect control plane and it turnes out there is a strange problem with filter on QFX switches. When that input filter list is applied then at least ports tcp/22 and tcp/179 are world-wide open. Issue: Filter was not getting programmed in TCAM: Action taken: As per our latest communication, we have identified two reasons behind the filters not getting programmed First, the filter entries exceeded the maximum TCAM entries. Second, we observed the the QFX platforms do not support input-list. Although the config gets committed without any error, only the first filter gets programmed in TCAM. We also provided a sample configuration to demonstrate the ssh filter. JTAC engineer's examples provided: I have tried the following configs in the lab under 13.2X51-D35 and 14.1X53-D30 and have observed the following: Config independent of the group: set interfaces lo0 unit 0 family inet filter input-list [ accept-ftp accept-ssh ] Config within group: set groups common:lo-filter interfaces lo0 unit 0 family inet filter input-list accept-ftp set groups common:lo-filter interfaces lo0 unit 0 family inet filter input-list accept-ssh In both cases, the configuration goes through without any error but only the first filter (accept-ftp) actually gets programmed in the PFE programs as can observed below: TFXPC0(vty)# show filter Program Filters: --- Index Dir Cnt Text Bss Name -- -- -- -- Term Filters: Index Semantic Name -- -- 1 Classic accept-ftp 2 Classic accept-ssh 3 Classic lo0.0-i 17000 Classic __default_arp_policer__ 16777216 Classic fnp-filter-level-all TFXPC0(vty)# show filter hw 3 show_term_info == Filter index : 3 == - Filter name : lo0.0-i + Programmed: YES + BD ID : 184 + Total TCAM entries available: 1528 + Total TCAM entries needed : 8 + Term Expansion: - Term 1: will expand to 1 term : Name "accept-ftp-0" - Term 2: will expand to 1 term : Name "accept-ftp-1" + Term TCAM entry requirements: - Term 1: needs 4 TCAM entries: Name "accept-ftp-0" - Term 2: needs
[j-nsp] MX80 v MX104
Hi, Beside the extra RE-slot of the 104 and a few more slots. Is there any more drawback (beside the knowned hella slow RE which is the same as the 104) of opting for the MX80? It looks like 4 10Gb XFP + 2 slot of 2 10Gb XFP is the maximum in the 80 case. Which will be viable for the project. PS: With a small budget, and they're buying 2 boxes anyway... and they're not interested in MS-MIC -- - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Copper transcievers in QFX5100, EX4600 and ACX5048
Rofl, That's why!!! We where wondering why 0 & 2 worked but not 0 & 1. ----- 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 12/05/17 09:40, Karl Gerhard wrote: Hello the official documentation for QFX5100, EX4600 and ACX5048 contains the following statement: https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/port-panel-qfx5100-48S.html "Caution: Do not place a copper transceiver in an access port directly above or below another copper transceiver. Internal damage to the access ports and switch can occur. We recommend either using the top port row exclusively, or bottom port row exclusively, for copper transceivers." Does this apply only to Direct Attach Cables or copper SFP modules oder both? This is potentially a big thing for us since we would like to use copper SFP modules on some of our devices. 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
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] 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] 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 <aar...@gvtc.com> 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 <karl_g...@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@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
[j-nsp] About MX960
We took possession of 2 MX960 yesterday. That is all =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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper M120 - SSD Replacement
Hi, I'm guessing juniper's are over priced? I have yet to yank mine from our MX240 demo to see if a generic one would suffice... - 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 05/01/18 12:05, Juan C. Crespo R. wrote: Hello Guys Could you please tell me a good SSD replacement for this Routing Engine (RE-A-2000)?? thanks ___ 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] MX104 and NetFlow - Any horror story to share?
Hi, Anyone has any horror stories with something similar to what we're about to do? We're planning to turn up the following Netflow config (see below) on our MX104s (while we wait for our new MX960 =D), it worked well with everything else (SRX mostly), the "*s**et chassis"* are making us wonder how high would be the possibility to render those system unstable, at short and long term. Thanks again for your time. PS: We're using Elastiflow, and its working great for our needs atm. -- A bit of context Model: mx104 Junos: 16.1R4-S1.3 They're routing about 20Gbps atm, with 5 full tables peers, ~0.20 load average, and 700MB mem free. -- The Netflow config *set chassis tfeb0 slot 0 sampling-instance NETFLOW-SI* *set chassis fpc 1 sampling-instance NETFLOW-SI* set services flow-monitoring version9 template FM-V9 option-refresh-rate seconds 25 set services flow-monitoring version9 template FM-V9 template-refresh-rate seconds 15 set services flow-monitoring version9 template FM-V9 ipv4-template set forwarding-options sampling instance NETFLOW-SI input rate 1 run-length 0 set forwarding-options sampling instance NETFLOW-SI family inet output flow-server port 2055 set forwarding-options sampling instance NETFLOW-SI family inet output flow-server source set forwarding-options sampling instance NETFLOW-SI family inet output flow-server version9 template FM-V9 set forwarding-options sampling instance NETFLOW-SI family inet output inline-jflow source-address set interfaces unit family inet sampling input set interfaces unit family inet sampling output ----- 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 04/30/18 10:34, Brijesh Patel wrote: Hello Members, Any idea what is Difference between MPC4E-3D-32XGE-RB and MPC4E-3D-32XGE-SFPP ? Juniper PDf says : MPC4E-3D-32XGE-SFPP 32x10GbE, full scale L2/L2.5 and *reduced scale L3 features* and MPC4E-3D-32XGE-RB 32XGbE SFPP ports, full scale L2/L2.5, * L3 and L3VPN features* now question is *what is reduced scale L3 featurs and L3vpn features ?* *Many Thanks,* *Brijesh Patel* ___ 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] l2circuit down one side/up another
Well, IS-IS or OSPF? Q: And don't you need at least RSVP for the LDP signaling? But since he didn't change nothing beside the L2 switches... Not relevant (maybe). I had a hard time passing IS-IS thru Extreme Switch, give up after 5m and used OSPF for that segment of our Pre-Prod Lab. ( Since its only for a redundant MX it don't matter much to perfectly match Prod for that part ) - 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/20/17 10:39, Caio wrote: *Did you change any of the physical interfaces as part of your topology change? And if so, is family mpls configured on that new port? Is that new port configured under protocols ldp and protocols mpls along with the loopback used for signaling? * No. Both of the MX routers are using the same interfaces. The only thing that has changed was the switches (l2 path) between them. *Do your control plane filters still permit ldp on both ends*? Yes Cheers, Caio Em 20 de out de 2017 11:12 AM, "Daniel Rohan" <dro...@gmail.com> escreveu: Did you change any of the physical interfaces as part of your topology change? And if so, is family mpls configured on that new port? Is that new port configured under protocols ldp and protocols mpls along with the loopback used for signaling? Do your control plane filters still permit ldp on both ends? Dan On Fri, Oct 20, 2017 at 3:26 AM Caio <cai...@gmail.com> wrote: Hello people, There's a weird problem I would like to share with you. I have the following scenario: MX104 -> L2 SW (1) -> L2 SW (2) -> MX80 Both L2 SW are Extreme X460 and they're doing nothing except forwarding frames at layer 2. In order to simplify our topology, we have changed the MX104 uplink to L2 SW (2) so the topology went to MX104 -> L2 SW (2) -> MX80. After that, the BGP sessions went up and all the traffic has returned as expected, however I have three l2circuit connections (vlan-ccc mode) and they went to "Down (OL)" status at one side and Up at another. In order to reestablish them we had to do a rollback of the physical changes we did. As it just don't make any sense to me, I summon you experts to help me with that, so we can try to figure out what went wrong. Additional details: I'm using LDP signaling at both sides. It' a point to point L3 connection, so I have the loopback interfaces configured at both sides and a /30 between them, also I have static routes to reach their loopback interface's addresses. Any help will be appreciated. Cheers, Caio ___ 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] l2circuit down one side/up another
Alphabet soup mistake =D. I never had a need for LDP alone. - 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/20/17 11:17, Aaron Gould wrote: Why would you need rsvp for ldp ? I don't think they have dependency on each other... As I understand it, you can use RSVP for label advertisement, OR, you can use LDP for label advertisement. They are alternatives to each other. -Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Meltdown and Spectre
If someone can sniff your authentication... You're in deep trouble. Also for 2018, about dropping using whataboutdisms. It is clear that those, oddly timed, flaws do not affect properly configured JNP devices. - 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 01/08/18 12:11, Chuck Anderson wrote: Umm, you type the password into the box, right? The box stores that password in memory so that it can build a TACACS+ request packet to send to the server? Unless you are using SSH keys in lieu of passwords. On Mon, Jan 08, 2018 at 05:16:01PM +0100, Sebastian Becker wrote: The password will not be seen on the box itself so no problem. The users are tacacs+ authorized/authenticated. Most scenarios are much easier to accomplish by using the already granted rights on the boxes per user then using these kinds of attack vectors opened by Meltdown and Spectre. Our boxes simply do not run other code than that what is delivered by the vendors. — Sebastian Becker s...@lab.dtag.de Am 08.01.2018 um 09:32 schrieb Thilo Bangert <thilo.bang...@gmail.com>: Den 06-01-2018 kl. 19:49 skrev Sebastian Becker: Same here. User that have access are implicit trusted. You do have individual user accounts on the equipment, right? The idea of having secure individual logins goes down the drain with Meltdown and Spectre. You want to be sure that a person logged into a box cannot snoop the password of a co-worker. Meltdown and Spectre are relevant on all affected computing equipment. So no need for panic. The usefulness of panic has been degrading the past couple of thousand years ;-) ___ 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] Experience with MX10003
Hi, After the bad experience with the QFX5100, now our rep is pushing for MX10003 instead of MX960. While its half the routing (10T versus 4T), at 1/2 the price, and a barely 3U in space, for the same chipset (coming from the sales guy). Anything ring thru? Or we're going to be just another bunch of crash test dummies for Juniper to test this new platform? Thanks for your time. -- - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX300 - How much MPLS can be done with that platform?
Curious to know. The commands are there... Most of the things seems functional up to LDP. Have a good day. -- - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX300 - How much MPLS can be done with that platform?
Well... Quick test with iperf v2. [ 3] 0.0-10.0 sec 1000 MBytes 839 Mbits/sec On ge-0/0/3 right now =D - set version 15.1X49-D140.2 set system host-name SITEA set system time-zone America/Toronto set system root-authentication encrypted-password "$5$Pp.xrsCy$38kIaR9FL8FFwOn.KBDPYJOPLpReC906HV7GyKhNKG1" set system name-server 8.8.8.8 set system name-server 8.8.4.4 set system login user calgah uid 2000 set system login user calgah class super-user set system login user calgah authentication encrypted-password "$5$6zYw7nsI$vk6zsBQ.ZsXGOx4xNuls9kw5LAfVyooF4sXgN/hKzQ7" set system services ssh set system services netconf ssh set system services dhcp-local-server group jdhcp-group interface irb.0 set system syslog archive size 100k set system syslog archive files 3 set system syslog user * any emergency set system syslog file messages any notice set system syslog file messages authorization info set system syslog file interactive-commands interactive-commands any set system max-configurations-on-flash 5 set system max-configuration-rollbacks 5 set system license autoupdate url https://ae1.juniper.net/junos/key_retrieval deactivate system license set security forwarding-options family inet6 mode packet-based set security forwarding-options family mpls mode packet-based set security forwarding-options family iso mode packet-based set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.220/24 set interfaces ge-0/0/2 description Customers set interfaces ge-0/0/2 flexible-vlan-tagging set interfaces ge-0/0/2 encapsulation flexible-ethernet-services set interfaces ge-0/0/2 unit 100 encapsulation vlan-ccc set interfaces ge-0/0/2 unit 100 vlan-id 100 set interfaces ge-0/0/2 unit 200 encapsulation vlan-ccc set interfaces ge-0/0/2 unit 200 vlan-id 200 set interfaces ge-0/0/3 description Eth-CCC set interfaces ge-0/0/3 encapsulation ethernet-ccc set interfaces ge-0/0/3 unit 0 family ccc set interfaces ge-0/0/4 description MPLS_Path_A set interfaces ge-0/0/4 unit 0 family inet address 10.10.10.2/31 set interfaces ge-0/0/4 unit 0 family iso set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 description MPLS_Path_B set interfaces ge-0/0/5 unit 0 family inet address 10.10.11.2/31 set interfaces ge-0/0/5 unit 0 family iso set interfaces ge-0/0/5 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.0.0.1/32 set interfaces lo0 unit 0 family iso address 49.0004.1000..0001.00 set interfaces lo0 unit 0 family mpls set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/4.0 set protocols rsvp interface ge-0/0/5.0 set protocols mpls interface lo0.0 set protocols mpls interface ge-0/0/4.0 set protocols mpls interface ge-0/0/5.0 set protocols isis interface ge-0/0/4.0 level 1 hello-authentication-key "$9$2SgGiPfz6CuQFWL" set protocols isis interface ge-0/0/4.0 level 1 hello-authentication-type simple set protocols isis interface ge-0/0/5.0 level 1 hello-authentication-key "$9$gL4UHf5F/A0z3" set protocols isis interface ge-0/0/5.0 level 1 hello-authentication-type simple set protocols isis interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 set protocols ldp interface ge-0/0/4.0 set protocols ldp interface ge-0/0/5.0 set protocols ldp interface lo0.0 set protocols l2circuit neighbor 10.0.0.2 interface ge-0/0/2.100 virtual-circuit-id 100 set protocols l2circuit neighbor 10.0.0.2 interface ge-0/0/2.100 no-control-word set protocols l2circuit neighbor 10.0.0.2 interface ge-0/0/2.200 virtual-circuit-id 200 set protocols l2circuit neighbor 10.0.0.2 interface ge-0/0/2.200 no-control-word set protocols l2circuit neighbor 10.0.0.2 interface ge-0/0/3.0 virtual-circuit-id 300 set protocols l2circuit neighbor 10.0.0.2 interface ge-0/0/3.0 no-control-word - 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 08/24/18 14:09, Aaron Gould wrote: Is that true? I was wondering if stateful mode does no mpls at all. I was recently wondering if I could use a Juniper SRX firewall in its purest firewall form, I think known as stateful mode, with MPLS encapsulation and services terminating directly inside of the SRX Let me know , thanks Aaron On Aug 24, 2018, at 10:12 AM, Pavel Lunin wrote: In stateless mode — as much as the cpus and ram can accommodate. Performance and scaling should be somewhat near the IP packet-mode numbers, and most major features are there. In stateful mode — zero, if I didn't miss something. пт, 24 авг. 2018 г., 16:31 Alain Hebert : Curious to know. The commands are there... Most of the things seems functional up to LDP. Have a good day. -- - Alain Hebert
Re: [j-nsp] QFX5110 : Q-in-Q in VXLAN
Hi, On QFX5100 the L2TP/Q-in-Q services has limitations. I have to dig through my pile of tickets for details... but I remember something about PVST+ packets not being forwarded at all. So we just switched everything to MPLS/l2circuits/VLAN CCC (for now) instead of battling with the QFX5100 platforms. We'll deploy EVPN/VXLAN to our customers once we find a solution but we're not in a rush. PS: I heard a rumor that there is a fix in 18.x for the QFX5100... To note that the QFX5110 platform do not seem to be suffering from the same issues... I suggest to get a demo to confirm the functionality. - 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 09/10/18 17:20, Pavel Lunin wrote: Hey, The Q-in-Q encapsulation comes from the EX2300 switches to the QFX switches (the S-VLAN Q-in-Q tag is also 1001), but on the other end of the tunnel we don't have the Q-in-Q frames coming. I am curious if the packets don't leave the ingress VTEP at all or the tail-end VTEP can't treat them. "ping -f -s 1000" and "monitor interface traffic" can help to figure out where the packets are dropped. And if the VXLAN packets leave the core-facing interface of the ingress VTEP, I'd suggest to put a sniffer in the middle and take a look at the packets closely. Not that I am sure that it will work but... Juniper explicitly says that it's supported on all Trident2/2+/3-based switches in the very very fresh JUNOS (make sure that you don't miss this point). I suspect that it's not a honest Q-in-Q-in-VXLAN but some cheating, e. g. pop the VLAN tags and push them back on the other side, while VXLAN tunnel carries untagged / single-tagged frames. (Yes this requires per-vlan tunnels and might not work for your need). This is how VLAN-based Martini pseudowires work on those switches (even on EX4550, if memory serves). It's officially supported in EX-to-EX/QFX-to-QFX mode, where it works out-of-the-box, while in case where you have an MX-like router on the other end, you need to manually push/pop VLAN tags and disable control-word on the MX side (discussed many times in this list). -- Pavel ___ 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] Juniper annoyance... Migration from MX104 to MX960 - inet6 lo0 firewall issue
Pretty basic box (beside boost in capacity and REs). MX104 - Junos: 16.1R4-S1.3 MX960 - Junos: 16.1R7.7 And yet the same "firewall family inet6" "lo0.0 family inet6 filter-list [ ... ]" from the MX104 refuse to work on the MX960... I have yet to find the hidden knot from Juniper about the MX960 and RE protect firewalling for inet6. PS: Works without issue for IPv4. Any hints? -- - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper annoyance... Migration from MX104 to MX960 - inet6 lo0 firewall issue
Y'all can safely ignore that. Someone punched in a lo0.1 without inet6 input-filter and it was bypassing it through a routing-instance which was unused. PS: Diogo, yeah did all that nice stuff while scratching my head for an hour until I noticed someone had fat fingers. Thx for the follow up. - 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 07/09/18 15:58, Alain Hebert wrote: Pretty basic box (beside boost in capacity and REs). MX104 - Junos: 16.1R4-S1.3 MX960 - Junos: 16.1R7.7 And yet the same "firewall family inet6" "lo0.0 family inet6 filter-list [ ... ]" from the MX104 refuse to work on the MX960... I have yet to find the hidden knot from Juniper about the MX960 and RE protect firewalling for inet6. PS: Works without issue for IPv4. Any hints? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU issue
Well, We had the same issue when switching one of our so called "wavelength" from L2 (1536) to MPLS/Jumbo (9216). After the usual Level 1 incompetence, we got tired and asked to bumped it to engineering, we found out they had some active booster that had a limitation of 2000 bytes per packet. There was an active/passive MUX, from FS.com, that created some headache for us too... ----- 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/22/18 16:21, john doe wrote: I talked to my supplier and they say that there is no MTU settings or limitations on their wavelength service. I have other wavelengths from the same supplier that works as expected so maybe it's not on their end. Johan On Mon, Oct 22, 2018 at 8:10 AM Mikael Abrahamsson wrote: On Mon, 22 Oct 2018, john doe wrote: The setup is a Cisco on one side and a MX one the other. Between them are a 10G wavelength. MPLS, RSVP is running and the ERO of my LSP is taking the What could cause the Low MTU? My guess is that it's actually not a "wavelength" but someones packet network in between and they're just calling it a "wavelength". So call the "wavelength" provider and ask them what MTU they support. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] QFX5100 red alarm after power-off
Then you should open a ticket with the JTAC. - 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 2/14/19 11:57 AM, Giovanni Bellac via juniper-nsp wrote: Hi, it matters for us, because I want to know the root cause of the red alarm LED when powering it down with an enabled management port. Kind regards Am Donnerstag, 14. Februar 2019, 13:12:13 MEZ hat Anderson, Charles R Folgendes geschrieben: Why does it matter since the switch is halted/powered off anyway? On Thu, Feb 14, 2019 at 08:31:43AM +, Giovanni Bellac via juniper-nsp wrote: Hi, we are issuing the command (request system power-off) when the switch is booted up normally. We are experiencing this on different JunOS versions (14.1, 17.3, 18.1). From our last email: Short update:We experiencing the red alarm only when the management port is connected when powering off the QFX5100-48T - weird...When the management port is not connected when powering down the device, there is no red alarm. Kind regards Am Mittwoch, 13. Februar 2019, 16:22:59 MEZ hat Anderson, Charles R Folgendes geschrieben: On Wed, Feb 13, 2019 at 11:08:16AM +, Giovanni Bellac via juniper-nsp wrote: after powering off a QFX5100-48T (request system power-off) the fans are spinning down and the ALARM LED is lightning red. The switch is working and looking as expected without any error messages. Is this a normal behavior ? Has someone a spare unit for a short test ? ___ 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] l2circuit between QFX-5110 & MX204 - one way traffic
Here is an production version (thx Phil) but on QFX-5100 and MX960
(and MX104 before).
This works for about 200ish circuits so far...
We had a bunch of issue with those which can lead to unresponsive
interface... So depending on your situation you may have to reboot the
switch :(
xe- {
description
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
description
encapsulation vlan-ccc;
no-traps;
vlan-id 123;
input-vlan-map pop;
output-vlan-map push;
}
interface xe-.123 {
virtual-circuit-id 123456;
description
no-control-word;
mtu 9000;
}
-
Alain hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911http://www.pubnix.net Fax: 514-990-9443
On 2019-07-18 10:02, Heng Chai, Tan wrote:
Try below on QFX5110 terminating l2circuit. Last I remember the
flexible-vlan-tagging + flexible-ethernet-services behaves oddly on
the QFX5110.
delete interfaces xe-0/0/9 flexible-vlan-tagging
set interfaces xe-0/0/9 vlan-tagging
set interfaces xe-0/0/9 encapsulation vlan-ccc
Heng Chai, Tan
On 18-07-19 9:48 PM, Liam Farr wrote:
Hi,
Not sure if I'm "doing the dumb" or Junos bug or limitation of the QFX /
Trident 2+ chip-set.
Trying to do a basic l2circuit as follows
VLAN Tagged Interface > MX204 l2circuit / ldp > QFX-5110 / ldp >
QFX-5110
l2circuit / ldp > VLAN Tagged Interface
What I am seeing is traffic going Test Device > QFX-5110 > QFX-5110 >
MX204
Test Device arrives fine.
Return path from Test Device > MX204 > QFX-5110 > QFX-5110 > Test
Device is
broken.
Config is as follows
*MX204 Port facing test device on VLAN tag 123*
liam@WN-MX204-1# show interfaces xe-0/1/3
description "WN-PVE-1 C0/F3 enp6s0f1";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
MPLS port facing intermediate / transit QFX (MS)
liam@WN-MX204-1# show interfaces xe-0/1/1
description "OTN MS";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.2/30;
}
family mpls;
}
liam@WN-MX204-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.3/32;
}
}
liam@WN-MX204-1# show protocols l2circuit
neighbor 192.168.68.5 {
interface xe-0/1/3.123 {
virtual-circuit-id 123;
control-word;
encapsulation-type ethernet-vlan;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@WN-MX204-1# show protocols ldp
interface xe-0/1/1.0;
interface lo0.0;
liam@WN-MX204-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
label-switched-path wn-mx-to-na-qfx-test {
from 192.168.68.3;
to 192.168.68.5;
adaptive;
fast-reroute;
primary anypath;
}
path anypath;
interface xe-0/1/1.0;
liam@WN-MX204-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface fxp0.0 {
disable;
}
interface xe-0/1/0.549 {
interface-type p2p;
}
interface xe-0/1/1.0 {
interface-type p2p;
}
}
*Intermediate / transit QFX*, MPLS interface facing MX204
liam@MS-QFX5110-1# show interfaces xe-0/0/1
description "OTN MS-WN";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.1/30;
}
family mpls;
}
Interface facing destination QFX
liam@MS-QFX5110-1# show interfaces xe-0/0/0
description "OTN MS-NA";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.5/30;
}
family mpls;
}
liam@MS-QFX5110-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.6/32;
}
}
liam@MS-QFX5110-1# show protocols ldp
interface xe-0/0/0.0;
interface xe-0/0/1.0;
interface lo0.0;
liam@MS-QFX5110-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
path anypath;
interface xe-0/0/0.0;
interface xe-0/0/1.0;
liam@MS-QFX5110-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface vme.0 {
disable;
}
interface xe-0/0/0.0 {
interface-type p2p;
}
interface xe-0/0/1.0 {
interface-type p2p;
}
}
*Destination QFX / other end of l2circuit*, interfacing test
equipment on
vlan 123
liam@NA-QFX5110-1# show interfaces xe-0/0/9
description "Temp Link to Arista";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
Interface facing intermediate / transit QFX
liam@NA-QFX5110-1# show interfaces xe-0/0/1
description "OTN NA-MS";
mtu 9216;
unit 0 {
family inet {
Re: [j-nsp] EX2300 Code
Well, Our RMA experience with those model is not great... good luck =D. PS: JTAC made us got down to 15.1X53-D592.1 after several issues of port being stuck open (STP) and looping our OOB Management :( - 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 2019-12-09 06:15, William wrote: Hi, I am in the process of getting our first stack of EX2300s ready for production, can anyone recommend any specific versions of junos to run on them? I'm not taking advantage of any advance features, just after something stable :) Cheers, William ___ 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] Managing MX480 fxp0
Hi, How wrong we where doing that with our MX960, QFX5100, and a few MX104 =D. One of our OOB is a bunch of EX2300 switches using STP, on a different set of dark fiber linking a few Metro data centers together... but as usual with JNP... one went nuts and started spewing packets from the other link while shifting left a few bytes. When those packets hit our fpx0s, dos protect did all and killed their CPU dropping everything BGP and MPLS (thx JNP) on most routers connected to the OOB network. Now, at each site, we have a mini putter (Lenovo/Zotac/etc) with SSD, Sealink serial ports, Consumer xDSL/Coax, MFA encrypted VPN. We enable fxp0 *if* needed... Other things to think about: 1. We're even looking at swapping to Cisco L2 switches instead of JNPs, since this type of event never happened, in our collective experience, with that brand. 2. Using OSPF3 (or IS-IS to limit OSPF injection) would have limit the fpx0 DoS to the local OOB switch... Which is still too risky for our taste. 3. You could use Serial->Ethernet devices instead of the Sealink but if the OOB switch goes down again, you cannot access the serials. PS: In our case it is our fiber bundles and we didn't need to invest in DWDM ... but its the same idea. For years an associate of mine implemented a very large deployment of OOB over DWDM and Cisco L2 switches with 0 downtime. Have fun and good luck. ----- 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 2019-11-26 06:09, Sander Steffann wrote: Hi, I would personally not wire or use fxp0 unless I'm out of options. Some other vendors today have real out-of-band ethernet for MGMT, meaning own CPU, own memory, own OS not fate-sharing the control-plane, which is the correct solution for OOB, but not something we as a community are actively asking vendors to deliver. We built an OOB network exactly like that. Cheap L3 switches talking OSPF to each other over their own 1G DWDM channels, completely independent of the production network. A separate OOB network used to be crazy expensive, but with cheap DWDM gear suddenly all you need is a free DWDM channel and some cheap second hand L3 switches. And that's what we connect our fxp0 ports to. Cheers, Sander ___ 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] Any red flags on this MX240 configuration...
Beside the RE-S-2000-4096-S being EOL. My experience with 16.2 was pretty solid. We're planning to have 3 Full Routes BGP and the MPLS alphabet soup, yadi yada. We don't want 2 RE since we'll use 2 MX240 and there is no point to go for ISSU since the RE is EOL. 1x CHAS-BP-MX240-S 1x FFANTRAY-MX240-HC 1x RE-S-2000-4096-S 1x SCBE-MX-S 2x PWR-MX480-1200-AC 1x MPC-3D-16XGE-SFPP -- - 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
Hi,
IMHO,
Directly on the interface permit to use plugins in Elastiflow
(example) to highlight odd traffic behavior (Scans/DDoS)
-
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 2020-04-08 08:56, Mark Tinka wrote:
On 8/Apr/20 14:51, Mark Tinka wrote:
Looks good.
The only other thing I would do different is to sample directly on the
interface, rather than through a firewall filter:
xe-0/1/0 {
unit 0 {
family inet {
sampling {
input;
output;
}
family inet6 {
sampling {
input;
output;
}
}
}
But either works. Just haven't sampled in firewall filters for some time
now.
___
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] Junos OS Evolved
I haven't unpackaged an Evolved distribution yet, but my experience with WindRiver licensing back in early 2000, it would be pricey. As for FreeBSD, they could have gone the way of upgrading the kernel (I saw some evidences about 10.x but no confirmation yet) but depending of their initial work done during the 4.x days, switching might have been a better financial choice. Device support wouldn't be an issue pretty much all the worthy stuff works on both... and with virtualization its not an really issue anymore. - 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 2020-10-13 13:22, Chris Adams wrote: Once upon a time, Alain Hebert said: Since most of the reference implementation from their ASIC provider with be Linux based ... the path of least resistance wins. This is on the RE, which is just standard Intel x86 stuff (or IIRC ARM for smaller stuff?). And, I think, the "preference" of the majority of their own devs/mgmt which never knew nothing but Linux =D. I think with FreeBSD-based Junos, Juniper forked their chosen FreeBSD release and made a bunch of customizations. That means every time they need to get to newer FreeBSD (for newer hardware support, newer features, etc.), it is a major operation. With Junos Evolved, it sounds like they're going with somebody else's distribution (Wind River) and adapting to fit it. Then when they need new support, they just get the latest release and go (somebody else does all the hardware work). It's my understand that the Linux kernel tends to have broader support for new hardware than the FreeBSD kernel, but I haven't really looked in a long time (I run Linux, not FreeBSD, so I could be wrong). ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos OS Evolved
Nice another round of customers doing JNP QA :( - 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 2020-10-09 12:38, Saku Ytti wrote: Hey Colton, I was unaware of Junos OS Evolved until recently. At what version did regular Junos evolve into Junos OS Evolved? Is there a certain version where after that version, everything ongoing is Junos OS Evolved? I think EVO appeared in 19.1, but in most cases you don't have a choice, you either install classic or you install evo. New platforms already only have EVO options and older platforms only have classic options. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos OS Evolved
Well this is coming from my experience with QFX5100, less of an issue with MX platforms but still for the price tag it was kinda hellish. Been stable after we worked some of the pitfalls... still got some chipset related issue when someone makes an error and mix L2 VLANs with VLAN-CCC on the same interface. Nothing like 3 lvl of peer review cannot fix. - 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 2020-10-09 13:00, Jared Mauch wrote: Like many things either it works or it doesn't. I'm not a fan of paying for software with bugs personally. We do have Evo in use. Sent from my iCar On Oct 9, 2020, at 12:55 PM, Alain Hebert wrote: Nice another round of customers doing JNP QA :( - 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 2020-10-09 12:38, Saku Ytti wrote: Hey Colton, I was unaware of Junos OS Evolved until recently. At what version did regular Junos evolve into Junos OS Evolved? Is there a certain version where after that version, everything ongoing is Junos OS Evolved? I think EVO appeared in 19.1, but in most cases you don't have a choice, you either install classic or you install evo. New platforms already only have EVO options and older platforms only have classic options. ___ 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] Junos OS Evolved
Since most of the reference implementation from their ASIC provider with be Linux based ... the path of least resistance wins. And, I think, the "preference" of the majority of their own devs/mgmt which never knew nothing but Linux =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 2020-10-11 07:04, Gavin Henry wrote: Whats its history? (will Google it too) I mean, from a software engineering point if view, it's a tough call to start again. ___ 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] Looking for Hints: Best Practices to PUSH prefix-list on MX platform with 16.x and UP
Context I'm looking for a *simple* & safe way to manage daily IRR changes from my customers... Right now its a simple script that push changes using command lines thru SSH... While it is working adequately, I wonder how long it will be feasible =D with the current growth. Solution As for there REST API, I remember someone having some issues where the RE keep rebooting and took down their entire OP for a few hours... . Anyone can testify on the solidity of their RESTful API? . Should we bump up the production version to something newer? PS: Security wise we're fine, anything related to management is tightly pinned to a OOB with MFA and high encryption =D. Thanks for your time. -- ----- 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Test Labs
Yeah, We (and some of my customers CTOs) always created parallel Labs. If you think about it, you *should* already have the spare parts required for production, using them in the Lab enabled us to insure: . They are in working condition; . They are readily available to provision production/bootstrap configuration in case of emergency; . We won't take down our world while goofing around =D. ( Yes, we do not have a complete MX960 in the lab... But we're running an older MX240, or MX104, yadi yada ) - Alain hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911http://www.pubnix.net Fax: 514-990-9443 On 11/3/21 11:53, harbor235 via juniper-nsp wrote: Hi all, Anybody out there integrating production environments (real-time service delivery), test, and development labs into a single architecture? I do not like this idea if it is avoidable. I understand supposed savings, but the cost of an unplanned event negates the implied savings. thoughts? Mike ___ juniper-nsp mailing listjuniper-...@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] upgrading an antique 240
Boot using a USB key and the proper image. junos-install-media-usb-mx-x86-32-16.2R2.8.img Upgraded a RE-S-2000 engine from 11.x to 16.2. - 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 7/15/21 5:31 PM, David Kotlerewsky via juniper-nsp wrote: See the doc here: https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/16.2/topic-113674.html Please note the very important info below: Support for upgrades and downgrades that span more than three Junos OS releases at a time is not provided, except for releases that are designated as Extended End-of-Life (EEOL) releases. EEOL releases provide direct upgrade and downgrade paths—you can upgrade directly from one EEOL release to the next EEOL release even though EEOL releases generally occur in increments beyond three releases. You can upgrade or downgrade to the EEOL release that occurs directly before or after the currently installed EEOL release, or to two EEOL releases before or after. For example, Junos OS Releases 14.1, 14.2, 15.1 and 16.1 are EEOL releases. You can upgrade from Junos OS Release 14.1 to Release 15.1 or even from Junos OS Release 14.1 to Release 16.1. However, you cannot upgrade directly from a non-EEOL release that is more than three releases ahead or behind. To upgrade or downgrade from a non-EEOL release to a release more than three releases before or after, first upgrade to the next EEOL release and then upgrade or downgrade from that EEOL release to your target release. For more information about EEOL releases and to review a list of EEOL releases, see https://www.juniper.net/support/eol/junos.html. Sounds like you’ll need to go to 15.1, then 16.1, then 16.2. From: Randy Bush Date: Thursday, July 15, 2021 at 1:46 PM To: David Kotlerewsky Cc: heasley , Juniper List Subject: Re: [j-nsp] upgrading an antique 240 Good point! TSB16735 says last version of Junos to support SCB-MX960 is 16.2 Junos 17.3R3-S10 Junos 18.4R2-S5 Junos 19.3R3-S2 Junos 19.4R3-S3 so which steps to get from 14 to 16.2? 15.x 16.2? randy ___ 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] MX960 PEMs and 3 phase power
Depending of your setup, all our COs are setup to provides A+B feed. Which include TS, UPS and Bypass. PS: Be sure to test before putting it in production, the PEM #, and its assignment into the chassis, are not that straight forward. - Alain hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911http://www.pubnix.net Fax: 514-990-9443 On 3/22/23 11:27, Tom Storey via juniper-nsp wrote: Hi all. I had this idea in my head that MX960 power supplies should not be split across phases, but I cant find anything in any documentation that says that. Can anyone comment on whether multiple phases per PEM are supported, or whether its even a reasonable idea to put into practice? My thought is one PEM on one phase, such that if that phase drops, you drop that PEM entirely. Or is it worthwhile spreading across phases to keep even half of a PEM alive and supplying the chassis? Thanks ___ juniper-nsp mailing listjuniper-...@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
