September 2016 - mice-discuss

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

by Doug McIntyre

On Mon, Sep 19, 2016 at 01:49:52PM -0500, Matthew Beckwell wrote: > I'm seeing the loss on traffic going from 4200 to 4500. > (Whether it's egress of the 4200 or 4500 ingress, i'm not sure). > > I'm not 100% sure I know what the infrastructure looks like now-- are there > two 4500's? Yes, there is a VC stack of EX4200 EX4500 EX4550 To summarize what Matthew has told me. EX4200 -> EX4200 no UDP packet loss EX4200 -> EX4500 Small ammount of UDP packet loss EX4500 -> EX4200 No detected UDP packet loss EX4500 -> EX4500 no UDP packet loss -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Sept. 19, 2016

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

by Levi Pederson

Mathew, We have a server up in 511 and would be interested in looking into assisting however we can. We'll most likely be up in 511 soon. I can keep you informed. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipederson(a)mankatonetworks.net On Mon, Sep 19, 2016 at 1:49 PM, Matthew Beckwell <matthewb(a)aitech.net> wrote: > Hi Levi, > I'm seeing the loss on traffic going from 4200 to 4500. > (Whether it's egress of the 4200 or 4500 ingress, i'm not sure). > > I'm not 100% sure I know what the infrastructure looks like now-- are > there two 4500's? > > As to whether there's loss to one of the "remote" switches, I'm not > sure.... > If one of the Neutral Path/Mankato Networks/ CNS connected participants > would be up for running iperf for a little while, we could find out fairly > quickly. > > ~Matthew > > *Matthew Beckwell* - V.P. - Network Operations > Advanced Integrated Technologies > Office: + > *1.952.829.5511 <1.952.829.5511> x204*E-Mail: matthewb(a)aitech.net > > > On Mon, Sep 19, 2016 at 1:43 PM, Levi Pederson < > levipederson(a)mankatonetworks.net> wrote: > >> Mathew, >> >> Is the dropped traffic crossing the Exchange from the 4200 to one of the >> other switches or is it random? >> >> Thank you, >> >> >> *Levi Pederson* >> Mankato Networks LLC >> cell | 612.481.0769 >> work | 612.787.7392 >> levipederson(a)mankatonetworks.net >> >> >> On Mon, Sep 19, 2016 at 1:37 PM, Matthew Beckwell <matthewb(a)aitech.net> >> wrote: >> >>> Greetings, >>> I wanted to see if anyone here has any thoughts on a small amount (<1%) >>> of packet loss I've been trying to chase down, specific to the MICE EX4200 >>> switch. >>> >>> Aitech/AS13746 has a 1G copper port on the EX4200 switch. It seems >>> that we're seeing a small amount of outbound packet loss (1G to 10G) >>> going participants outside of the EX4200 switch. >>> >>> I might expect this going from 10G to 1G (inbound for us), but it's the >>> opposite where we see the problem: 1G to 10G participants. >>> >>> Doug at ipHouse (ge-1/0/3 on the EX4200) fired up iperf and we did some >>> testing. They're in the same situation: Loss leaving the EX4200. >>> Specifically, I was testing over to US Internet (xe-0/0/14) but seeing it >>> via Onvoy as well. >>> >>> The iperf test I was running was UDP, bandwidth of 69000, and packet >>> size of 172, running in both directions. Essentially--emulating a G.711 >>> SIP call (which is how I noticed the loss). I tested with no loss in both >>> directions within the EX4200. >>> >>> Doug mentioned: >>> >>> >I pulled the VC chassis stats, but it has nothing for drops or >>> re-transmits for it. >>> >>> Maybe some of our Juniper-centric members have suggestions? It's quite >>> possible it's always been like this-- the loss is small enough that's >>> managed to evade monitoring. I suspect everyone on the EX4200 is affected. >>> >>> ~Matthew >>> >>> >>> ------------------------------ >>> >>> To unsubscribe from the MICE-DISCUSS list, click the following link: >>> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >>> >> >> >> ------------------------------ >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >> > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Sept. 19, 2016

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

by Matthew Beckwell

Hi Levi, I'm seeing the loss on traffic going from 4200 to 4500. (Whether it's egress of the 4200 or 4500 ingress, i'm not sure). I'm not 100% sure I know what the infrastructure looks like now-- are there two 4500's? As to whether there's loss to one of the "remote" switches, I'm not sure.... If one of the Neutral Path/Mankato Networks/ CNS connected participants would be up for running iperf for a little while, we could find out fairly quickly. ~Matthew *Matthew Beckwell* - V.P. - Network Operations Advanced Integrated Technologies Office: + *1.952.829.5511 x204*E-Mail: matthewb(a)aitech.net On Mon, Sep 19, 2016 at 1:43 PM, Levi Pederson < levipederson(a)mankatonetworks.net> wrote: > Mathew, > > Is the dropped traffic crossing the Exchange from the 4200 to one of the > other switches or is it random? > > Thank you, > > > *Levi Pederson* > Mankato Networks LLC > cell | 612.481.0769 > work | 612.787.7392 > levipederson(a)mankatonetworks.net > > > On Mon, Sep 19, 2016 at 1:37 PM, Matthew Beckwell <matthewb(a)aitech.net> > wrote: > >> Greetings, >> I wanted to see if anyone here has any thoughts on a small amount (<1%) >> of packet loss I've been trying to chase down, specific to the MICE EX4200 >> switch. >> >> Aitech/AS13746 has a 1G copper port on the EX4200 switch. It seems that >> we're seeing a small amount of outbound packet loss (1G to 10G) going >> participants outside of the EX4200 switch. >> >> I might expect this going from 10G to 1G (inbound for us), but it's the >> opposite where we see the problem: 1G to 10G participants. >> >> Doug at ipHouse (ge-1/0/3 on the EX4200) fired up iperf and we did some >> testing. They're in the same situation: Loss leaving the EX4200. >> Specifically, I was testing over to US Internet (xe-0/0/14) but seeing it >> via Onvoy as well. >> >> The iperf test I was running was UDP, bandwidth of 69000, and packet size >> of 172, running in both directions. Essentially--emulating a G.711 SIP >> call (which is how I noticed the loss). I tested with no loss in both >> directions within the EX4200. >> >> Doug mentioned: >> >> >I pulled the VC chassis stats, but it has nothing for drops or >> re-transmits for it. >> >> Maybe some of our Juniper-centric members have suggestions? It's quite >> possible it's always been like this-- the loss is small enough that's >> managed to evade monitoring. I suspect everyone on the EX4200 is affected. >> >> ~Matthew >> >> >> ------------------------------ >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >> > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Sept. 19, 2016

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

by Levi Pederson

Mathew, Is the dropped traffic crossing the Exchange from the 4200 to one of the other switches or is it random? Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipederson(a)mankatonetworks.net On Mon, Sep 19, 2016 at 1:37 PM, Matthew Beckwell <matthewb(a)aitech.net> wrote: > Greetings, > I wanted to see if anyone here has any thoughts on a small amount (<1%) of > packet loss I've been trying to chase down, specific to the MICE EX4200 > switch. > > Aitech/AS13746 has a 1G copper port on the EX4200 switch. It seems that > we're seeing a small amount of outbound packet loss (1G to 10G) going > participants outside of the EX4200 switch. > > I might expect this going from 10G to 1G (inbound for us), but it's the > opposite where we see the problem: 1G to 10G participants. > > Doug at ipHouse (ge-1/0/3 on the EX4200) fired up iperf and we did some > testing. They're in the same situation: Loss leaving the EX4200. > Specifically, I was testing over to US Internet (xe-0/0/14) but seeing it > via Onvoy as well. > > The iperf test I was running was UDP, bandwidth of 69000, and packet size > of 172, running in both directions. Essentially--emulating a G.711 SIP > call (which is how I noticed the loss). I tested with no loss in both > directions within the EX4200. > > Doug mentioned: > > >I pulled the VC chassis stats, but it has nothing for drops or > re-transmits for it. > > Maybe some of our Juniper-centric members have suggestions? It's quite > possible it's always been like this-- the loss is small enough that's > managed to evade monitoring. I suspect everyone on the EX4200 is affected. > > ~Matthew > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Sept. 19, 2016

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

by Matthew Beckwell

Greetings, I wanted to see if anyone here has any thoughts on a small amount (<1%) of packet loss I've been trying to chase down, specific to the MICE EX4200 switch. Aitech/AS13746 has a 1G copper port on the EX4200 switch. It seems that we're seeing a small amount of outbound packet loss (1G to 10G) going participants outside of the EX4200 switch. I might expect this going from 10G to 1G (inbound for us), but it's the opposite where we see the problem: 1G to 10G participants. Doug at ipHouse (ge-1/0/3 on the EX4200) fired up iperf and we did some testing. They're in the same situation: Loss leaving the EX4200. Specifically, I was testing over to US Internet (xe-0/0/14) but seeing it via Onvoy as well. The iperf test I was running was UDP, bandwidth of 69000, and packet size of 172, running in both directions. Essentially--emulating a G.711 SIP call (which is how I noticed the loss). I tested with no loss in both directions within the EX4200. Doug mentioned: >I pulled the VC chassis stats, but it has nothing for drops or re-transmits for it. Maybe some of our Juniper-centric members have suggestions? It's quite possible it's always been like this-- the loss is small enough that's managed to evade monitoring. I suspect everyone on the EX4200 is affected. ~Matthew

Sept. 19, 2016

FW: How do I start an Internet Exchange Point?

by Michael Hemphill

Hello MICE people, I saw this post on LinkedIn today & thought it may offer some more help and/or confusion to the current discussions. Mike Mike Hemphill ColoConnect 612-812-5242 mikeh(a)ColoConnect.net<mailto:mikeh@ColoConnect.net> [Kurt-Erik "Kurtis" Lindqvist]<https://www.linkedin.com/in/klindqvist>Kurt-Erik "Kurtis" Lindqvist<https://www.linkedin.com/in/klindqvist>CMO at LINX ( The London Internet Exchange) How do I start an Internet Exchange Point? September 17, 2016 • 13 Likes • 3 Comments I have been involved in helping a lot of Internet Exchange Points (IXPs) get of the ground and I have also been to several countries and regions to help IXPs to prosper and sometimes even to explain to the IXP, the members and the regulators why things have failed. I have helped IXPs in Europe, Asia, the Middle East and even North America. In addition to this I have together with Philip Smith and others thought numerous classes for APRICOT<http://www.apricot.net/>s, MENOG<http://www.menog.org/>s, ISOC<http://www.isoc.org/>, AfPIF<http://www.internetsociety.org/events/afpif> and others on how routing, IXPs and peering work. Because of this involvement I very often get asked advice by people wanting to establish an IXP or even newly formed IXPs. At LINX we are always very supportive of new IXPs being formed, and we try and contribute as much as we can. For those wanting to start an IXP I thought I would write up some comments that observations I have made over the years and post it here. There are already a large number of resources for new IXPs, and I will also list some of these considerations below. Establishing the IXP The hard part with establishing an IXP is not really the technical part, but building up a community and a community with trust with that. Also, an IXP needs to be sustainable beyond the establishment phase, i.e. have enough funds to operate, and in the future upgrade the equipment they need as technology develops and traffic grows. Most IXPs ensure this by setting up a mutual or membership association so that the users of the IXP have equal say in the operation of the IXP. This is by far the most successful model of IXPs today. The members pay a fee based on their port size to the association, so one fee for a 1GE port and one for a 10GE port. Not based on the actual traffic, but the port speed. The membership all have one vote each in the running of the organisation and normally appoints a board for the day to day operation of the IXP. Secondly, new IXPs tend to believe it is a good idea to offer free ports to large content networks in order to attract other members. At first glance this might seem like a good idea, but you will quickly find yourself squeezed between the content networks and the broadband operators that then also want their ports for free. Generally it is better to charge everyone equally and threat everyone equally. It might make it slightly harder for the IXP to get off the ground but it certainly makes running the IXP easier in the long run. Most of the large content owners are also quite supportive of new IXPs being formed in locations or regions where no IXP exists. Thirdly, what is very important is to ensure that the IXP does not in any way interfere with the peering arrangements across the IXP. If the members want to for example sell transit to each other across the IXP, that is fine. If someone only want to peer with a subset of the members, that is also fine. Selecting the location for your IXP Besides creating the community in order to support the IXP, the other important factor for establishing a successful IXP is the location. Successful IXPs needs to be accessible for everyone so a neutral datacenter, where any fibre infrastructure can be build in. These locations can be hard to find, but are very critical for the success. The wider the choice of fibre providers (or wlan for that matter in some parts of the world) and choice of carriers that are available, the better. Datacenters owned by current or former incumbents are not good choices as they generally tend to be very restrictive in what choice of infrastructure providers they offer. Besides easy infrastructure access, the datacenter also needs to provide a stable power feed, or you need to ensure you have UPSes and perhaps even generators (depending on ambition, stability of power grid and if the datacenter provides generator power). Also make sure there is room to grow the IXP. You might only two racks to start with, but if you are successful you might need more and moving the IXP is always painful. What type of switch do I need? There is an excellent presentation<http://ripe71.ripe.net/presentations/30-1000-dollar-exchange-ripe71.pdf> by Remco van Mook that covers many of the same topics as this post, and that also points out that ~50% of IXPs carry less than 20Gbps of traffic. As a new start-up IXP you will most certainly carry less than 20Gbps. What you need is a switch that will support 1GE and 10GE ports, preferably via SFPs, not an expensive and large switch with massive amount of features (although the vendors will try and sell you one). Instead, make sure you get a switch that you can manage and that you can monitor. These are the most important components of an IXP switch. Co-location of services For the benefit of the membership of your IXP as well as the local Internet community, you should co-locate some critical shared resources with the IXP. The most important ones are * The local ccTLD slave service (i.e .uk, .fr, .sg, .bd etc). If the ccTLD registry is supportive of the IXP, the contact them and ask if they are willing to locate one of their unicast slaves behind your IXP router. Never connect the DNS slaves directly to IXP L2 domain. * It is likely that the ccTLD registry also uses an anycast provider for their slave service. In that case it might be worth contacting that DNS anycast provider and ask them to connect to the IXP. You should in any cast contact the DNS anycast providers as they are more than happy to peer at many of the IXPs. Many of these also operate or provide service to one the DNS root-servers. These are a critical part of the internet infrastructure and having one co-located with your IXP will provide a lot of value to your local Internet community. PCH<http://www.pch.net/>, Verisign<http://www.verisign.com/> and Netnod<http://www.netnod.se/> are some of the DNS Anycast providers that locate nodes around the world. * Route-servers are also important to offer to your members, especially as you start to grow. The most stable software for route-servers today is BIRD<http://bird.network.cz/>. Providing two route-servers also adds redundancy as if one fails, the peering sessions will go down. Last, some IXPs offer NTP services as part of the IXP to their community. This is a very good service, and something that the community should make use of. However, for a new start-up IXP, NTP services is quite expensive to provide and definitely not needed at the first stage. Managing my IXP and members The guys over at INEX<http://www.inex.ie/> has created an amazing tool called The IXP Manager<http://www.inex.ie/ixp/index/about> that provides you all the software you need to mange your IXP and the tools for your members. This is really an amazing resource that you should use for setting up the IXP! How do I know if my IXP is a success? What makes an IXP successful varies very much from each individual case. A small land-locked country where all ISPs or Internet Operators are forced to use Satellite capacity for Internet access will benefit enormously from an IXP no matter how little traffic that is exchanged, as each bit is a huge saving! Value of peering is always in the eye of the beholder. Access to one single route or Internet prefix can be extremely valuable to one ISP, while another might need large traffic volumes before it creates value to them. In the end a successful IXP is defined by the membership. If there is a community that uses and continuous to see benefit from the IXP they will continue to support it. By being stable and sustainable the IXP is successful! Other resources IXP Associations * IX-F<http://www.ix-f.net/> * Euro-IX<http://www.euro-ix.net/> * APIX<http://apix.asia/> * LACIX<http://www.lac-ix.net/> * AF-IX<http://www.af-ix.net/> The IXP toolkit<http://www.ixptoolkit.org/> is a collection of resources for IXPs. The Euro-IX movie<http://youtu.be/QuBde4Sn3f0> is a great resource for explaining in a non-technical manner how an IXP works and what it does. You are always welcome to contact me for questions and advice! Written by [Kurt-Erik "Kurtis" Lindqvist]<https://www.linkedin.com/in/klindqvist>Kurt-Erik "Kurtis" Lindqvist<https://www.linkedin.com/in/klindqvist>CMO at LINX ( The London Internet Exchange) 3 comments [ ] 2h [https://media.licdn.com/mpr/mpr/shrink_100_100/AAEAAQAAAAAAAAltAAAAJDMwNWY0…]<https://www.linkedin.com/in/ivanbev> Ivan Beveridge<https://www.linkedin.com/in/ivanbev> Seeking network/systems opportunities in… Typo correction: Establishing the IXP .... "Generally it is better to charge everyone equally and threat everyone equally" - threat -> treat LikeReply 2h [https://media.licdn.com/mpr/mpr/shrink_100_100/p/2/000/03f/0cb/2aae6f1.jpg]<https://www.linkedin.com/in/muhammad-aslam-1868a15> Muhammad Aslam<https://www.linkedin.com/in/muhammad-aslam-1868a15> Chief Operating Officer at ADRAS Great article - mostly the technical would agree with the points mentioned in the article including the Remco van Mook presentation in terms of the technical and costing matrix. The biggest dilemma with the developing economies would be that their consulting partner being ITU that provides different approach towards the setup of IXP , so the question would be how to convin… See more LikeReply 1 1h [https://media.licdn.com/mpr/mpr/shrink_100_100/AAEAAQAAAAAAAAltAAAAJDMwNWY0…]<https://www.linkedin.com/in/ivanbev> Ivan Beveridge<https://www.linkedin.com/in/ivanbev> Seeking network/systems opportunities in… You say "ITU that provides different approach towards the setup of IXP". Can you elaborate? What is their approach? LikeReply 1h [https://media.licdn.com/mpr/mpr/shrink_100_100/AAEAAQAAAAAAAAltAAAAJDMwNWY0…]<https://www.linkedin.com/in/ivanbev> Ivan Beveridge<https://www.linkedin.com/in/ivanbev> Seeking network/systems opportunities in… Good article, highlighting important topics and linking to additional resources. I guess the particularly tricky part comes when wishing to setup in areas where there are few/no neutral colocation centres. I suspect such instances need to be treated on a case-by-case basis; is this what you/people (eg Bill, Gaurab, etc) have found?

Sept. 17, 2016

Re: Proposed Membership and Sponsorship Model

by Steve Howard

Sept. 16, 2016

Re: Proposed Membership and Sponsorship Model

by DeLong, Owen

I would like to humbly suggest that we first focus the discussion on the revenue model we want to achieve (flat fee vs. voluntary differentiations vs. differentiated services). Once we come to consensus on that, it will be much easier to look at all the corner cases for making sure that each organization can provide money in a way that meets both our and their accounting needs. Owen > On Sep 9, 2016, at 10:09 , Ben Franske <ben.lists(a)FRANSKE.COM> wrote: > > On 9/9/2016 1:28 AM, Richard Laager wrote: >> >> Ironically, I don't think this even works for the University of >> Minnesota. I believe it was your position that you needed an invoice, as >> "the University doesn't give donations; it accepts them". > > I was actually going to bring this up, but it wasn't the U of M that had this issue, it was Wisconsin/BadgerNet. I believe they stated that even a "membership" might be problematic, but port fees could definitely be paid. > > -Ben > > Ben Franske > Inver Hills Community College (MICE via MNSCU via UMN)

Sept. 9, 2016

Re: Proposed Membership and Sponsorship Model

by Ben Franske

On 9/9/2016 1:28 AM, Richard Laager wrote: > > Ironically, I don't think this even works for the University of > Minnesota. I believe it was your position that you needed an invoice, as > "the University doesn't give donations; it accepts them". I was actually going to bring this up, but it wasn't the U of M that had this issue, it was Wisconsin/BadgerNet. I believe they stated that even a "membership" might be problematic, but port fees could definitely be paid. -Ben Ben Franske Inver Hills Community College (MICE via MNSCU via UMN)

Sept. 9, 2016

Wikstrom Telephone MICE Port Move

by Jason Hanke

Wikstrom Telephone is moving their connection from the Mankato Networks Remote Switch to the Main Switch The new port will be xe-2/0/6 on the main stack. IP information will remain the same. Welcome aboard (again)! -- 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. 9, 2016