Re: [j-nsp] Speed
On (2013-04-08 23:29 +0200), Benny Amorsen wrote: UDP tests can be too generous on the network. A stream of perfectly spaced UDP packets will not show problems with microbursts. Almost all bulk transfer protocols are TCP, so it is important to test with TCP. Microbursts will drop UDP has well, you'll experience this as packet loss just the same, so you want to find value which has 0 packet loss. This same number will indicate when TCP will start dropping (and reducing window-size) I see people often don't even look at packet loss numbers in iperf UDP output -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ex9200 fib size
Hi What is FIB size at latest EX9200 switches ? I cannot find it out from datasheet. Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex9200 fib size
http://www.juniper.net/us/en/products-services/switching/ex-series/ex9200/#specifications IPv4 Unicast / Multicast Routes 256,000 IPv6 Unicast / Multicast Routes 256,000 clearly artificially limited to create differentiation On 9 April 2013 15:15, Robert Hass robh...@gmail.com wrote: Hi What is FIB size at latest EX9200 switches ? I cannot find it out from datasheet. Rob ___ 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
Re: [j-nsp] Speed
Saku Ytti s...@ytti.fi writes: Microbursts will drop UDP has well, you'll experience this as packet loss just the same, so you want to find value which has 0 packet loss. This same number will indicate when TCP will start dropping (and reducing window-size) There will only be packet loss if you test while there is background traffic on the link. If the only load is a perfect stream of UDP packets, the buffers will not fill and no packets will be dropped. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
On (2013-04-09 15:03 +0200), Benny Amorsen wrote: There will only be packet loss if you test while there is background traffic on the link. If the only load is a perfect stream of UDP packets, the buffers will not fill and no packets will be dropped. This is completely L4 agnostic though, TCP and UDP experience same rate of packet loss due to congestion (short of specific QoS). Obviously microbursts can (in both TCP or UDP) scenario happen without any background traffic. Consider you're connected to 1GE port, testing another host in 100M port, if you limit your rate to 100M, you still causes the 100M port to congest, as incoming rate is always 1GE for variable duration (depending on how you police the sending). -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Stackable switches, looping stacking ports
Hey all. A colleague of mine tells me that, if you have a single stackable switch (not in a stack obviously) and do not loop the two stacking ports on the back using the stacking cable that comes in the box, then you reduce the effective throughput of the switch. Specifically I am talking about an EX4200. To me this sounds a bit odd, and is not in line with my perhaps rudimentary understanding of stackable switches, so hoping someone here can clarify whether looping the stacking ports is good/bad/necessary/unnecessary? Thanks. Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Stackable switches, looping stacking ports
On 4/9/13 11:15 AM, Tom Storey wrote: Hey all. A colleague of mine tells me that, if you have a single stackable switch (not in a stack obviously) and do not loop the two stacking ports on the back using the stacking cable that comes in the box, then you reduce the effective throughput of the switch. The ex4200's asic has a capacity of 136Gb/s from the front panel ports which is 100% of line rate across all ports. I don't imagine connecting the asic back to itself is that useful or usable topology. Specifically I am talking about an EX4200. To me this sounds a bit odd, and is not in line with my perhaps rudimentary understanding of stackable switches, so hoping someone here can clarify whether looping the stacking ports is good/bad/necessary/unnecessary? Thanks. Tom ___ 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] Stackable switches, looping stacking ports
On Tue, Apr 09, 2013 at 11:48:36AM -0700, joel jaeggli wrote: On 4/9/13 11:15 AM, Tom Storey wrote: Hey all. A colleague of mine tells me that, if you have a single stackable switch (not in a stack obviously) and do not loop the two stacking ports on the back using the stacking cable that comes in the box, then you reduce the effective throughput of the switch. The ex4200's asic has a capacity of 136Gb/s from the front panel ports which is 100% of line rate across all ports. I don't imagine connecting the asic back to itself is that useful or usable topology. It does make a positive difference to loop back the stack cable on a standalone unit. See this diagram: http://blog.cochard.me/2010/08/juniper-ex-4200-internal-pfe-routing-in.html Connecting from ports 0-23 to 24-47 has to normally cross 3 internal PFEs. If you connect VCP-0 to VCP-1, then it only has to cross 2 PFEs. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Saku Ytti s...@ytti.fi writes: Obviously microbursts can (in both TCP or UDP) scenario happen without any background traffic. Consider you're connected to 1GE port, testing another host in 100M port, if you limit your rate to 100M, you still causes the 100M port to congest, as incoming rate is always 1GE for variable duration (depending on how you police the sending). Yes, you can in theory cause microbursting of UDP if you want. I am just not sure which tool I would use to do that. Typical UDP tests like iperf attempt to do perfect timing of packets so bursts are avoided, and they seem to do a fairly good job of it. In contrast, iperf TCP can get awfully bursty. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Max ARP entries on an MX240?
Can't seem to find a specific ceiling on this. Anyone know the max ARP entries on an MX240? Thanks in advance. --Dave Peters ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Max ARP entries on an MX240?
On 4/9/13 3:41 PM, Dave Peters - Terabit Systems wrote: Can't seem to find a specific ceiling on this. Anyone know the max ARP entries on an MX240? There isn't one, it's going to depend on the amount of memory used for the rest of the fib. I imagine that with 2 million or so l2 next hops the control plane would be rather busy. Thanks in advance. --Dave Peters ___ 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] M10i
hello, I need to change a CISCO 7206 router that computer I recommend one of the requirements is that you have two 10G interfacez two interfacez 1G and STM1 interface to connect with the ISP was thinking M10i Router but I do not support 10g interface. thank you very much for your help. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M10i
I think you'll need at least an M20 for your 10 GigE requirement as well as SDH. If you can somehow get a different transit circuit than your SDH one, an MX5 would be a much closer (throughput-wise) and better bang-for-your-buck replacement for a 7206 than an M-series. J-series with a T1 module could also work, depending on your STM-1. If you need SDH though, you'll need M or T. J can do T1s. --j On Tue, Apr 9, 2013 at 6:28 PM, Orlando Cordova Gonzales orlando.cordova.gonza...@gmail.com wrote: hello, I need to change a CISCO 7206 router that computer I recommend one of the requirements is that you have two 10G interfacez two interfacez 1G and STM1 interface to connect with the ISP was thinking M10i Router but I do not support 10g interface. thank you very much for your help. ___ 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] port mirror on EX causing crash
Wondering if anyone has seen any issues with EX switches running port mirroring - specifically seeing the switch generate a 'parity error' and crashing? I have an EX4200 10.4r5.5, a few hours after turning on port mirroring the switch crashed. It threw some memory parity errors which JTAC tells me means the switch is faulty and should be replaced. The switch in question has been running fine for 3 years, but turning on a ingress and egress port mirror (on a single port) seems to make the switch have a bad day. The switch isn't busy, and the port that I'm mirroring has about 80 to 100Mb of traffic. I'm mirroring the port to an IDS and would like to keep it running for the foreseeable future. Any thoughts on this situation? Thanks Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] port mirror on EX causing crash
Yep - listen to JTAC. The parity error is definitely a sign that the memory on your switch is flakey - I had an EX4200 completely lock-up and drop out of a VC after 6 months of flawless operation. Rebooted it and it came good, 24 hours later it dropped right back out again with the parity error again. RMA and everything is happy again. On 10/04/2013, at 2:50 PM, Luca Salvatore l...@ninefold.com wrote: Wondering if anyone has seen any issues with EX switches running port mirroring - specifically seeing the switch generate a 'parity error' and crashing? I have an EX4200 10.4r5.5, a few hours after turning on port mirroring the switch crashed. It threw some memory parity errors which JTAC tells me means the switch is faulty and should be replaced. The switch in question has been running fine for 3 years, but turning on a ingress and egress port mirror (on a single port) seems to make the switch have a bad day. The switch isn't busy, and the port that I'm mirroring has about 80 to 100Mb of traffic. I'm mirroring the port to an IDS and would like to keep it running for the foreseeable future. Any thoughts on this situation? Thanks Luca. ___ 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] port mirror on EX causing crash
Hi Luca, On Wed, Apr 10, 2013 at 2:50 PM, Luca Salvatore l...@ninefold.com wrote: [...] I have an EX4200 10.4r5.5, a few hours after turning on port mirroring the switch crashed. It threw some memory parity errors which JTAC tells me means the switch is faulty and should be replaced. The switch in question has been running fine for 3 years, but turning on a ingress and egress port mirror (on a single port) seems to make the switch have a bad day. The switch isn't busy, and the port that I'm mirroring has about 80 to 100Mb of traffic. I'm mirroring the port to an IDS and would like to keep it running for the foreseeable future. [...] FWIW, I have lots of EX4200s with analyzers running 10.4R6 (not R5) and have never seen this problem. Sounds like a hardware thing. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] port mirror on EX causing crash
Yes this is what has happened to us... twice in two days. Only change on the switch was setting up a port mirror... This would probably consume a bit more memory which may have triggered the crash. I have already organised the RMA, was just wondering about the mirroring. Luca -Original Message- From: Ben Dale [mailto:bd...@comlinx.com.au] Sent: Wednesday, 10 April 2013 3:14 PM To: Luca Salvatore Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] port mirror on EX causing crash Yep - listen to JTAC. The parity error is definitely a sign that the memory on your switch is flakey - I had an EX4200 completely lock-up and drop out of a VC after 6 months of flawless operation. Rebooted it and it came good, 24 hours later it dropped right back out again with the parity error again. RMA and everything is happy again. On 10/04/2013, at 2:50 PM, Luca Salvatore l...@ninefold.com wrote: Wondering if anyone has seen any issues with EX switches running port mirroring - specifically seeing the switch generate a 'parity error' and crashing? I have an EX4200 10.4r5.5, a few hours after turning on port mirroring the switch crashed. It threw some memory parity errors which JTAC tells me means the switch is faulty and should be replaced. The switch in question has been running fine for 3 years, but turning on a ingress and egress port mirror (on a single port) seems to make the switch have a bad day. The switch isn't busy, and the port that I'm mirroring has about 80 to 100Mb of traffic. I'm mirroring the port to an IDS and would like to keep it running for the foreseeable future. Any thoughts on this situation? Thanks Luca. ___ 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
