September 2016 - mice-discuss

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Andrew Hoyos

Option #1 seems to be the most logical (with a 2x10g LAG, split between the two 4500/4550 switches even MCLAG style). That removes that traffic from the VC paths and simplifies that side of the house. I’d even pony up this EX-UM-2XFP I have sitting here unused. Are we graphing the VC links? SNMP support for that came in 14.something, otherwise, there is a SLAX script that can put values in the util mib: https://kb.juniper.net/InfoCenter/index?page=content&id=KB27711&actp=search https://github.com/dgarros/juniper-ex-vcp-to-mib/blob/master/ex-vcp-to-mib.… I know that the interfaces themselves are clean, as Doug showed us, but that doesn’t rule out microbursts that are maxing them out. -- Andrew Hoyos hoyosa(a)gmail.com > On Sep 20, 2016, at 9:21 AM, Jason Hanke <jayhanke(a)NEUTRALPATH.NET> wrote: > > We've had pretty significant growth (20+ Gig) over the last year or so. > > <graph_image.png> > > Most of this traffic is CDN->Eyeball. The CDN networks are taking increasingly larger connections creating a large delta between the largest and smallest connections on the switch. A 4x10G LAG can put a pretty big dent in the VC links on its own. > > I have two ideas- > > 1) Reconfigure the 1G switch to have a LAG group back into the main switch. > 2) Offer community strings letting the CDN networks send traffic to the eyeballs without traversing the VC links. > > Jay > > > > On Tue, Sep 20, 2016 at 8:29 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > No, that isn't the case, it is a dual ring, so there are paths > > FPC0->FPC1->FPC2->FPC0 > FPC0->FPC2->FPC1->FPC0 > > There are ways to tell which is the "active" path through the rings, as I > stated before, I think one path is mainly "active" and one is mainly passive. > I don't know if just disabling one VCP port will work. > > But I guess there is a KB on it. > https://kb.juniper.net/InfoCenter/index?page=content&id=KB17821&actp=search > > So, we could failover the active path to the other ring. > Or set one of the VCP ports to disable. > > Should we do a 'virtual-chassis active path failover' event sometime? > > > On Tue, Sep 20, 2016 at 08:07:00AM -0500, Jeremy Lumby wrote: > > So if I understand correctly from your "show virtual-chassis active-topology" below, all traffic from the 4500 to the 4200 is going via the 4550? And if that is the case, is there an easy way in the software that we could tell it to have return traffic from the 4200 to the 4500 also go via the 4550? This would allow us to easily test to see if it is the specific cable that runs from the 4200 to the 4500. > > > > -----Original Message----- > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre > > Sent: Tuesday, September 20, 2016 12:24 AM > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants > > > > On Mon, Sep 19, 2016 at 11:01:00PM -0500, Jeremy Lumby wrote: > > > This leads me to wonder if there is possibly an issue with the stacking modules, or they are being saturated. > > ... > > > > Your understanding of the vc port speeds is correct. > > > > The VCP ports are built into the EX4200 and EX4500. The EX4550 has addon > > cards that do those functions. We can devote a port to VCP functionality > > instead, but it'll be a 10G limit instead of 32G > > > > The VCP ports are 32Gbps single direction in each port. So in the dual-ring > > the cables have are 32Gbps in each direction. > > > > You can see which ports are connected to what. (FPC0 is the EX4500, > > FPC1 is the EX4200, FPC2 is the EX4550). > > > > show virtual-chassis active-topology > > fpc0: > > -------------------------------------------------------------------------- > > Destination ID Next-hop > > > > 1 2(vcp-1.32768) 1(vcp-0.32768) > > > > 2 2(vcp-1.32768) > > > > fpc1: > > -------------------------------------------------------------------------- > > Destination ID Next-hop > > > > 0 0(vcp-0.32768) 2(vcp-1.32768) > > > > 2 2(vcp-1.32768) > > > > fpc2: > > -------------------------------------------------------------------------- > > Destination ID Next-hop > > > > 0 0(vcp-255/2/0.32768) > > > > 1 1(vcp-255/2/3.32768) > > > > > > > > You can monitor each of the VCP ports on each of the members. I don't think > > we are close to saturation. > > > > request session member 1 > > (ie. rlogin to the EX4200 switch). > > > > monitor int vcp-0 > > Interface: vcp-0, Enabled, Link is Up > > Encapsulation: Virtual-Chassis-Interface, Speed: 32000mbps > > Traffic statistics: Current delta > > Input bytes: 25685118521 [12138] > > Output bytes: 27856843010 [13204] > > Input packets: 33377693 [16] > > Output packets: 33371644 [16] > > Error statistics: > > Input errors: 0 [0] > > Input drops: 0 [0] > > Input framing errors: 0 [0] > > Carrier transitions: 0 [0] > > Output errors: 0 [0] > > Output drops: 0 [0] > > > > > > vcp-1 on FPC1 is much less usage. Still zero error stats. All switches > > show zero error stats on any of the respective VCP port status. > > > > I suppose further troubleshooting could be to replace the VCP cables > > one by one coming out of the EX4200. > > > > Its too bad that we've got the quad fiber expansion in the EX4200, > > another test could be to put the dual 10G expansion in it, and make > > those VCP ports and make the VC fabric over those ports instead. But > > we've got 3 member ports lit on that quad 1G fiber. > > > > > > > > -- > > Doug McIntyre <merlyn(a)iphouse.net> > > ~.~ ipHouse ~.~ > > Network Engineer/Provisioning/Jack of all Trades > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > > > > -- > Jay Hanke > CTO > Neutral Path Communications > 3 Civic Center Plaza, Suite 204 > Mankato, MN 56001 > (507) 327-2398 mobile > jayhanke(a)neutralpath.net > www.neutralpath.net > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Richard Laager

On 09/20/2016 09:21 AM, Jason Hanke wrote: > Offer community strings letting the CDN networks send traffic to the > eyeballs without traversing the VC links. I'm not quite following this one. What did you have in mind? -- Richard

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jason Hanke

We've had pretty significant growth (20+ Gig) over the last year or so. [image: Inline image 5] Most of this traffic is CDN->Eyeball. The CDN networks are taking increasingly larger connections creating a large delta between the largest and smallest connections on the switch. A 4x10G LAG can put a pretty big dent in the VC links on its own. I have two ideas- 1) Reconfigure the 1G switch to have a LAG group back into the main switch. 2) Offer community strings letting the CDN networks send traffic to the eyeballs without traversing the VC links. Jay On Tue, Sep 20, 2016 at 8:29 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > No, that isn't the case, it is a dual ring, so there are paths > > FPC0->FPC1->FPC2->FPC0 > FPC0->FPC2->FPC1->FPC0 > > There are ways to tell which is the "active" path through the rings, as I > stated before, I think one path is mainly "active" and one is mainly > passive. > I don't know if just disabling one VCP port will work. > > But I guess there is a KB on it. > https://kb.juniper.net/InfoCenter/index?page=content& > id=KB17821&actp=search > > So, we could failover the active path to the other ring. > Or set one of the VCP ports to disable. > > Should we do a 'virtual-chassis active path failover' event sometime? > > > On Tue, Sep 20, 2016 at 08:07:00AM -0500, Jeremy Lumby wrote: > > So if I understand correctly from your "show virtual-chassis > active-topology" below, all traffic from the 4500 to the 4200 is going via > the 4550? And if that is the case, is there an easy way in the software > that we could tell it to have return traffic from the 4200 to the 4500 also > go via the 4550? This would allow us to easily test to see if it is the > specific cable that runs from the 4200 to the 4500. > > > > -----Original Message----- > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Doug McIntyre > > Sent: Tuesday, September 20, 2016 12:24 AM > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G > Participants > > > > On Mon, Sep 19, 2016 at 11:01:00PM -0500, Jeremy Lumby wrote: > > > This leads me to wonder if there is possibly an issue with the > stacking modules, or they are being saturated. > > ... > > > > Your understanding of the vc port speeds is correct. > > > > The VCP ports are built into the EX4200 and EX4500. The EX4550 has addon > > cards that do those functions. We can devote a port to VCP functionality > > instead, but it'll be a 10G limit instead of 32G > > > > The VCP ports are 32Gbps single direction in each port. So in the > dual-ring > > the cables have are 32Gbps in each direction. > > > > You can see which ports are connected to what. (FPC0 is the EX4500, > > FPC1 is the EX4200, FPC2 is the EX4550). > > > > show virtual-chassis active-topology > > fpc0: > > ------------------------------------------------------------ > -------------- > > Destination ID Next-hop > > > > 1 2(vcp-1.32768) 1(vcp-0.32768) > > > > 2 2(vcp-1.32768) > > > > fpc1: > > ------------------------------------------------------------ > -------------- > > Destination ID Next-hop > > > > 0 0(vcp-0.32768) 2(vcp-1.32768) > > > > 2 2(vcp-1.32768) > > > > fpc2: > > ------------------------------------------------------------ > -------------- > > Destination ID Next-hop > > > > 0 0(vcp-255/2/0.32768) > > > > 1 1(vcp-255/2/3.32768) > > > > > > > > You can monitor each of the VCP ports on each of the members. I don't > think > > we are close to saturation. > > > > request session member 1 > > (ie. rlogin to the EX4200 switch). > > > > monitor int vcp-0 > > Interface: vcp-0, Enabled, Link is Up > > Encapsulation: Virtual-Chassis-Interface, Speed: 32000mbps > > Traffic statistics: Current > delta > > Input bytes: 25685118521 > [12138] > > Output bytes: 27856843010 > [13204] > > Input packets: 33377693 > [16] > > Output packets: 33371644 > [16] > > Error statistics: > > Input errors: 0 > [0] > > Input drops: 0 > [0] > > Input framing errors: 0 > [0] > > Carrier transitions: 0 > [0] > > Output errors: 0 > [0] > > Output drops: 0 > [0] > > > > > > vcp-1 on FPC1 is much less usage. Still zero error stats. All switches > > show zero error stats on any of the respective VCP port status. > > > > I suppose further troubleshooting could be to replace the VCP cables > > one by one coming out of the EX4200. > > > > Its too bad that we've got the quad fiber expansion in the EX4200, > > another test could be to put the dual 10G expansion in it, and make > > those VCP ports and make the VC fabric over those ports instead. But > > we've got 3 member ports lit on that quad 1G fiber. > > > > > > > > -- > > Doug McIntyre <merlyn(a)iphouse.net> > > ~.~ ipHouse ~.~ > > Network Engineer/Provisioning/Jack of all Trades > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Andrew Hoyos

On Sep 20, 2016, at 8:29 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > > There are ways to tell which is the "active" path through the rings, as I > stated before, I think one path is mainly "active" and one is mainly passive. > I don't know if just disabling one VCP port will work. Let’s figure out of a common VCP port first. Like I said before, this ‘path’ is based on src/dst interfaces in the VC, and the selection algorithm is SPF based (but factors in actual PFE hops on each switch - internal to each switch is a PFE chip controlling a set of ports with a fabric between that is also used for VC - it’s not as simple as FPC0 -> FPC1 -> FPC2) What say: ‘show virtual-chassis vc-path source-interface ge-1/0/15 destination-interface xe-0/0/14’ (original issue of AITech to USInternet - loss evident) ‘show virtual-chassis vc-path source-interface ge-1/0/11 destination-interface xe-0/0/8’ (MNVoip to Charter - loss evident) ‘show virtual-chassis vc-path source-interface ge-1/0/15 destination-interface xe-2/0/11’ (AITech to UW Madison - no loss evident) If there is a common VCP port on the two paths where loss was evident, it’d probably be easier and less intrusive to disable that port during a maintenance window, test, then re-enable. IIRC that active path failover command is for *. 'request virtual-chassis vc-port member 1 set interface vcp-X disable' -- Andrew Hoyos hoyosa(a)gmail.com

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Doug McIntyre

No, that isn't the case, it is a dual ring, so there are paths FPC0->FPC1->FPC2->FPC0 FPC0->FPC2->FPC1->FPC0 There are ways to tell which is the "active" path through the rings, as I stated before, I think one path is mainly "active" and one is mainly passive. I don't know if just disabling one VCP port will work. But I guess there is a KB on it. https://kb.juniper.net/InfoCenter/index?page=content&id=KB17821&actp=search So, we could failover the active path to the other ring. Or set one of the VCP ports to disable. Should we do a 'virtual-chassis active path failover' event sometime? On Tue, Sep 20, 2016 at 08:07:00AM -0500, Jeremy Lumby wrote: > So if I understand correctly from your "show virtual-chassis active-topology" below, all traffic from the 4500 to the 4200 is going via the 4550? And if that is the case, is there an easy way in the software that we could tell it to have return traffic from the 4200 to the 4500 also go via the 4550? This would allow us to easily test to see if it is the specific cable that runs from the 4200 to the 4500. > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre > Sent: Tuesday, September 20, 2016 12:24 AM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants > > On Mon, Sep 19, 2016 at 11:01:00PM -0500, Jeremy Lumby wrote: > > This leads me to wonder if there is possibly an issue with the stacking modules, or they are being saturated. > ... > > Your understanding of the vc port speeds is correct. > > The VCP ports are built into the EX4200 and EX4500. The EX4550 has addon > cards that do those functions. We can devote a port to VCP functionality > instead, but it'll be a 10G limit instead of 32G > > The VCP ports are 32Gbps single direction in each port. So in the dual-ring > the cables have are 32Gbps in each direction. > > You can see which ports are connected to what. (FPC0 is the EX4500, > FPC1 is the EX4200, FPC2 is the EX4550). > > show virtual-chassis active-topology > fpc0: > -------------------------------------------------------------------------- > Destination ID Next-hop > > 1 2(vcp-1.32768) 1(vcp-0.32768) > > 2 2(vcp-1.32768) > > fpc1: > -------------------------------------------------------------------------- > Destination ID Next-hop > > 0 0(vcp-0.32768) 2(vcp-1.32768) > > 2 2(vcp-1.32768) > > fpc2: > -------------------------------------------------------------------------- > Destination ID Next-hop > > 0 0(vcp-255/2/0.32768) > > 1 1(vcp-255/2/3.32768) > > > > You can monitor each of the VCP ports on each of the members. I don't think > we are close to saturation. > > request session member 1 > (ie. rlogin to the EX4200 switch). > > monitor int vcp-0 > Interface: vcp-0, Enabled, Link is Up > Encapsulation: Virtual-Chassis-Interface, Speed: 32000mbps > Traffic statistics: Current delta > Input bytes: 25685118521 [12138] > Output bytes: 27856843010 [13204] > Input packets: 33377693 [16] > Output packets: 33371644 [16] > Error statistics: > Input errors: 0 [0] > Input drops: 0 [0] > Input framing errors: 0 [0] > Carrier transitions: 0 [0] > Output errors: 0 [0] > Output drops: 0 [0] > > > vcp-1 on FPC1 is much less usage. Still zero error stats. All switches > show zero error stats on any of the respective VCP port status. > > I suppose further troubleshooting could be to replace the VCP cables > one by one coming out of the EX4200. > > Its too bad that we've got the quad fiber expansion in the EX4200, > another test could be to put the dual 10G expansion in it, and make > those VCP ports and make the VC fabric over those ports instead. But > we've got 3 member ports lit on that quad 1G fiber. > > > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jeremy Lumby

So if I understand correctly from your "show virtual-chassis active-topology" below, all traffic from the 4500 to the 4200 is going via the 4550? And if that is the case, is there an easy way in the software that we could tell it to have return traffic from the 4200 to the 4500 also go via the 4550? This would allow us to easily test to see if it is the specific cable that runs from the 4200 to the 4500. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Tuesday, September 20, 2016 12:24 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants On Mon, Sep 19, 2016 at 11:01:00PM -0500, Jeremy Lumby wrote: > This leads me to wonder if there is possibly an issue with the stacking modules, or they are being saturated. ... Your understanding of the vc port speeds is correct. The VCP ports are built into the EX4200 and EX4500. The EX4550 has addon cards that do those functions. We can devote a port to VCP functionality instead, but it'll be a 10G limit instead of 32G The VCP ports are 32Gbps single direction in each port. So in the dual-ring the cables have are 32Gbps in each direction. You can see which ports are connected to what. (FPC0 is the EX4500, FPC1 is the EX4200, FPC2 is the EX4550). show virtual-chassis active-topology fpc0: -------------------------------------------------------------------------- Destination ID Next-hop 1 2(vcp-1.32768) 1(vcp-0.32768) 2 2(vcp-1.32768) fpc1: -------------------------------------------------------------------------- Destination ID Next-hop 0 0(vcp-0.32768) 2(vcp-1.32768) 2 2(vcp-1.32768) fpc2: -------------------------------------------------------------------------- Destination ID Next-hop 0 0(vcp-255/2/0.32768) 1 1(vcp-255/2/3.32768) You can monitor each of the VCP ports on each of the members. I don't think we are close to saturation. request session member 1 (ie. rlogin to the EX4200 switch). monitor int vcp-0 Interface: vcp-0, Enabled, Link is Up Encapsulation: Virtual-Chassis-Interface, Speed: 32000mbps Traffic statistics: Current delta Input bytes: 25685118521 [12138] Output bytes: 27856843010 [13204] Input packets: 33377693 [16] Output packets: 33371644 [16] Error statistics: Input errors: 0 [0] Input drops: 0 [0] Input framing errors: 0 [0] Carrier transitions: 0 [0] Output errors: 0 [0] Output drops: 0 [0] vcp-1 on FPC1 is much less usage. Still zero error stats. All switches show zero error stats on any of the respective VCP port status. I suppose further troubleshooting could be to replace the VCP cables one by one coming out of the EX4200. Its too bad that we've got the quad fiber expansion in the EX4200, another test could be to put the dual 10G expansion in it, and make those VCP ports and make the VC fabric over those ports instead. But we've got 3 member ports lit on that quad 1G fiber. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Doug McIntyre

On Mon, Sep 19, 2016 at 11:01:00PM -0500, Jeremy Lumby wrote: > This leads me to wonder if there is possibly an issue with the stacking modules, or they are being saturated. ... Your understanding of the vc port speeds is correct. The VCP ports are built into the EX4200 and EX4500. The EX4550 has addon cards that do those functions. We can devote a port to VCP functionality instead, but it'll be a 10G limit instead of 32G The VCP ports are 32Gbps single direction in each port. So in the dual-ring the cables have are 32Gbps in each direction. You can see which ports are connected to what. (FPC0 is the EX4500, FPC1 is the EX4200, FPC2 is the EX4550). show virtual-chassis active-topology fpc0: -------------------------------------------------------------------------- Destination ID Next-hop 1 2(vcp-1.32768) 1(vcp-0.32768) 2 2(vcp-1.32768) fpc1: -------------------------------------------------------------------------- Destination ID Next-hop 0 0(vcp-0.32768) 2(vcp-1.32768) 2 2(vcp-1.32768) fpc2: -------------------------------------------------------------------------- Destination ID Next-hop 0 0(vcp-255/2/0.32768) 1 1(vcp-255/2/3.32768) You can monitor each of the VCP ports on each of the members. I don't think we are close to saturation. request session member 1 (ie. rlogin to the EX4200 switch). monitor int vcp-0 Interface: vcp-0, Enabled, Link is Up Encapsulation: Virtual-Chassis-Interface, Speed: 32000mbps Traffic statistics: Current delta Input bytes: 25685118521 [12138] Output bytes: 27856843010 [13204] Input packets: 33377693 [16] Output packets: 33371644 [16] Error statistics: Input errors: 0 [0] Input drops: 0 [0] Input framing errors: 0 [0] Carrier transitions: 0 [0] Output errors: 0 [0] Output drops: 0 [0] vcp-1 on FPC1 is much less usage. Still zero error stats. All switches show zero error stats on any of the respective VCP port status. I suppose further troubleshooting could be to replace the VCP cables one by one coming out of the EX4200. Its too bad that we've got the quad fiber expansion in the EX4200, another test could be to put the dual 10G expansion in it, and make those VCP ports and make the VC fabric over those ports instead. But we've got 3 member ports lit on that quad 1G fiber. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jeremy Lumby

So this brings an issue I was watching for a couple days into a new light. I have a customer that is in Rochester MN on Charter's Fiber. They have 2 locations just a couple miles apart. I was monitoring their connections before we start to do their voice on the 22nd. I was surprised to see I was getting about 0.3% loss to both locations. The loss would happen at the same times, so I was tempted to blame Charter. When Matthew posted this today it reminded me that charter is on the 4500 and I am on the 4200 just like Matthew. So I started two different tests this afternoon, and I now have gathered results for last 6 hours, so I feel confident in the result that there is loss in traffic going from the 4200 to the 4500. Test 1 was to add a static route to one of my customer's Rochester locations, so that traffic from me to them went via HE, and then Charter. The location that I added the static route to has had no loss for the past 6 hours, and the location that I did not change has continued to show 0.3% loss. Obviously the return path still takes MICE, so I do not believe traffic from the 4500 to the 4200 is having a problem. Test 2 was to start a running ping to 9 different interface IP addresses on MICE. I choose 3 from each switch to avoid the possibility that one router was an outlier and overly deprioritizing ICMP. I let that run for almost 6 hours, and all interfaces on the 4200, and the 4550 showed 0 loss, and all three on the 4500 showed 0.2% loss. Looking deeper into the data, the loss that happened on the 4500 would often happen at the same time for all three addresses. This leads me to wonder if there is possibly an issue with the stacking modules, or they are being saturated. Let me preface this by saying I am not a Juniper guy, and I may be wrong, however my understanding is that the stacking modules are 128Gig which would seem like plenty, however it is my understanding that each module has 2 ports, and each one is 64G, and then that 64G is actually in + out, and therefore a single direction of one port could get maxed out at 32G. I remember when we added the 4550 I asked if there was a way to graph the traffic on them, and I believe we were not able to. While I do not think that they are saturated, I wonder if there are small bursts that get them near to capacity that are far too short to show up on the 5 minute averages. Jeremy Lumby Minnesota VoIP 9217 17th Ave S Suite 216 Bloomington, MN 55425 Main: 612-355-7740 x211 Direct: 612-392-6814 EFax: 952-873-7425 jlumby(a)mnvoip.com From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Matthew Beckwell Sent: Monday, September 19, 2016 4:24 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants Testing against the UW iperf servebbb, but no loss running the same 10M UDP test). So this (somewhat limited) test seems to show the current path from 4200 -> 4550 is okay. ~Matthew On Mon, Sep 19, 2016 at 4:06 PM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: UW Madison operates some IPerf servers you could try against too, see: https://kb.wisc.edu/uwsysnet/page.php?id=41947 They are on the 4550, it appears, so more data points to be gleaned there. To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 20, 2016

Re: Proposed Membership and Sponsorship Model

by Jason Hanke

I've looked at this and I support the SIX style of user fees for MICE. I also very much like that the remotes can charge their own rates. This should create options for members who prefer a different style of payment (perhaps monthly with little upfront?). The other shared resource is address space. We may want to consider a cap per ASN. Perhaps 2 without board/tech committee approval? In the propose scenario there would be no direct cost to the end user for these. I'd also selfishly support membership voting rights for remote switch operators. Jay On Mon, Sep 19, 2016 at 4:56 PM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: > I fully support this model as well. (see: https://www.seattleix.net/join) > > The large expenditures of new equipment are all member growth or new > member driven. Recouping a 1/nth portion of those switch upgrade costs per > member, plus some small overhead for the rest, seems to be a totally viable > model and has worked well for SIX. (plus donations). The rest of the > expense side of the house is pennies in comparison. > > For those that don’t think an IX can be driven, at least partially by > donations, maybe review this as well: https://www.seattleix.net/ > contributors > > This simplifies things on the backend too: > - one time payment vs monthly deposits via multiple methods that someone > on MICE board would need to manage for 60+ members > - members joining the IX have an easy sell internally of one time fee vs > MRC above and beyond a cross connect (always infinitely harder to justify) > > Solves the root issue of new members and more bandwidth (higher speed > ports) driving growth, and doesn’t penalize the little guys. > > Remote switches can charge their own rates, however, still need to pay the > main core switch port costs. (https://www.seattleix.net/rules) > > -- > Andrew Hoyos > hoyosa(a)gmail.com > > > > > On Sep 19, 2016, at 2:35 PM, Justin Krejci <jkrejci(a)usinternet.com> > wrote: > > > > I am a fan of the SIX model of revenue: you pay to connect to the > exchange up front and bigger ports (ie 10-Gig) cost more than smaller (ie > 1-Gig). This fee applies to MICE core equipment only. Port costs on > extension switches are dictated by the respective extension switch > operators. > > > > As there are already many existing connected ports I would also be in > favor of retroactively charging each connected port based on their current > port type(s) in use at the time of the implementation of said fees. Already > connected organizations that want to take a bit of time to budget can make > arrangements with the board. Also, I would be in favor of implementing this > soon instead of waiting for the desired but elusive non-profit status > unless someone has knowledge of its actual pending completion. > -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net

Sept. 19, 2016

Re: Proposed Membership and Sponsorship Model

by Andrew Hoyos

I fully support this model as well. (see: https://www.seattleix.net/join) The large expenditures of new equipment are all member growth or new member driven. Recouping a 1/nth portion of those switch upgrade costs per member, plus some small overhead for the rest, seems to be a totally viable model and has worked well for SIX. (plus donations). The rest of the expense side of the house is pennies in comparison. For those that don’t think an IX can be driven, at least partially by donations, maybe review this as well: https://www.seattleix.net/contributors This simplifies things on the backend too: - one time payment vs monthly deposits via multiple methods that someone on MICE board would need to manage for 60+ members - members joining the IX have an easy sell internally of one time fee vs MRC above and beyond a cross connect (always infinitely harder to justify) Solves the root issue of new members and more bandwidth (higher speed ports) driving growth, and doesn’t penalize the little guys. Remote switches can charge their own rates, however, still need to pay the main core switch port costs. (https://www.seattleix.net/rules) -- Andrew Hoyos hoyosa(a)gmail.com > On Sep 19, 2016, at 2:35 PM, Justin Krejci <jkrejci(a)usinternet.com> wrote: > > I am a fan of the SIX model of revenue: you pay to connect to the exchange up front and bigger ports (ie 10-Gig) cost more than smaller (ie 1-Gig). This fee applies to MICE core equipment only. Port costs on extension switches are dictated by the respective extension switch operators. > > As there are already many existing connected ports I would also be in favor of retroactively charging each connected port based on their current port type(s) in use at the time of the implementation of said fees. Already connected organizations that want to take a bit of time to budget can make arrangements with the board. Also, I would be in favor of implementing this soon instead of waiting for the desired but elusive non-profit status unless someone has knowledge of its actual pending completion.

Sept. 19, 2016