- mice-discuss - lists.micemn.net

MICE Google Global cache issues?

by Colin Murphy

Hi, Since Monday we've been having issues with mobile devices accessing YouTube and Google Play store via IPv6. Our symptoms with YouTube app is mostly with Apple IOS devices. When a user loads a video, the ads will play fine and then the video will start and play for 5 seconds and stop. Browsing youtube via a web browser on the IOS devices seems fine. With Android devices, users can't download apps from the play store. Is anyone else experiencing these issues with their peering with the Google Global Cache at MICE? Thanks, Colin Murphy Sr. Network Engineer Office of Information Technology University of Minnesota Northern Lights Gigapop Desk: 612-626-0870

April 4, 2018

Re: Broadcast Traffic

by Ben Wiechman

Agreed on both the passive configuration for the route servers and implementation suggestions. Ben Wiechman Director of IP Strategy and Engineering Direct: 320.256.0184 Cell: 320.247.3224 ben.wiechman(a)arvig.com 150 Second Street SW | Perham, MN 56573 | arvig.com On Tue, Apr 3, 2018 at 9:23 AM, Michael Hare <michael.hare(a)wisc.edu> wrote: > My 2c is proceed but consider the following > > 1) space out changes the route servers by a day or so. > 2) force reset bgp on the changed route server. > > As someone who has previously screwed up control plane BGP filters (such > that sessions only came up if remove side was active), I believe step #2 > will shake out anyone who has their control plane filters wrong. Not > really MICE's fault per se, but a nice gesture. > > -Michael > > >>-----Original Message----- > >>From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf > >>Of Richard Laager > >>Sent: Tuesday, April 03, 2018 12:56 AM > >>To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > >>Subject: Re: [MICE-DISCUSS] Broadcast Traffic > >> > >>On 04/02/2018 11:23 PM, Andrew Hoyos wrote: > >>> I’d vote for passive BGP sessions (v4/v6) on the route servers across > the > >>board, already established or not. Easy solution to the issue at hand > and sane > >>default. “Quiet unless spoken to”. > >> > >>This is what I was thinking too. > >> > >>-- > >>Richard >

April 3, 2018

Re: Broadcast Traffic

by Michael Hare

My 2c is proceed but consider the following 1) space out changes the route servers by a day or so. 2) force reset bgp on the changed route server. As someone who has previously screwed up control plane BGP filters (such that sessions only came up if remove side was active), I believe step #2 will shake out anyone who has their control plane filters wrong. Not really MICE's fault per se, but a nice gesture. -Michael >>-----Original Message----- >>From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf >>Of Richard Laager >>Sent: Tuesday, April 03, 2018 12:56 AM >>To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >>Subject: Re: [MICE-DISCUSS] Broadcast Traffic >> >>On 04/02/2018 11:23 PM, Andrew Hoyos wrote: >>> I’d vote for passive BGP sessions (v4/v6) on the route servers across the >>board, already established or not. Easy solution to the issue at hand and sane >>default. “Quiet unless spoken to”. >> >>This is what I was thinking too. >> >>-- >>Richard

April 3, 2018

Re: Broadcast Traffic

by Richard Laager

On 04/02/2018 11:23 PM, Andrew Hoyos wrote: > I’d vote for passive BGP sessions (v4/v6) on the route servers across the board, already established or not. Easy solution to the issue at hand and sane default. “Quiet unless spoken to”. This is what I was thinking too. -- Richard

April 3, 2018

Re: Broadcast Traffic

by Andrew Hoyos

On Apr 2, 2018, at 11:03 PM, Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > > Yes, that is an option. > > So, you're suggesting that we kick over the non-configured IPv6 peers > over to passive BGP on the BIRD6 side? I don't think that should be a > default option, although I don't think it matters too much if it is > BIRD trying to initiate the BGP or the client. I’d vote for passive BGP sessions (v4/v6) on the route servers across the board, already established or not. Easy solution to the issue at hand and sane default. “Quiet unless spoken to”. Many other IX’s do this by default (AMSIX, SIX, Denver-IX, etc). I’m not sure I see any downsides to this behavior. -- Andrew Hoyos hoyosa(a)gmail.com

April 3, 2018

Re: Broadcast Traffic

by Doug McIntyre

On Mon, Apr 02, 2018 at 10:57:08AM -0500, Richard Laager wrote: >Can BIRD be configured to be passive with BGP? That is, it would respond to the participant’s router starting the session, but never try to initiate a session. Yes, that is an option. So, you're suggesting that we kick over the non-configured IPv6 peers over to passive BGP on the BIRD6 side? I don't think that should be a default option, although I don't think it matters too much if it is BIRD trying to initiate the BGP or the client. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

April 3, 2018

MN VoIP Extension switch link upgrade

by Jeremy Lumby

On Saturday 4/7/2018 at approx 2pm MN VoIP will be cutting the link to their MICE extension switch from 10G to 40G. BGP will be blocked ahead of time to allow traffic to gracefully reroute. The estimated downtime will be less than 5 minutes. 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

April 2, 2018

Re: Broadcast Traffic

by David Farmer

While I support looking into the source of broadcast and multicast traffic and eliminating any that is unnecessary. I'd also like to add a little perspective; we (AS57) currently on our MICE interface are receiving about 1.5Mpps and sending about 1Mpps, for a total of about 2.5Mpps on our interface. So even at 100pps that is (100/2,500,000) or 0.004% broadcast traffic. So let's not panic either. Thanks. On Mon, Apr 2, 2018 at 10:41 AM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: > +1 to AMSIX guidelines. > > For context, on our port, I’m seeing about 80pps of broadcast/multicast > traffic, with a fairly recent jump. > > FWIW, for comparison purposes: > SIX - ~10pps > NWAX - ~30pps > Equinix ORD - ~200pps (this is likely lots of ARP fail due to current IP > Migration, previous levels were ~60pps) > MadIX - 3pps > MKEIX - 1pps > > I just checked what some of the spew was, and it seems like a large > majority of it was the pair of RR’s sending out neighbor solicitation > messages. > Is there some timers we can adjust on those? > > > > > > — > Andrew Hoyos > hoyosa(a)gmail.com > > > > On Apr 2, 2018, at 10:30 AM, Jeremy Lumby <jlumby(a)MNVOIP.COM> wrote: > > I have been watching the broadcast traffic on MICE steadily increase. We > are now at the point where our broadcast traffic is 10X that of many > exchanges that are larger than us. I would encourage the membership to > look over the configuration of their peering routers to make sure that they > are configured in a way that they are not generating excessive broadcast > traffic. In the past on the list we have referenced the Amsterdam Internet > Exchange configuration guidelines. I feel that the router specific > configuration hints are a great starting point to be sure that your router > is configured properly. https://ams-ix.net/technical/ > specifications-descriptions/config-guide > > > Jeremy Lumby > Minnesota VoIP > 9217 17th Ave S > <https://maps.google.com/?q=9217+17th+Ave+S+Suite+216+Bloomington,+MN+55425&…> > Suite 216 > <https://maps.google.com/?q=9217+17th+Ave+S+Suite+216+Bloomington,+MN+55425&…> > Bloomington, MN 55425 > <https://maps.google.com/?q=9217+17th+Ave+S+Suite+216+Bloomington,+MN+55425&…> > Main: 612-355-7740 x211 <(612)%20355-7740> > Direct: 612-392-6814 <(612)%20392-6814> > EFax: 952-873-7425 <(952)%20873-7425> > jlumby(a)mnvoip.com > > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

April 2, 2018

Re: Broadcast Traffic

by Richard Laager

Can BIRD be configured to be passive with BGP? That is, it would respond to the participant’s router starting the session, but never try to initiate a session. -- Richard

April 2, 2018

Re: Broadcast Traffic

by Ben Wiechman

Can you post a list and/or communicate with the SP that are not set up for peering and let them either fix it or indicate whether they have any immediate plans to implement IPv6 peering. Maybe make it an onboarding question for new peers - do you intend to peer with the route servers using IPv6 and configure BIRD appropriate for new members? If off document the process to request IPv6 be turned up. Ben Wiechman Director of IP Strategy and Engineering Direct: 320.256.0184 Cell: 320.247.3224 ben.wiechman(a)arvig.com 150 Second Street SW | Perham, MN 56573 | arvig.com On Mon, Apr 2, 2018 at 10:52 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > On Mon, Apr 02, 2018 at 10:41:37AM -0500, Andrew Hoyos wrote: > >> I just checked what some of the spew was, and it seems like a large >> majority of it was the pair of RR’s sending out neighbor solicitation >> messages. >> Is there some timers we can adjust on those? >> > > > I think a lot of it is from BIRD6 looking for route peers that aren't > there. > > Traditionally, we've configured up IPv4 & IPv6 dual stack route peers in > the route > servers. > > Doing a tcpdump on the ICMP6 protocol traffic on them, it is all > ICMPv6 ND looking for route peers that aren't configured on the far end. > Should we disable all the IPv6 route peers that people aren't using? > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades >

April 2, 2018