Re: [j-nsp] SRX: rate-limiting source NAT sources
You can limit flows per individual source IP (not NAT ports) using UTM https://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configuration-statement/security-edit-limit.html You'll need a UTM license. And if you are doing NAT on branch SRX, UTM is supported only on high-memory branch SRX boxes. Thanks Alex - Original Message - From: Jonathan Lassoff j...@thejof.com To: juniper-nsp@puck.nether.net Sent: Monday, October 29, 2012 9:55 PM Subject: [j-nsp] SRX: rate-limiting source NAT sources So, I'm working on tuning an SRX deployment and am wondering if something is possible. This deployment is doing a lot of source NAT for a wide variety of endpoints as they egress out to the Internet. Pretty vanilla configuration. Specific sources are mapped via NAT rules to specific egress IPs (for IP filtering in some places, outside of the SRXes in question). And once in a while, some endpoint will have a legitimate need to open up *many* connections (and then NAT states) that pass over this SRX deployment. Unfortunately, the rate of connection establishment relative to the application timeouts means that these heavy users can use up all of the ephemeral ports, blocking new flows from becoming established. We've been playing a bit of whack-a-mole, assigning more IP space to the various source NAT pools, but would like to find a more proper solution. So, my question is this: is there any mechanism anyone knows of to rate-limit or block-past-a-threshold a source NAT source if it starts making too many connections? I don't see anything obvious in the SRX documentation, so I figured I'd ask here for pointers. Right now, it's way to easy for one bad actor (malicious or benevolent) to max out a source NAT pool. Cheers, jof ___ 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] VPLS design - dual homed
Are those four MX your PE routers? Does your CE devices connect to one or two PE routers? I have a question regarding dual VPLS links. My topology will look like this: MX1-darkfibre--MX2 | | | | MX3-darkfibre--MX4 So above you see that there are dual links which will create a loop. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Security bugs in documentation
Yes, documentation itself maybe be a security risk... I am more than a bit pissed after attemting to view http://www.juniper.net/techpubs/en_US/junos12.2/information-products/topic-collections/config-guide-firewall-filter/config-guide-firewall-policer.pdf Using an open source viewer, all I see in that document is a single page displaying For the best experience, open this PDF portfolio in Acrobat 9 or Adobe Reader 9, or later. and a link to Get Adobe Reader Now!. And sure enough, inspecting the pdf shows that it is a 5MB single page document: bjorn@nemi:~/tmp$ pdfinfo config-guide-firewall-policer.pdf Title: Firewall Filter and Policer Configuration Guide Author: Juniper Networks Creator:Adobe Acrobat Pro 9.3.0 Producer: Adobe Acrobat Pro 9.3.0 CreationDate: Fri Jul 6 16:05:23 2012 ModDate:Fri Jul 6 16:07:53 2012 Tagged: yes Pages: 1 Encrypted: no Page size: 504 x 360 pts File size: 5257154 bytes Optimized: no PDF version:1.7 Yes, I understand what is going on here and I DO NOT APPROVE. I considere the above a malicious attempt to force me to use software I do not want to use. It is no better than any other phishing attemt. I was wondering if I should open a case with JTAC for this, but I fear that would only be ignored. This really deserves public humiliation. So, please Juniper and others: Do not use any Abobe program ever. They are deliberately buggy like demonstrated above, creating faulty documents which can only be read by their own buggy readers. If you continue distributing your documentation infected by the Adobe phishing virus, then I will have to manage without your documentation. That's a pity, because I think it will make it very diffcult for me to work with any Juniper equipment. I am sure you can figure out where that is going to end. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Number of logical interfaces for EX switches
Thank yo very much! I have one more concern about scaling. What would be the maximum number Firewall Filter terms per system? I mean if I put several big prefix lists and apply an accept/drop actions on them will it be possible to have a total of a few thousand entries? Thanx in advance On Thu, Oct 18, 2012 at 2:57 AM, Jerry Jones jjo...@danrj.com wrote: Hi Emil, This will be different for each model. Most are in the 500 range per pre, some can do around 1k. Get hold of your Juniper SE and he can help you out with scaling questions. I would say most models are safe to 400, but over that you should verify and test. Good luck. On Oct 15, 2012, at 3:57 AM, Emil Katzarski ekatzar...@gmail.com wrote: Hi Troy, Unfortunately it is not so simple. There are 4096 VLAN IDs and you can create that many VLANs in the system doing L2 bridging on them. If it is possible to assign an operational IP interface on each of them is subject of availability of another resource called IFL's. I don't know how many IFL's are there in an EX3200. Anibody with an idea? On Fri, Oct 12, 2012 at 10:50 PM, Troy Coulombe tcoulo...@telecomsys.com wrote: Wouldn't it simply be the number of VLANs [4096 per the datasheet], although you can only configure 4094 per the CLI # set vlans test vlan-id ? Possible completions: vlan-id802.1q tag (1..4094) Or am I missing something ... Thanks, TroyC -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto: juniper-nsp-boun...@puck.nether.net] On Behalf Of Emil Katzarski Sent: Thursday, October 11, 2012 8:31 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Number of logical interfaces for EX switches Hi everybody, Can anyone help with finding some secret numbers about EX-series switches. I didn't find them in any document. What I need is the number of L3 interfaces (RVI and vlan tagging units) that can be used on a single system. The maximum unit number of the VLAN interface is about 16k but it doesn't mean anything. So if anybody knows what is tha maximum number of L3 interfaces per system for EX2200, EX3200, EX4200, EX4500 etc, please help. Kind regards: Emil Katzarski ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. ___ 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] VPLS design - dual homed
Yes, the MX routers are PE. CE devices at each end will be two EX4500 in VC mode. One connection from each EX to each MX. From: Per Granath [per.gran...@gcc.com.cy] Sent: Tuesday, 30 October 2012 8:46 PM To: Luca Salvatore; juniper-nsp@puck.nether.net Subject: RE: VPLS design - dual homed Are those four MX your PE routers? Does your CE devices connect to one or two PE routers? I have a question regarding dual VPLS links. My topology will look like this: MX1-darkfibre--MX2 | | | | MX3-darkfibre--MX4 So above you see that there are dual links which will create a loop. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Number of logical interfaces for EX switches
2200 hundreds 3300,4500 around a thousand 4200 thousands These should be safe, but again your SE can really help you out here. On Oct 30, 2012, at 5:36 AM, Emil Katzarski ekatzar...@gmail.com wrote: Thank yo very much! I have one more concern about scaling. What would be the maximum number Firewall Filter terms per system? I mean if I put several big prefix lists and apply an accept/drop actions on them will it be possible to have a total of a few thousand entries? Thanx in advance On Thu, Oct 18, 2012 at 2:57 AM, Jerry Jones jjo...@danrj.com wrote: Hi Emil, This will be different for each model. Most are in the 500 range per pre, some can do around 1k. Get hold of your Juniper SE and he can help you out with scaling questions. I would say most models are safe to 400, but over that you should verify and test. Good luck. On Oct 15, 2012, at 3:57 AM, Emil Katzarski ekatzar...@gmail.com wrote: Hi Troy, Unfortunately it is not so simple. There are 4096 VLAN IDs and you can create that many VLANs in the system doing L2 bridging on them. If it is possible to assign an operational IP interface on each of them is subject of availability of another resource called IFL's. I don't know how many IFL's are there in an EX3200. Anibody with an idea? On Fri, Oct 12, 2012 at 10:50 PM, Troy Coulombe tcoulo...@telecomsys.comwrote: Wouldn't it simply be the number of VLANs [4096 per the datasheet], although you can only configure 4094 per the CLI # set vlans test vlan-id ? Possible completions: vlan-id802.1q tag (1..4094) Or am I missing something ... Thanks, TroyC -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto: juniper-nsp-boun...@puck.nether.net] On Behalf Of Emil Katzarski Sent: Thursday, October 11, 2012 8:31 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Number of logical interfaces for EX switches Hi everybody, Can anyone help with finding some secret numbers about EX-series switches. I didn't find them in any document. What I need is the number of L3 interfaces (RVI and vlan tagging units) that can be used on a single system. The maximum unit number of the VLAN interface is about 16k but it doesn't mean anything. So if anybody knows what is tha maximum number of L3 interfaces per system for EX2200, EX3200, EX4200, EX4500 etc, please help. Kind regards: Emil Katzarski ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. ___ 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] LACP support on forwarding plane on M10i?
Is LACP supported on forwarding plane on M10i? According to Disabling Distributed Periodic Packet Management on the Packet Forwarding Engine(http://goo.gl/uDwYm) document LACP is supported on packet forwarding engine only on MX series. On the other hand, show pfe statistics traffic displays LACP under Packet Forwarding Engine local protocol statistics: root@M10i show pfe statistics traffic Packet Forwarding Engine traffic statistics: Input packets: 15819824321 pps Output packets: 13308609440 pps Packet Forwarding Engine local traffic statistics: Local packets input : 13846116 Local packets output: 5817751 Software input control plane drops :0 Software input high drops :0 Software input medium drops : 6108913 Software input low drops:0 Software output drops : 2049 Hardware input drops:201244886 Packet Forwarding Engine local protocol statistics: HDLC keepalives:0 ATM OAM:0 Frame Relay LMI:0 PPP LCP/NCP:0 OSPF hello :0 OSPF3 hello:0 RSVP hello :0 LDP hello : 217 BFD: 3502848 IS-IS IIH : 140750 LACP : 564573 ARP:40358 ETHER OAM :0 Unknown:0 Packet Forwarding Engine hardware discard statistics: Timeout:0 Truncated key :0 Bits to test :0 Data error :0 Stack underflow:0 Stack overflow :0 Normal discard : 15337489 Extended discard :0 Invalid interface :0 Info cell drops:0 Fabric drops :0 Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU Error statistics: Input Checksum : 707 Output MTU :0 root@M10i regards, martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LACP support on forwarding plane on M10i?
Hello, Not supported. You can see LACP packets punted to the RE if you use monitor trafic interface xxx or if you check ppm remote adjacencies there is no LACP adj up at PFE level : show ppm adjacencies remote (hidden cmd) For exemple on MX you have LACP distributed at PFE : mymx@mx show ppm adjacencies remote Protocol Hold time (msec) LACP 3000 LACP 3000 LACP 3000 LACP 3000 LACP 3000 LACP 3000 LACP 3000 LFM300 David David Roy IP/MPLS Support engineer - Orange France Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13 david@orange.com JNCIE-MT/SP #703 - JNCIE-ENT #305 - JNCIP-SEC -Message d'origine- De : juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] De la part de Martin T Envoyé : mardi 30 octobre 2012 16:16 À : juniper-nsp@puck.nether.net Objet : [j-nsp] LACP support on forwarding plane on M10i? Is LACP supported on forwarding plane on M10i? According to Disabling Distributed Periodic Packet Management on the Packet Forwarding Engine(http://goo.gl/uDwYm) document LACP is supported on packet forwarding engine only on MX series. On the other hand, show pfe statistics traffic displays LACP under Packet Forwarding Engine local protocol statistics: root@M10i show pfe statistics traffic Packet Forwarding Engine traffic statistics: Input packets: 15819824321 pps Output packets: 13308609440 pps Packet Forwarding Engine local traffic statistics: Local packets input : 13846116 Local packets output: 5817751 Software input control plane drops :0 Software input high drops :0 Software input medium drops : 6108913 Software input low drops:0 Software output drops : 2049 Hardware input drops:201244886 Packet Forwarding Engine local protocol statistics: HDLC keepalives:0 ATM OAM:0 Frame Relay LMI:0 PPP LCP/NCP:0 OSPF hello :0 OSPF3 hello:0 RSVP hello :0 LDP hello : 217 BFD: 3502848 IS-IS IIH : 140750 LACP : 564573 ARP:40358 ETHER OAM :0 Unknown:0 Packet Forwarding Engine hardware discard statistics: Timeout:0 Truncated key :0 Bits to test :0 Data error :0 Stack underflow:0 Stack overflow :0 Normal discard : 15337489 Extended discard :0 Invalid interface :0 Info cell drops:0 Fabric drops :0 Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU Error statistics: Input Checksum : 707 Output MTU :0 root@M10i regards, martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ juniper-nsp mailing list
[j-nsp] understanding PFE Hardware input drops on M10i(CFEB, Internet Processor II)
Hi, Hardware input drops counter in show pfe statistics traffic output increases rapidly in case one floods router interface with small UDP datagrams. Software input medium drops counter increases as well. show pfe statistics traffic output can be seen below: root@M10i show pfe statistics traffic Packet Forwarding Engine traffic statistics: Input packets: 158758931965240 pps Output packets: 1330946214 771 pps Packet Forwarding Engine local traffic statistics: Local packets input : 14439730 Local packets output: 5902958 Software input control plane drops :0 Software input high drops :0 Software input medium drops : 6603218 Software input low drops:0 Software output drops : 2467 Hardware input drops:205506491 Packet Forwarding Engine local protocol statistics: HDLC keepalives:0 ATM OAM:0 Frame Relay LMI:0 PPP LCP/NCP:0 OSPF hello :0 OSPF3 hello:0 RSVP hello :0 LDP hello : 230 BFD: 3505972 IS-IS IIH : 140941 LACP : 566167 ARP:40372 ETHER OAM :0 Unknown:0 Packet Forwarding Engine hardware discard statistics: Timeout:0 Truncated key :0 Bits to test :0 Data error :0 Stack underflow:0 Stack overflow :0 Normal discard : 15382993 Extended discard :0 Invalid interface :0 Info cell drops:0 Fabric drops :0 Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU Error statistics: Input Checksum : 707 Output MTU :0 root@M10i As much as I have read various documents(for example http://www.gossamer-threads.com/lists/nsp/juniper/7292), this seems to be rather platform dependent. What does Hardware input drops mean on M10i with CFEB(Internet Processor II, FEB-M10i-M7i-S)? regards, martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LACP support on forwarding plane on M10i?
David, thank you for confirming this. There are indeed no remote PPM adjacencies: root@M10i show ppm adjacencies remote Adjacencies: 0, Remote adjacencies: 0 root@M10i regards, martin 2012/10/30, david@orange.com david@orange.com: Hello, Not supported. You can see LACP packets punted to the RE if you use monitor trafic interface xxx or if you check ppm remote adjacencies there is no LACP adj up at PFE level : show ppm adjacencies remote (hidden cmd) For exemple on MX you have LACP distributed at PFE : mymx@mx show ppm adjacencies remote Protocol Hold time (msec) LACP 3000 LACP 3000 LACP 3000 LACP 3000 LACP 3000 LACP 3000 LACP 3000 LFM300 David David Roy IP/MPLS Support engineer - Orange France Ph. +33 2 99 87 64 72 - Mob. +33 6 85 52 22 13 david@orange.com JNCIE-MT/SP #703 - JNCIE-ENT #305 - JNCIP-SEC -Message d'origine- De : juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] De la part de Martin T Envoyé : mardi 30 octobre 2012 16:16 À : juniper-nsp@puck.nether.net Objet : [j-nsp] LACP support on forwarding plane on M10i? Is LACP supported on forwarding plane on M10i? According to Disabling Distributed Periodic Packet Management on the Packet Forwarding Engine(http://goo.gl/uDwYm) document LACP is supported on packet forwarding engine only on MX series. On the other hand, show pfe statistics traffic displays LACP under Packet Forwarding Engine local protocol statistics: root@M10i show pfe statistics traffic Packet Forwarding Engine traffic statistics: Input packets: 15819824321 pps Output packets: 13308609440 pps Packet Forwarding Engine local traffic statistics: Local packets input : 13846116 Local packets output: 5817751 Software input control plane drops :0 Software input high drops :0 Software input medium drops : 6108913 Software input low drops:0 Software output drops : 2049 Hardware input drops:201244886 Packet Forwarding Engine local protocol statistics: HDLC keepalives:0 ATM OAM:0 Frame Relay LMI:0 PPP LCP/NCP:0 OSPF hello :0 OSPF3 hello:0 RSVP hello :0 LDP hello : 217 BFD: 3502848 IS-IS IIH : 140750 LACP : 564573 ARP:40358 ETHER OAM :0 Unknown:0 Packet Forwarding Engine hardware discard statistics: Timeout:0 Truncated key :0 Bits to test :0 Data error :0 Stack underflow:0 Stack overflow :0 Normal discard : 15337489 Extended discard :0 Invalid interface :0 Info cell drops:0 Fabric drops :0 Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU Error statistics: Input Checksum : 707 Output MTU :0 root@M10i regards, martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
Re: [j-nsp] SRX: rate-limiting source NAT sources
You could limit the number of sessions each ip address in your internal zone can initiate. Here is an example on limiting an ip address in the zone trust to only be able to create 1 session. set security screen ids-option session-limit limit-session source-ip-based 1 set security zones security-zone trust screen session-limit There should be no license needed for this feature.Here is how to configure this: http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/denial-of-service-firewall-source-based-session-limit-setting-cli.html -- Hans Kristian Eiken 2012/10/29 Jonathan Lassoff j...@thejof.com So, I'm working on tuning an SRX deployment and am wondering if something is possible. This deployment is doing a lot of source NAT for a wide variety of endpoints as they egress out to the Internet. Pretty vanilla configuration. Specific sources are mapped via NAT rules to specific egress IPs (for IP filtering in some places, outside of the SRXes in question). And once in a while, some endpoint will have a legitimate need to open up *many* connections (and then NAT states) that pass over this SRX deployment. Unfortunately, the rate of connection establishment relative to the application timeouts means that these heavy users can use up all of the ephemeral ports, blocking new flows from becoming established. We've been playing a bit of whack-a-mole, assigning more IP space to the various source NAT pools, but would like to find a more proper solution. So, my question is this: is there any mechanism anyone knows of to rate-limit or block-past-a-threshold a source NAT source if it starts making too many connections? I don't see anything obvious in the SRX documentation, so I figured I'd ask here for pointers. Right now, it's way to easy for one bad actor (malicious or benevolent) to max out a source NAT pool. Cheers, jof ___ 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] SRX: rate-limiting source NAT sources
30.10.2012 01:55, Jonathan Lassoff wrote: Specific sources are mapped via NAT rules to specific egress IPs (for IP filtering in some places, outside of the SRXes in question). And once in a while, some endpoint will have a legitimate need to open up *many* connections (and then NAT states) that pass over this SRX deployment. Unfortunately, the rate of connection establishment relative to the application timeouts means that these heavy users can use up all of the ephemeral ports, blocking new flows from becoming established. Looks like session-limit SCREEN options is what you need: http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/security/topic-43929.html It's applied per-zone, so if you want to apply different limits to different NAT pools, you need to put users of different pools into different zones. Otherwise you only can have a single setting for all (maybe not that big issue). Older JUNOS version (10.1 at least, don't know when it's changed but looks like it did) applied source and dst-limits in a bunch, so if you needed to only limit per-src you also had to explicitly configure dst-limit to the maximum number (which is platform dependent) otherwise it would be applied with a very low default value. As of my quick check with 11.4, looks like it is changed and you can apply per-src and don't care per-dst, but I might be missing something, so you'd rather test it. It's maybe a good idea to also limit the rate of new sessions per second with tcp-syn knob. Be careful, most default screen option values are for server-side protection and very very rough, so completely inapplicable in you case and must be adjusted for each particular scenario. Another thing you might find useful is called aggressive-aging: http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/security/index.html?topic-60842.htm ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Should be hitless. You need to configure GRES + NSR + no-split-detection. On 10/30/12 4:06 PM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ #specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
Have no split detection, I'll try for the GRES and NSR. Thanks, Morgan On Tue, Oct 30, 2012 at 4:24 PM, Doug Hanks dha...@juniper.net wrote: Should be hitless. You need to configure GRES + NSR + no-split-detection. On 10/30/12 4:06 PM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ #specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ 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] Odd drop behavior on low-rate multicast streams
Hi John, Did you check by sending the traffic after enabling this configuration? Once the forwarding entry is created with traffic, it should have the timeout set to Never for that entry in show multicast route group blah extensive output. Forwarding entry won't get created until we see the traffic hitting this PIM join entry. Creation of entry with flow-map is still traffic driven (except the very first time when the PIM join is received). Only the deletion (once created is affected by flow-map. Let me know what you see after sending traffic. Thanks, Nilesh. Sent from my mobile device On Oct 30, 2012, at 12:31 PM, John Neiberger jneiber...@gmail.com wrote: Nilesh, We're trying this configuration and it's not having the results I expected. Previously, there would be no entry in show multicast route for a particular group, but there would be an entry in show pim join extensive. After implementing the flow map with the timeout set to never, I would have expected an entry to appear in the multicast routing table since there are active PIM joins, but that doesn't seem to be the case. Can you confirm what I should expect to see? Shouldn't I see an entry in the multicast routing table for all entries matched in the flow map now? Thanks, John On Mon, Oct 8, 2012 at 3:44 PM, Nilesh Khambal nkham...@juniper.net wrote: Sure. Make sure you implement this workaround across all Juniper boxes that are in path for this multicast group traffic. - Nilesh. From: John Neiberger jneiber...@gmail.com Date: Monday, October 8, 2012 2:40 PM To: Nilesh Khambal nkham...@juniper.net Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Odd drop behavior on low-rate multicast streams On Mon, Oct 8, 2012 at 3:28 PM, Nilesh Khambal nkham...@juniper.net wrote: Hi John, Is it the first packet that gets lost from the stream or the subsequent ones? If the route does not exist on MX for your (S,G) in the forwarding-table, then when you receive the packet for this (S,G) on MX, it will be punted to the routing-enginer (control-plane) for what is known as multicast route resolution to install the route. Control plane does usual the checks (IIF, receivers etc) on the packets and installs the route in the forwarding table. This is probably what you are seeing in this case. Creation and maintenance of multicast route in the forwarding-table is a data-driven. If there is no data for the timeout period, which is usually 6 mins by default, route (a.k.a forwarding cache) will timeout and the new traffic will need to be resolved again by control plane to install the route. The forwarding-cache timeout knob can increase the value when route will be timed out when there is no traffic hitting the route but depending upon the frequency of your data traffic, it might not be useful in all use cases. You might want to consider flow-map configuration. This gives you control over which groups you want not to timeout. The forwarding-cache knob you mentioned in other email will affect all multicast routes which you may not want. http://www.juniper.net/techpubs/en_US/junos12.2/topics/example/mcast-flow-map.html Thanks, Nilesh. Nilesh, It is only the first packet that gets dropped. If the sender is configured to immediately send a second copy of the message, that one arrives at the destination. I think it's a great idea to use a flow mask to control this because we can set this particular S,G to never timeout while leaving default rules in place for everything else. Thanks! John ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Also will need the 'set commit sync' command under the 'edit system' This is needed for nonstop-bridging Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ben Dale Sent: Wednesday, 31 October 2012 10:31 AM To: Morgan McLean Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2 000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2 000/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx20 00/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx20 00/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
Richard A Steenbergen r...@e-gerbil.net wrote: IMHO multi-chassis boxes are for people who can't figure out routing protocols When it comes to ethernet switching, routing protocols means what? :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200
NSR was not supported on EX3300s until 12.1 per the release notes, and 12.2 added NSSU for EX3300s. I did not see mention of NSB in the release notes, but I have to believe it's supported for NSSU to work properly. Unfortunately I do not have access to any EX3300s to test / confirm. http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#high-availability-features-by-platform-table also suggests that NSB came in 12.2 also make sure you remove the no-split-detection option if your VC is more than 2 units. my testing with EX4500 / EX4200 VCs has been very positive of the NSR / NSB features on 11.4 Will On Oct 30, 2012, at 8:00 PM, juniper-nsp-requ...@puck.nether.net wrote: Date: Tue, 30 Oct 2012 17:00:17 -0700 From: Morgan McLean wrx...@gmail.com To: Ben Dale bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Message-ID: CAPiLEQdy1fMW5wG0qpY1ukn7tOvVP=pytj0axezsgfshxsi...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Seriously, routing protocol ain't my problem here. Sent from my iPhone On Oct 30, 2012, at 5:49 PM, Pavel Lunin plu...@senetsy.ru wrote: Richard A Steenbergen r...@e-gerbil.net wrote: IMHO multi-chassis boxes are for people who can't figure out routing protocols When it comes to ethernet switching, routing protocols means what? :) ___ 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] How reliable is EX multichassis? 3300 and 8200
I'll upgrade and try it out. Sent from my iPhone On Oct 30, 2012, at 6:33 PM, William McLendon wimcl...@gmail.com wrote: NSR was not supported on EX3300s until 12.1 per the release notes, and 12.2 added NSSU for EX3300s. I did not see mention of NSB in the release notes, but I have to believe it's supported for NSSU to work properly. Unfortunately I do not have access to any EX3300s to test / confirm. http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#high-availability-features-by-platform-table also suggests that NSB came in 12.2 also make sure you remove the no-split-detection option if your VC is more than 2 units. my testing with EX4500 / EX4200 VCs has been very positive of the NSR / NSB features on 11.4 Will On Oct 30, 2012, at 8:00 PM, juniper-nsp-requ...@puck.nether.net wrote: Date: Tue, 30 Oct 2012 17:00:17 -0700 From: Morgan McLean wrx...@gmail.com To: Ben Dale bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Message-ID: CAPiLEQdy1fMW5wG0qpY1ukn7tOvVP=pytj0axezsgfshxsi...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
GR is mutually exclusive with NSR. You want NSR. On 10/30/12 5:44 PM, Luca Salvatore l...@ninefold.com wrote: I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx20 00/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx20 00/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Yep I'm aware, but why are my OSPF neighbours going down when one switch reboots? Luca -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Wednesday, 31 October 2012 2:42 PM To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches GR is mutually exclusive with NSR. You want NSR. On 10/30/12 5:44 PM, Luca Salvatore l...@ninefold.com wrote: I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2 0 00/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2 0 00/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ 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
