- mice-discuss - lists.micemn.net

Re: Fwd: Google - Drain of routes for Route-Servers in your IX

by Anthony Anderberg

Yes, in last fall’s meeting we reminded everyone that they needed to create bilateral sessions with Google right away if they hadn’t already done so. From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Jeremy Lumby <jlumby(a)MNVOIP.COM> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Date: Wednesday, April 3, 2024 at 2:38 PM To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Fwd: Google - Drain of routes for Route-Servers in your IX They did it to MICE back in December From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Wednesday, April 3, 2024 2:32 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Fwd: Google - Drain of routes for Route-Servers in your IX I haven't heard this for MICE, but presumably they will be doing the same thing here? -------- Forwarded Message -------- Subject: Google - Drain of routes for Route-Servers in your IX (fwd) Date: Wed, 3 Apr 2024 14:31:55 +0000 (UTC) From: Chris Caputo <ccaputo(a)seattleix.net><mailto:ccaputo@seattleix.net> To: members(a)seattleix.net<mailto:members@seattleix.net> FYI from Google... Chris ---------- Forwarded message ---------- Date: Wed, 03 Apr 2024 04:21:02 -0700 From: Google Peering Operations <peering-ops(a)google.com><mailto:peering-ops@google.com> To: info(a)seattleix.net<mailto:info@seattleix.net> Subject: Drain of routes for Route-Servers in your IX Dear Internet Exchange, As part of Google's effort to simplify peering operations and increase routing security we have decided to stop advertising and receiving prefix information from Route-Servers in Internet Exchanges. The BGP session with the route servers will remain established. We are planning to implement the change in your IX in the next few weeks. We won’t disconnect from the IX and we will keep current BGP bilateral sessions with individual peers on the IX. We invite other networks that rely on Route-Servers to request a bilateral session. Bilateral session request can be done at: https://isp.google.com/iwantpeering We kindly request you to inform peers in your Internet Exchange of these future changes so they can request bilateral sessions with us if they desire to do so. Sincerely, Google Network Operations ________________________________ 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

April 3, 2024

Re: Fwd: Google - Drain of routes for Route-Servers in your IX

by Jeremy Lumby

They did it to MICE back in December From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Wednesday, April 3, 2024 2:32 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Fwd: Google - Drain of routes for Route-Servers in your IX I haven't heard this for MICE, but presumably they will be doing the same thing here? -------- Forwarded Message -------- Subject: Google - Drain of routes for Route-Servers in your IX (fwd) Date: Wed, 3 Apr 2024 14:31:55 +0000 (UTC) From: Chris Caputo <mailto:ccaputo@seattleix.net> <ccaputo(a)seattleix.net> To: members(a)seattleix.net <mailto:members@seattleix.net> FYI from Google... Chris ---------- Forwarded message ---------- Date: Wed, 03 Apr 2024 04:21:02 -0700 From: Google Peering Operations <mailto:peering-ops@google.com> <peering-ops(a)google.com> To: info(a)seattleix.net <mailto:info@seattleix.net> Subject: Drain of routes for Route-Servers in your IX Dear Internet Exchange, As part of Google's effort to simplify peering operations and increase routing security we have decided to stop advertising and receiving prefix information from Route-Servers in Internet Exchanges. The BGP session with the route servers will remain established. We are planning to implement the change in your IX in the next few weeks. We won’t disconnect from the IX and we will keep current BGP bilateral sessions with individual peers on the IX. We invite other networks that rely on Route-Servers to request a bilateral session. Bilateral session request can be done at: https://isp.google.com/iwantpeering We kindly request you to inform peers in your Internet Exchange of these future changes so they can request bilateral sessions with us if they desire to do so. Sincerely, Google Network Operations _____ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> &A=1

April 3, 2024

Re: Fwd: Google - Drain of routes for Route-Servers in your IX

by Reid Fishler

I believe its internet-wide. Reid On Wed, Apr 3, 2024 at 3:32 PM Richard Laager <rlaager(a)wiktel.com> wrote: > I haven't heard this for MICE, but presumably they will be doing the same > thing here? > -------- Forwarded Message -------- > Subject: Google - Drain of routes for Route-Servers in your IX (fwd) > Date: Wed, 3 Apr 2024 14:31:55 +0000 (UTC) > From: Chris Caputo <ccaputo(a)seattleix.net> <ccaputo(a)seattleix.net> > To: members(a)seattleix.net > > FYI from Google... > > Chris > > ---------- Forwarded message ---------- > Date: Wed, 03 Apr 2024 04:21:02 -0700 > From: Google Peering Operations <peering-ops(a)google.com> > <peering-ops(a)google.com> > To: info(a)seattleix.net > Subject: Drain of routes for Route-Servers in your IX > > Dear Internet Exchange, > > As part of Google's effort to simplify peering operations and increase > routing security we have decided to stop advertising and receiving prefix > information from Route-Servers in Internet Exchanges. The BGP session with > the route servers will remain established. We are planning to implement the > change in your IX in the next few weeks. > > We won’t disconnect from the IX and we will keep current BGP bilateral > sessions with individual peers on the IX. We invite other networks that > rely on Route-Servers to request a bilateral session. Bilateral session > request can be done at: https://isp.google.com/iwantpeering > > We kindly request you to inform peers in your Internet Exchange of these > future changes so they can request bilateral sessions with us if they > desire to do so. > > Sincerely, > Google Network Operations > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- Reid Fishler Senior Director Hurricane Electric +1-510-580-4178

April 3, 2024

Fwd: Google - Drain of routes for Route-Servers in your IX

by Richard Laager

I haven't heard this for MICE, but presumably they will be doing the same thing here? -------- Forwarded Message -------- Subject: Google - Drain of routes for Route-Servers in your IX (fwd) Date: Wed, 3 Apr 2024 14:31:55 +0000 (UTC) From: Chris Caputo <ccaputo(a)seattleix.net> To: members(a)seattleix.net FYI from Google... Chris ---------- Forwarded message ---------- Date: Wed, 03 Apr 2024 04:21:02 -0700 From: Google Peering Operations <peering-ops(a)google.com> To: info(a)seattleix.net Subject: Drain of routes for Route-Servers in your IX Dear Internet Exchange, As part of Google's effort to simplify peering operations and increase routing security we have decided to stop advertising and receiving prefix information from Route-Servers in Internet Exchanges. The BGP session with the route servers will remain established. We are planning to implement the change in your IX in the next few weeks. We won’t disconnect from the IX and we will keep current BGP bilateral sessions with individual peers on the IX. We invite other networks that rely on Route-Servers to request a bilateral session. Bilateral session request can be done at: https://isp.google.com/iwantpeering We kindly request you to inform peers in your Internet Exchange of these future changes so they can request bilateral sessions with us if they desire to do so. Sincerely, Google Network Operations

April 3, 2024

Please welcome MIDnet LLC Network to MICE!

by Jeremy Lumby

Name: MIDnet LLC Switch: NOCIX Ports: E 5/16 ASN: 16970 IPv4: 206.108.255.230/24 IPv6: 2001:504:27:0:0:424A::1/64 Peering Contact: noc(a)mid.net Route Servers: YES Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

March 29, 2024

Please welcome Qwilt Inc. to MICE!

by Jeremy Lumby

Name: Qwilt Inc. Switch: MICE Core 511 Ports: 5/2/1 in portchannel 12 for a total of 2x100G ASN: 20253 IPv4: All IP info remains the same, this is a 100G port addition IPv6: Peering Contact: peering(a)qwilt.com Route Servers: YES Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

March 27, 2024

Please welcome Mankato Networks to MICE!

by Jeremy Lumby

Name: Mankato Networks Switch: MICE Core - 511 Ports: E 4/38 in portchannel 32 for a total of 2x10G ASN: This is a remote switch uplink upgrade; all other info remains the same IPv4: IPv6: Peering Contact: peering(a)mankatonetworks.net Route Servers: Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

March 26, 2024

Please welcome Fort Dodge Fiber to MICE!

by Jeremy Lumby

Name: City of Fort Dodge dba Fort Dodge Fiber Switch: SouthFront Networks Ports: E 5/2 for a total of 1x10G ASN: 400405 IPv4: 206.108.255.229/24 IPv6: 2001:504:27:0:6:1C15::1/64 Peering Contact: noc(a)fortdodgefiber.net Route Servers: YES Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

March 26, 2024

Please welcome Starwire Technologies to MICE!

by Jeremy Lumby

Name: Starwire Technologies, LLC Switch: MICE Core - Ridgeview Ports: E 3/31/4 Strands 127-128 for a total of 1x10G ASN: 16614 IPv4: 206.108.255.227/24 IPv6: 2001:504:27:0:0:40E6::1/64 Peering Contact: info(a)starwire.net Route Servers: YES Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

March 26, 2024

Re: MICE interface flap

by Jeremy Lumby

I did get more information from Arista related to the bug that caused the other cards to restart/ports to flap a month ago. It is still in progress, so not everything is published in its final state yet. It comes down to swapping in a R2 card in a chassis that has mostly R1 cards in it. BUG 916990 Release Note: When Linecard of a SKU is swapped with Linecard of different SKU, SandFap agent corresponding to other Linecards on the chassis may restart 1 time. There is no workaround, recommendation is the perform the SKU swap during a maintenance window In our situation, this is the summary: Agent restarted when we replaced 7500-R with 7500-R2 because the SPPID binding was already present for a different VOQ. Agent restart happens to clear out this binding to allocate it properly with the 7500-R2 linecard. More information about the bug: The forwarding chip has a Traffic Manager that does destination lookup table that provides a destination based on a globally known ID called systemPhyPortID (SPPID). This SystemPhyPortID (SPPID) uniquely identifies the Virtual Output Queues (VOQ) that the packet will get inserted into and the final forwarding chip port the packet will be sent towards. The software binding of Traffic Manager's destination lookup table corresponding to SPPID of MeshDrop port wasn't cleaned up during removal of 7500-R card. When 7500-R2 card was inserted this SPPID got allocated to the front panel port. When programming on an existing slice agent (the cards which were already present on the switch) triggered for this Front panel port, the code asserted about binding already present for this SPPID with a different VOQ (MeshDrop port's VOQ), causing the slice agent to restart. Jeremy -----Original Message----- From: Jeremy Lumby <jlumby(a)mnvoip.com> Sent: Wednesday, February 21, 2024 4:54 PM To: 'MICE Discuss' <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Subject: RE: [MICE-DISCUSS] MICE interface flap A quick update. I just heard from Arista support that the interface flap last week was the result of a new bug that they are currently working out the details of. At the moment I have no further information about the details. -----Original Message----- From: Jeremy Lumby <jlumby(a)mnvoip.com> Sent: Friday, February 16, 2024 9:44 AM To: 'MICE Discuss' <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Subject: RE: [MICE-DISCUSS] MICE interface flap It will be interesting when Arista responds. It sounds very similar. The week before we upgraded to 4.30.5M to prepare for the new card (7500R2-36CQ-LC). -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Frank Bulk Sent: Friday, February 16, 2024 9:03 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE interface flap Thanks for sharing, we definitely saw this, too. We had a *somewhat* similar issue last year that when we slotted a card into our 7504 and the other card rebooted. Turned out to be some kind of mesh bug. Bug ID 765840 resolved in 4.30.1. Frank -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Wednesday, February 14, 2024 4:57 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE interface flap I am still sorting out the details. But it was related to the card swap scheduled for today. The card was in up and running without an issue for several minutes, however when I programmed/moved the first link to it, all of the other cards in the core switch started rebooting themselves. I am opening a ticket with Arista since we seem to be stable at the moment. -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Chris Wopat Sent: Wednesday, February 14, 2024 4:56 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] MICE interface flap WiscNet's remote switch flapped twice within the last half hour: Feb 14 16:34:16.657 2024 s-minneapolis-hub mib2d[8448]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 540, ifAdminStatus up(1), ifOperStatus down(2), ifName et-0/0/23 Feb 14 16:39:29.456 2024 s-minneapolis-hub mib2d[8448]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 540, ifAdminStatus up(1), ifOperStatus down(2), ifName et-0/0/23 Aggregate traffic definitely shows a hit: https://link.edgepilot.com/s/5abcf6c9/_Ox0o9rFAUimx0FLu4zJ0g?u=http://micel… Curious if others experienced flaps or could reveal logs from the core Arista? -- Chris Wopat Network Engineer, WiscNet wopat(a)wiscnet.net 608-210-3965 Links contained in this email have been replaced. If you click on a link in the email above, the link will be analyzed for known threats. If a known threat is found, you will not be able to proceed to the destination. If suspicious content is detected, you will see a warning.

March 19, 2024