- mice-discuss - lists.micemn.net

Fwd: [arin-announce] Reminder of Upcoming Deadline for ARIN’s Multifactor Authentication (MFA) Enforcement for ARIN Online
by David Farmer Sept. 9, 2024

Sept. 9, 2024

If you still need to enable MFA on your ARIN Online Account, DO IT NOW! More than 15,000 ARIN Online Accounts have yet to enable MFA, which is nuts! Thanks. ---------- Forwarded message --------- From: ARIN <info(a)arin.net> Date: Mon, Sep 9, 2024 at 11:25 AM Subject: [arin-announce] Reminder of Upcoming Deadline for ARIN’s Multifactor Authentication (MFA) Enforcement for ARIN Online To: <arin-announce(a)arin.net> On 7 October 2024, ARIN will lock all remaining ARIN Online accounts that have not enabled multifactor authentication (MFA). As of 1 February 2023, ARIN requires MFA on all new ARIN Online accounts. Users with accounts created before February 2023 were notified and encouraged to log in at their earliest opportunity, where they would be prompted to set up MFA. This step was taken to provide stronger security for the registry, reduce the risk of fraud, and increase confidence in the integrity of their ARIN resources. On 17 July, we announced that ARIN was continuing to take steps to secure the registry by enforcing MFA. We engaged in direct communications with 19,853 account holders linked to organizations with direct allocations, detailed reassignments, and reallocations who had not yet enabled MFA on their accounts. These users were notified that they needed to set up MFA within 60 days or their accounts would be locked, As of 4 September 2024, 15,593 accounts have not completed MFA setup. We are extending this deadline by two weeks to allow more time for account holders to enable MFA on existing accounts. We strongly encourage ARIN Online account holders who have not set up MFA to do so before the 7 October deadline. Users with locked accounts can contact Registration Services during ARIN operating hours, 7:00 AM to 7:00 PM ET Monday through Friday, to unlock and set up MFA and regain access to ARIN Online. ARIN relies on the support of its customers to ensure the accuracy and security of the registry. We rely on all our customers to follow best practices for account security and to report any suspicious activity to us immediately. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) --------- Helpful Resources: Need help setting up your MFA? Visit https://www.arin.net/MFA to get started. You’ll find guides on enabling MFA via an authenticator application, SMS, or security key hardware. We also provide information on how to receive and save your MFA recovery codes, as well as what to do if you’ve lost access to your authenticator app, SMS phone number, or security key. -- =============================================== 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 ===============================================

1 0

Odd AWS transfer issue
by Danny Meister Sept. 7, 2024

Sept. 7, 2024

8 11

New QCIX Mailing Lists
by Jay Hanke Sept. 6, 2024

Sept. 6, 2024

For those that are interested, QCIX has just added mailing lists. https://qcix.mailman3.com/ -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 507-327-2398 https://southfront.io/ <https://southfront.io/path.html>

1 0

Fwd: [Idr] [job@fastly.com: RFC 9234 route leak prevention in the wild!]
by David Farmer Sept. 4, 2024

Sept. 4, 2024

I think this is something we should add to our list Thanks ---------- Forwarded message --------- From: Job Snijders <job=40fastly.com(a)dmarc.ietf.org> Date: Mon, Sep 2, 2024 at 8:36 AM Subject: [Idr] [job(a)fastly.com: RFC 9234 route leak prevention in the wild!] To: <idr(a)ietf.org> Hello IDR, You might enjoy a report back from the field on route leak blocking based on RFC 9234. Please see below. Kind regards, Job ----- Forwarded message from Job Snijders <job(a)fastly.com> ----- Date: Mon, 2 Sep 2024 13:33:00 +0000 From: Job Snijders <job(a)fastly.com> To: nanog(a)nanog.org Subject: RFC 9234 route leak prevention in the wild! Dear all, I'd like to share an update on RFC 9234 deployment. RFC 9234 titled "BGP Open Policy" aka the "Only-To-Customer" (OTC) BGP Path Attribute is an anti-route-leak mechanism which is *NOT* based on RPKI! (yes ... routing security is more than just RPKI! :-) The basic idea of 9234 is that BGP routers (based on their role in the Gao-Rexford inter-domain routing model) attach a special BGP Path attribute, or take action based on the presence and contents of this BGP Path attribute - with the intention to constrain a route's propagation radius to just the downstream customer cone of the neighboring ASN. Most operators will intuitively understand that any route propagating through multiple IX route servers operated by different IXPs is a route leak: ``` IXP_1 IXP_2 / \ / \ / \ / \ ISP_A ISP_B ISP_C (receives) (leaker) (originates) ``` (figure 1. propagation from right to left; leak scenario) In the above example, ISP_A originates a route towards IXP_1's route servers, IXP_1 propagates the route to ISP_B (so far so good); but for one reason or another ISP_B subsequently continues propagation of the route towards IXP_2's route servers, who in turn propagate it to ISP_C. ISP_B is forwarding IP traffic between ISP_A and ISP_C for zero revenue. ISP_A and ISP_C are probably not expecting ISP_B to be in the middle. This situation can happen as a result of a misconfiguration in ISP_B's equipment, even when all participants use IRR & RPKI ROV to attempt to mitigate the worst routing incidents. What does it matter / impact ============================ Calgary-based YYCIX deployed RFC9234 support in late 2022/early 2023 using OpenBGPD; and FranceIX deployed support using BIRD in Q2 2024. Both IXPs configured their route servers to reject BGP routes that have an OTC attribute attached, and to attach an OTC attribute when propagating routes to the Route Server's peers. As it happens to be, currently (Mon Sep 2 12:26:50 UTC 2024) a small route leak is happening involving both YYCIX and FranceIX Route Servers via an ISP connected to both IXP's Route Servers; with the leak being stopped at YYCIX thanks to RFC 9234! Appendix A contains a table of leaked IPv4 routes. Let's zoom in on 1 entry: ``` $ bgpctl show rib 157.185.154.0/24 detail BGP routing table entry for 157.185.154.0/24 6939 38040 54994 Nexthop 206.126.225.20 (via 206.126.225.20) Neighbor 206.126.225.20 (216.218.252.194) Origin IGP, metric 1911, localpref 100, weight 0, ovs not-found, avs unknown, external, otc leak Last update: 11:58:08 ago Communities: 0:2906 0:16265 0:16276 0:18638 0:41690 0:48641 0:49029 Ext. Communities: ovs not-found Large Communities: 53339:11:1 53339:11:3 Aggregator: 54994 [163.171.131.254] OTC: 51706 ``` (figure 2. inspecting an leaked route using OpenBGPD's CLI) In figure 2. one can see the route is marked as 'otc leak', this was made possible because FranceIX's route server's attached the OTC attribute with the ASN value set to their Route Server's ASN (51706). ``` YYCIX FranceIX . x <adds OTC> \ . \ / \ ISP_A 6939_38040 54994 ``` (figure 3. right to left: real world example of blocked leak) In figure 3 AS 54994 originates 157.185.154.0/24 and propagates a route towards the FranceIX route servers. FranceIX accepts this route (probably because an IRR route object exists) and propagates it onward with the "Only-To-Customer" attribute set to 51706. The route is received by AS 38040, who appear to propagate the route to their upstream 6939. << An AS 38040 router is likely misconfigured! >> Then 6939 sends its customer's routes to the YYCIX route server, but the YYCIX route server recognizes that the route already passed through a 'valley' and thus considers this a leak; and blocks further propagation towards ISP_A. Impact with partial deployment ============================== RFC 9234 is an easy mechanism to configure and debug for both small & large network operators and IXP route server operators. In the above scenario YYCIX and FranceIX are likely the only 2 entities in the entire AS path which support RFC 9234; but we're already seeing leaks being blocked despite partial deployment! It's not hard to imagine that many IX-to-IX route leaks can be blocked with only the IXP operators themselves enabling RFC 9234 support. The world's most populair RS implementations (BIRD and OpenBGPD) already support RFC 9234! Tens of thousands of IX customers would enjoy the benefits of a few hundred IXPs taking action. RFC 9234 has no dependency on the RPKI, this means tha What can you do? ================ Just ask your vendors (your hardware routers and IXPs) to implement and deploy RFC 9234! :-) The more people ask, the more it'll bubble to the top of the priority list. The cost of implementing & deploying RFC 9234 is excellent bang for buck. Closing words ============= Shout out to our friends at FranceIX and MSK-IX for being amongst the first IXPs to deploy RFC 9234! Your effort helped reduce the potential impact of today's route leak! Kind regards, Job (YYCIX volunteer) Appendix A: ----------- Vantage point: YYCIX Route Server 1 (rs1.yycix.ca) Timestamp: Mon Sep 2 12:31:50 UTC 2024 Destination Prefix AS_PATH 102.164.129.0/24 6939 37613 6758 37649 i 102.164.139.0/24 6939 37613 6758 37649 37649 37649 37649 37649 i 102.164.140.0/24 6939 37613 6758 37649 i 102.164.141.0/24 6939 37613 6758 37649 i 102.164.182.0/24 6939 37613 6758 37649 i 154.65.33.0/24 6939 37613 6758 37649 i 154.65.34.0/24 6939 37613 6758 37649 i 154.65.35.0/24 6939 37613 6758 37649 i 154.65.36.0/24 6939 37613 6758 37649 i 154.65.37.0/24 6939 37613 6758 37649 i 154.65.38.0/24 6939 37613 6758 37649 i 154.65.39.0/24 6939 37613 6758 37649 i 154.72.35.0/24 6939 37613 37100 37027 37063 327721 i 157.185.151.0/24 6939 38040 54994 i 157.185.154.0/24 6939 38040 54994 i 163.171.164.0/24 6939 38040 54994 i 192.150.250.0/23 6939 4651 4618 4618 63529 4621 3836 i 196.50.8.0/24 6939 37613 6758 37649 i 196.50.9.0/24 6939 37613 6758 37649 i 196.50.11.0/24 6939 37613 6758 37649 37649 37649 37649 37649 i 196.50.13.0/24 6939 37613 6758 37649 37649 37649 37649 37649 i 196.50.14.0/24 6939 37613 6758 37649 i 2001:67c:15f4::/48 6939 41103 i 2401:c500:fd08::/48 6939 4637 38040 54994 i 2a01:53c0:ff03::/48 6939 4637 38040 54994 i 2a01:53c0:ff0f::/48 6939 4637 38040 54994 i 2a01:58c0::/32 6939 16347 42487 i 2a03:8920::/32 6939 41103 i 2a03:d602::/31 6939 16347 42487 i 2a03:d606::/31 6939 16347 42487 i 2a0d:ee00::/32 6939 16347 42487 i 2a0e:5b80::/29 6939 16347 42487 i 2a0e:e080::/32 6939 16347 42487 i 2a0f:c540::/29 6939 16347 42487 i ----- End forwarded message ----- _______________________________________________ Idr mailing list -- idr(a)ietf.org To unsubscribe send an email to idr-leave(a)ietf.org -- =============================================== 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 ===============================================

2 1

Re: [EXTERNAL] - Re: [MICE-DISCUSS] Peering with Google no longer available at MICE IX
by Jeremy Lumby Aug. 23, 2024

Aug. 23, 2024

I would be willing to bet if you looked just at the eyeball networks on MICE, 90% are getting the majority of their Google traffic across MICE, even if they have caches they are getting the fill across MICE in addition to the non cacheable traffic. Google's caches are not nearly as efficient as many of their competitors.I can confirm with over 10 years of experience dealing with Google that they are almost always very slow to upgrade.Jeremy LumbyMinnesota VoIP9217 17th Ave SSuite 216Bloomington MN 55425Main 612-355-7740Direct 612-392-6814EFax 952-873-7425jlumby(a)mnvoip.com -------- Original message --------From: Miles McCredie <Miles.McCredie(a)MIDCO.COM> Date: 8/23/24 6:34 AM (GMT-06:00) To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] [EXTERNAL] - Re: [MICE-DISCUSS] Peering with Google no longer available at MICE IX Curious how many MICE members are in each of the following buckets. Receive limited portion of Google traffic via MICE Midco and, I assume, US Internet are in this bucket Receive a significant portion of Google traffic via MICE today I’ve only got a couple years of experience with Google for Midco but my experience has been that Google will not always provide the cache capacity that I think is appropriate. The last two augments were triggered 9-12 months later than I would have liked. Could be my fault for creating new GNLs but… Miles McCredie Principal Network Engineer II-Core IP Office: 6052755192 Miles.McCredie(a)midco.com Midco.com Let's go beyond. From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Justin Krejci Sent: Thursday, August 22, 2024 5:25 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [EXTERNAL] - Re: [MICE-DISCUSS] Peering with Google no longer available at MICE IX CAUTION: This email originated from outside of MIDCO. Do not click links or open attachments unless you recognize the sender and know the content is safe. I am not sure what Google's stance is on deploying cache servers at an IX vs remote connection like the ones pending disconnection. If they were to deploy caching nodes at an IX, I assume they would still have a cache-fill requirement in terms of connectivity that has to come from somewhere... of which they appear to be disinterested in maintaining long distance connections going forward. So perhaps this is a donation opportunity for some to entice Google to deploy caching nodes at MICE? Donate local colo and transit bandwidth along with local MICE connectivity? We have numerous Google caching nodes in our network as well as multiple PNIs to Google, so their pending disconnect from MICE will likely have minimal direct impact on our eyeballs. -----Original Message----- From: Aaron Wendel <aaron(a)WHOLESALEINTERNET.NET> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Peering with Google no longer available at MICE IX Date: Thu, 22 Aug 2024 22:03:01 +0000 Has MICE requested a cache box from Google? ------ Original Message ------ From "Anthony Anderberg" <AnthonyAnderberg(a)NUVERA.NET> To MICE-DISCUSS(a)LISTS.IPHOUSE.NET Date 8/22/2024 4:28:18 PM Subject Re: [MICE-DISCUSS] Peering with Google no longer available at MICE IX I've been surprised that folks haven't been talking about this more and am curious about everyone's thoughts - as MICE user-members but also in terms of MICE leadership and direction. As a user-member I feel somewhat conflicted: on one hand in an effort to maximize performance I could obtain transport to Chicago and connect to Google there, but I feel like doing so is making Google's problem into my problem and that doing so undercuts the goals of MICE. We've seen content providers move MICE's larger members toward local direct private peering, and I can understand rational behind that even if it shifts traffic away from MICE - but Google is proposing remote direct peering at member's cost which feels different. Of course nobody expects Google to subsidize our corner of the world, I am just curious if there are other aspects we should be thinking about. Thanks in advance, Anthony On 8/22/24, 7:24 AM, "Google Peering Operations No-reply" <peering-ops-noreply(a)google.com <mailto:peering-ops-noreply@google.com>> wrote: Dear Peer, This is a reminder that peering with Google will no longer be available at MICE Internet Exchange from 16th of September. As a result of unsustainable overheads associated with connecting to an IX using remote waves, we have made a decision to stop connecting to IXs that way. MICE IX falls under the category of IXs we remotely connect to. We will withdraw prefixes on 16th of September, and disconnect from the IX on 24th of September. We realize this may cause inconvenience for some peers. If there is another mutually present IX that we can peer in, we will be happy to help set up a bilateral session there - no multilaterals. If there is no mutual IX, traffic may have to be exchanged via indirect paths (transit links). We are not looking to connect to any additional IXs to replace the IX that we are leaving, but if you are considering connecting to another IX and not sure if Google will also be leaving that IX because of this measure, please reach out to us and we can share more. Thank you for your understanding. 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

4 4

Re: Peering with Google no longer available at MICE IX
by Anthony Anderberg Aug. 23, 2024

Aug. 23, 2024

I've been surprised that folks haven't been talking about this more and am curious about everyone's thoughts - as MICE user-members but also in terms of MICE leadership and direction. As a user-member I feel somewhat conflicted: on one hand in an effort to maximize performance I could obtain transport to Chicago and connect to Google there, but I feel like doing so is making Google's problem into my problem and that doing so undercuts the goals of MICE. We've seen content providers move MICE's larger members toward local direct private peering, and I can understand rational behind that even if it shifts traffic away from MICE - but Google is proposing remote direct peering at member's cost which feels different. Of course nobody expects Google to subsidize our corner of the world, I am just curious if there are other aspects we should be thinking about. Thanks in advance, Anthony On 8/22/24, 7:24 AM, "Google Peering Operations No-reply" <peering-ops-noreply(a)google.com <mailto:peering-ops-noreply@google.com>> wrote: Dear Peer, This is a reminder that peering with Google will no longer be available at MICE Internet Exchange from 16th of September. As a result of unsustainable overheads associated with connecting to an IX using remote waves, we have made a decision to stop connecting to IXs that way. MICE IX falls under the category of IXs we remotely connect to. We will withdraw prefixes on 16th of September, and disconnect from the IX on 24th of September. We realize this may cause inconvenience for some peers. If there is another mutually present IX that we can peer in, we will be happy to help set up a bilateral session there - no multilaterals. If there is no mutual IX, traffic may have to be exchanged via indirect paths (transit links). We are not looking to connect to any additional IXs to replace the IX that we are leaving, but if you are considering connecting to another IX and not sure if Google will also be leaving that IX because of this measure, please reach out to us and we can share more. Thank you for your understanding. Sincerely, Google Network Operations

8 9

RFP: 511 IP Transit
by Richard Laager Aug. 23, 2024

Aug. 23, 2024

MICE is in need of IP transit at 511. This is for our management connection. We are looking for IPv4 + IPv6 transit delivered over a 1G copper (if in the same suite), 1G optical, or 10G optical. MICE will take care of the cross-connect. No BGP necessary. We need a /29 of IPv4 space and a /60 of IPv6 space. The current IP space is routed to us over a separate point-to-point (e.g. the /29 is over a /31 point-to-point). Our actual bandwidth usage is very minimal; 100 Mbps is more than plenty. Please specify the speed you are offering. I don't know that we have a specific term length in mind. Month-to-month, 1 year, or 3 year is probably fine. Please specify the term length(s) you are offering. You can reply off-list to Anthony Anderberg <AnthonyAnderberg(a)nuvera.net>. He intends NOT to bid on this. Conflict of interest note: My employer will bid on this. I will recuse from the board vote on it. -- Richard

1 0

bgp down to 206.108.255.117 and 2001:504:27::80a6:0:2 for both as3128 and as2381.. others?
by Michael Hare July 9, 2024

July 9, 2024

As the subject says, at least two ASN seem to bgp down v4/v6 as of roughly 03:48:42 local [UTC-5]. Is this a bigger thing? Apologies if I missed something. -Michael

3 2

Global Net (AS395466) - Transport Outages
by Global Net NOC June 24, 2024

June 24, 2024

MICEMN Members – We have been experiencing ongoing outages with our carrier into Minneapolis (whom I will not name) which directly affects our connectivity with MICE. I want to apologize for the drops in our BGP sessions that seem to be happening more and more frequently as our carrier refuses to do anything to address the problem. We are actively seeking another transport option as a long term solution. Short term, all I can do is apologize for all the flaps and outages. GLOBAL NET AS 395466 IPV4 206.108.255.97 IPV6 2001:504:27:0:6:8ca:0:1 Thanks, Global Net NOC noc(a)theglobal.net<mailto:noc@theglobal.net> Global Net Peering peering(a)theglobal.net<mailto:peering@theglobal.net>

1 0

outage of some sort last night
by Jeff Wilde June 17, 2024

June 17, 2024

Did anyone experience some type of odd outage in the middle of the night? Like before 5am? I don't know if it was a dns issue or what, but it seems to have resolved itself. [A picture containing icon Description automatically generated] Jeff Wilde * Network Engineer * Park Region Office 218.826.6161 * Direct 218.826.8330 * Fax 218.826.6298

4 3

Link to Ridgeview down
by Jeremy Lumby June 10, 2024

June 10, 2024

An FYI that we are aware that the link between the MICE core switch @ 511, and the MICE core switch @ Ridgeview is down. There is a complete loss of light. I have contacted the dark fiber provider to begin troubleshooting the link. Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington MN 55425 Main 612-355-7740 x211 Direct 612-392-6814 Fax 952-873-7425 jlumby(a)mnvoip.com

2 2

Minnesota Repeals Municipal Broadband Restrictions
by David Farmer May 24, 2024

May 24, 2024

https://arstechnica.com/tech-policy/2024/05/another-us-state-repeals-law-th… Minnesota this week eliminated two laws that made it harder for cities and towns to build their own broadband networks. The state-imposed restrictions were repealed in an omnibus commerce policy bill signed on Tuesday by Gov. Tim Walz, a Democrat. .... -- =============================================== 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 ===============================================

3 3

Traffic spike starting at 2:00am today
by Dean Bahls May 24, 2024

May 24, 2024

Curious if anyone knows why we are seeing about 25-30% increase in traffic today. Some big updates going on perhaps? Thanks, Dean Dean Bahls COO | Fiber Minnesota & Aurora Fiber Optic Networks 14 Main St SW | PO Box J | Menahga, MN 56464 218.564-1321 (Direct) | 218.564.3000 (Main Office) dean.bahls(a)fiberminnesota.com<mailto:dean.bahls@fiberminnesota.com> [cid:image001.png@01DAADBE.2C9CB570] [cid:image002.jpg@01DAADBE.2C9CB570]

16 19

Cacti vulnerabilities
by Michael Horwath May 14, 2024

May 14, 2024

https://thehackernews.com/2024/05/critical-flaws-in-cacti-framework-could.h… Sharing is caring, and I care about sharing! -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

1 0

Server Updates
by Cameron Skappel May 3, 2024

May 3, 2024

We plan to update MICE servers and firewalls Friday 11:00AM Central. We'll only be doing 1 route server at a time. -- Cameron

1 1

Peering Summit Bus Mankato->Kansas City
by Jay Hanke April 24, 2024

April 24, 2024

The Midwest Peering Summit bus is a go. Here's the schedule: Wednesday 6/12/2024 10:00 AM Leave Mankato, We have free parking available 5:20 PM Arrive at Westin Crown Plaza Kansas City Friday 6/14/2024 4:00 PM Leave Kansas City Westin Crown Plaza Kansas City 11:25 PM Arrive in Mankato Cost is $150.00 round trip per person There is space on the bus to transport down exhibit equipment as well if needed. Email mwps(a)southfront.io to register. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 507-327-2398 https://southfront.io/

1 0

MWPS 2024 Transportion
by Jay Hanke April 18, 2024

April 18, 2024

If I had a coach bus going from MN to Kansas City Peering Summit, are others interested? -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 507-327-2398 https://southfront.io/

4 4

Fwd: Google - Drain of routes for Route-Servers in your IX
by Richard Laager April 5, 2024

April 5, 2024

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

10 11

MICE interface flap
by Chris Wopat March 19, 2024

March 19, 2024

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: http://micelg.usinternet.com/export/graph_2625.html 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

3 6

UG 45 Meeting Reminder
by Anthony Anderberg March 18, 2024

March 18, 2024

The MICE UG 45 meeting will be held Wednesday, March 20, 3:00 pm at the University of Minnesota IT Building. 2218 University Ave SE Minneapolis, MN 55414, Room 185 Across University Ave SE from Huntington (TCF) Bank Stadium Parking, etc. details same as before: https://lists.iphouse.net/cgi-bin/wa?A2=MICE-DISCUSS;2c503e19.2209 Zoom Details: https://umn.zoom.us/j/94910223662?pwd=RUluTERkODlsdU93eHlQejR4eFVRdz09 ID: 94910223662, passcode: XdrNr3 651-372-8299 (passcode: 988007) Thanks everyone, Anthony

1 0

Re: MICE Usage Graphs
by Anthony Anderberg March 6, 2024

March 6, 2024

Yes, this had been on my todo list since Jeremy’s port changes - guess I just needed my friends to prod me a bit. :-) I think I’ve got everything cleaned up; I was able to preserve CarverLink’s data history but most of the others are new since the port changes. Cheers, Anthony From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Randy Lehs <rlehs(a)CARVERLINK.COM> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Date: Tuesday, March 5, 2024 at 5:26 PM To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] MICE Usage Graphs I noticed that several ports stopped graphing on the weathermap about a month ago, and just wanted to make sure someone was aware/working on it since I use the graphs all the time. Randy Lehs | CarverLink Fiber Manager CarverLink – A Department of Carver County Public Services 600 East Fourth Street Chaska, MN 55318-2102 www.carverlink.com<http://www.carverlink.com/> | rlehs(a)carverlink.com<mailto:rlehs@carverlink.com> Office: 952-361-1494 | Fax: 952-361-1582 | Cell: 612-719-1656 | Standard and Emergency Support 24/7/365: 952-361-1200 ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

2 1

MICE Usage Graphs
by Randy Lehs - CarverLink March 5, 2024

March 5, 2024

I noticed that several ports stopped graphing on the weathermap about a month ago, and just wanted to make sure someone was aware/working on it since I use the graphs all the time. Randy Lehs | CarverLink Fiber Manager CarverLink - A Department of Carver County Public Services 600 East Fourth Street Chaska, MN 55318-2102 www.carverlink.com<http://www.carverlink.com/> | rlehs(a)carverlink.com<mailto:rlehs@carverlink.com> Office: 952-361-1494 | Fax: 952-361-1582 | Cell: 612-719-1656 | Standard and Emergency Support 24/7/365: 952-361-1200

1 0

IRR Mandatory at MICE / New Route Servers
by Richard Laager Feb. 27, 2024

Feb. 27, 2024

[I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.] MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs. *What* * You MUST have an as-set object listing your AS and your downstream ASes (if any). o You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager(a)wiktel.com please). * A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set. *When* * *If you are a transit AS (i.e. have ASes behind you) and don't have an /as-set/ object, fix this **/now/**.* Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the /first/ new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. * Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now. ** *Where* If you are not sure /where/ to create IRR records, use ARIN (assuming you are in the ARIN region). *How (with ARIN)* 1. Login to ARIN Online. (Go to arin.net and click Login in the top right.) 2. On the left side, expand "Routing Security" and click "IRR". 3. Click "as-set" at the top. 4. Click "Create an Object". 5. Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). 6. Click "Review". Once ready, click "Submit". 7. Click "route/route6" at the top. 8. Click "Create an Object". 9. Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. 10. Click "Review". Once ready, click "Submit". 11. Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6! *Examples* Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20 (I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.) -- Richard

10 34

Global Net - AS395466 Maintenance
by Global Net NOC Feb. 22, 2024

Feb. 22, 2024

MICEMN Members - Our upstream provider, Zayo, will be undergoing a forced relocation at our datacenter in Montana. Expect our BGP sessions to drop during this time. 2/22 2200 – 2/23 0500 MST GLOBAL NET AS 395466 IPV4 206.108.255.97 IPV6 2001:504:27:0:6:8ca:0:1 Thanks, Global Net NOC noc(a)theglobal.net<mailto:noc@theglobal.net> Global Net Peering peering(a)theglobal.net<mailto:peering@theglobal.net>

1 0

UG 45 Meeting
by Richard Laager Feb. 22, 2024

Feb. 22, 2024

The MICE UG 45 meeting will be held Wednesday, March 20, 3:00 pm at UMN. Parking, etc. details same as before: https://lists.iphouse.net/cgi-bin/wa?A2=MICE-DISCUSS;2c503e19.2209 Zoom Details: https://umn.zoom.us/j/94910223662?pwd=RUluTERkODlsdU93eHlQejR4eFVRdz09 ID: 94910223662, passcode: XdrNr3 651-372-8299 (passcode: 988007) -- Richard

1 1

MICE Server Updates
by Cameron Skappel Feb. 9, 2024

Feb. 9, 2024

This evening I applied server updates to some of the MICE servers including Router Server 2. Let me know if there are issues. -- Cameron

1 1

MICE BFD Errors
by Richard Laager Feb. 8, 2024

Feb. 8, 2024

BIRD is complaining that various peers are sending BFD packets with an unknown session id. Anyone have thoughts on this? The logs look like this: 2024-02-07 23:44:14 <RMT> bfd1: Bad packet from YOUR_IP - unknown session id (SOME_INTEGER) Those marked with an asterisk were doing this yesterday, so prior to the reboot of rs2. rs1: Inteliquent (Neutral Tandem) 206.108.255.137 * rs2: les.net 2001:504:27::4813:0:1 Savage Communications 206.108.255.17 * 2001:504:27::5adc:0:1 * Stellar Association 206.108.255.53 2001:504:27::8e16:0:1 * Hoyos Consulting 2001:504:27::d15d:0:1 Eastern Iowa Data Group 206.108.255.168 * 2001:504:27::f7a2:0:1 * Omnitel Communications 206.108.255.148 Here is for the entire month of January: rlaager@rs1:~$ rg "^2024-01-.*Bad packet from" /var/log/bird/rs1-ipv*.1 | awk '{print $8}' | sort | uniq -c 9 2001:504:27::3823:0:2 2 2001:504:27::8252:0:1 1183836 2001:504:27::b7f8:0:1 4 2001:504:27::d15d:0:1 1183834 206.108.255.101 7498 206.108.255.119 380 206.108.255.121 1463099 206.108.255.137 3 206.108.255.176 3 206.108.255.185 root@rs2:~# rg "^2024-01-.*Bad packet from" /var/log/bird/rs2-ipv*.1 | awk '{print $8}' | sort | uniq -c 12 2001:504:27::1e49:0:1 1 2001:504:27::3823:0:2 1 2001:504:27::39:0:1 1457433 2001:504:27::5adc:0:1 3 2001:504:27::6478:0:1 1457369 2001:504:27::8e16:0:1 1 2001:504:27::9dbe:0:1 5 2001:504:27::9dbe:0:2 1179733 2001:504:27::b7f8:0:1 1176975 2001:504:27::d15d:0:1 4 2001:504:27::e4f:0:1 1 2001:504:27::f756:0:1 1331747 2001:504:27::f7a2:0:1 1179735 206.108.255.101 7494 206.108.255.119 1954 206.108.255.120 3 206.108.255.137 3 206.108.255.161 1331745 206.108.255.168 1457437 206.108.255.17 2 206.108.255.176 8 206.108.255.185 11 206.108.255.3 6 206.108.255.46 1457345 206.108.255.53 4 206.108.255.92 -- Richard

2 1

MICE Core Switch Card Upgrade
by Richard Laager Feb. 8, 2024

Feb. 8, 2024

Date & Time Wednesday, February 14 at 15:00 US/Central Description Jeremy will swap a (now unused) 10G line card for a 100G line card in the Arista core switch at 511. There is no expected impact for most participants. In the (relatively unlikely) event that a fiber cable is physically in the way and he has to unplug it to remove/install the card, he will disable BGP for that participant first and wait (unless the port is part of a LAG with sufficient excess capacity at that time of day). The Fiber Minnesota and Minnesota VoIP remote switches are connected by 3x100G LAG. Jeremy will move one port from each LAG from card 6 to the new card. Rollback Plan If there is some problem, the new 100G card can be removed. The ports in the Fiber Minnesota and Minnesota VoIP remote switches can be moved back to card 6. -- Richard

1 0

MICE Core Switch EOS Upgrade
by Richard Laager Feb. 7, 2024

Feb. 7, 2024

Date & Time Wednesday, January 31 at 06:00 US/Central Description Jeremy will upgrade software on the Arista core switch at 511. This is necessary to be able to install the (newer) 100G card into the switch. Rollback Plan The previous software image will be available to revert. -- Richard

3 5

Addresses on the list...
by Mike Horwath Jan. 31, 2024

Jan. 31, 2024

Calling out: From: Tritan Internet LLC (AS393577) <noc(a)as393577.net> Subject: TD#937 - Acknowledgement from Tritan Internet NOC Please subscribe either a user to the list or update things so that autoresponses do not occur. LISTSERV picked it up and did the right thing, thankfully. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

1 0

BGP ADD-PATH capability
by Richard Laager Jan. 24, 2024

Jan. 24, 2024

I propose that MICE enable BGP ADD-PATH capability (RFC 7911) on the route servers (in TX mode only). This is negotiated BGP capability, so we do not need any per-participant setting for it. ADD-PATH is useful if the best path route is being filtered but another route would not be. We discussed adding this at a UG meeting years ago. There are other IXPs that have this enabled. For example, this one: https://www.bcix.de/ixp/content/0/route-servers In terms of timeline, I propose something like this: * January 9: Enable it on Route Server 1. * January 16: Enable it on Route Server 2. The actual change looks like this for the RS1-only piece, and then the conditional would be removed when we want to deploy to RS2: --- a/roles/ixpmanager/files/mice/api/v4/router/server/bird2/neighbors.foil.php +++ b/roles/ixpmanager/files/mice/api/v4/router/server/bird2/neighbors.foil.php @@ -315,6 +315,9 @@ protocol bgp pb_<?= $int['fvliid'] ?>_as<?= $int['autsys'] ?> from tb_rsclient { import filter f_import_as<?= $int['autsys'] ?>; table t_<?= $int['fvliid'] ?>_as<?= $int['autsys'] ?>; export filter f_export_as<?= $int['autsys'] ?>; +<?php if( $t->router->router_id == "206.108.255.1" ): ?> + add paths tx; +<?php endif; ?> }; <?php if( $int['bgpmd5secret'] && !$t->router->skip_md5 ): ?> password "<?= $int['bgpmd5secret'] ?>"; -- Richard

6 11

MICE Maintenance 2024-01-18 & 2024-01-19
by Richard Laager Jan. 9, 2024

Jan. 9, 2024

Date & Time January 18, 00:00 - 05:00 US/Central January 19, 00:00 - 05:00 US/Central Description Our underlying fiber provider will be doing maintenance on the connection from 511 to Ridgeview. They are attempting to repair some other fiber issues. We may or may not go down. If we did go down, participants on the 511 side would see a loss of BGP to Route Server 2. -- Richard

1 0

Route servers?
by Miles McCredie Jan. 3, 2024

Jan. 3, 2024

FWIW, the AS11232 sessions to route server 2 have been active for about 25 minutes. https://ixpmgr.micemn.net/lg/rs2-ipv4 and https://ixpmgr.micemn.net/lg/rs2-ipv6 <https://ixpmgr.micemn.net/lg/rs2-ipv6%20show%20that%20AS11232> show quite a few other ASNs that are not established. https://ixpmgr.micemn.net/lg/rs1-ipv4 and https://ixpmgr.micemn.net/lg/rs1-ipv6 show more not-established sessions than I would expect but fewer than rs2. I haven't looked more closely at the impact to routing yet. Any details about the work in progress? Thanks [http://images.midcocomm.com/ES_MidcoLogo.png] Miles McCredie Principal Network Engineer II-Core IP Office: 6052755192 Miles.McCredie(a)midco.com Midco.com

4 6

Strange Cacti graphs
by Dean Bahls Dec. 21, 2023

Dec. 21, 2023

Anyone notice the strange spikes/valleys on the Cacti graphs lately? Looks like a heartbeat every hour on the hour. Thanks, Dean Dean Bahls COO | Fiber Minnesota 14 Main St SW | PO Box J | Menahga, MN 56464 218.564-1321 (Direct) | 218.564.3000 (Main Office) dean.bahls(a)fiberminnesota.com<mailto:dean.bahls@fiberminnesota.com> [cid:image001.png@01DA3298.4466DA60] [cid:image002.png@01DA3298.4466DA60]

2 1

MICE almost hit 2T
by David Farmer Dec. 5, 2023

Dec. 5, 2023

We had a 1.96T burst last night. [image: image.png] The extra Fortnite Chapter 5 Season 1 release traffic over the weekend can be seen. [image: image.png] -- =============================================== 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 ===============================================

5 5

micelg.usinternet.com
by Jeremy Lumby Nov. 28, 2023

Nov. 28, 2023

I no longer seem to be able to connect to http://micelg.usinternet.com via IPv4 or IPv6 Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington MN 55425 Main 612-355-7740 x211 Direct 612-392-6814 Fax 952-873-7425 jlumby(a)mnvoip.com

5 6

OmniTech (AS54821) has disconnected from MICE
by Jay Hanke Nov. 27, 2023

Nov. 27, 2023

OmniTech AS54821 has disconnected from MICE. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 507-327-2398 https://southfront.io/ <https://southfront.io/path.html>

1 0

Thursday night Prime Football
by Steve Savoy Nov. 22, 2023

Nov. 22, 2023

Hello everyone, Just curious if anyone else has customers complaining about Prime football on Thursday nights being extremely 'grainy' - like the old VHS days........ Thank you, Steve Savoy Confidentiality Notice: This correspondence is the property of Winnebago Cooperative Telecom Association and is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

8 8

Global Net (AS395466) - Upcoming Maintenance 11/15/2023
by Global Net NOC Nov. 18, 2023

Nov. 18, 2023

MICEMN Members - We have a maintenance window scheduled for Wednesday, November 15th. BGP sessions will go down during the window. Start: 11/15/23 0701 UTC (00:01 MST) End: 11/15/23 1300 UTC (06:00 MST) GLOBAL NET AS 395466 IPV4 206.108.255.97 IPV6 2001:504:27:0:6:8ca:0:1 Thanks, Global Net NOC noc(a)theglobal.net Global Net Peering peering(a)theglobal.net

1 1

AS394330 LTD Broadband/GigFire Port Move
by Jay Hanke Nov. 8, 2023

Nov. 8, 2023

LTD Broadband/GigFire has moved from the MN VoIP Remote to port eth9/1 on the SFN remote switch. The MN VoIP port has been disabled. All IP information remains the same. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 507-327-2398 https://southfront.io/ <https://southfront.io/path.html>

1 0

[OT] Calix GigaSpire RG Failures
by Richard Laager Nov. 5, 2023

Nov. 5, 2023

"Critical: EXOS – GigaSpire RG Systems May Display Amber LED and Be Unreachable" https://community.calix.com/s/feed/0D54u0000A5ugVA "We have confirmed today that *only releases 23.2 and 23.3 are impacted*. EXOS Release 23.3.0.3.57 is now available for use in workflows within Calix Cloud, or for local download from theCalix Software Center <https://www.calix.com/my-calix/software-center.html#>.Please find the release notes for this build here <https://www.calix.com/content/dam/calix/doc-library/systems/prem/support/ex…>, and please reviewService Bulletin SB-23-005 <https://www.calix.com/bin/calix/servlets/docdownload?fileId=/content/dam/ca…>for additional technical detail regarding this matter. With the new release now available,*_we strongly recommend any systems running 23.2 or 23.3 be upgraded to this new release immediately_*. Systems running 23.1 or lower should upgrade to the 23.4 release when it becomes available later this month." -- Richard

1 0

Amazon TNF Bitrate/Stream
by Ben Wiechman Nov. 2, 2023

Nov. 2, 2023

Has anyone spent any time studying the bitrate per stream this year? What are you seeing on your networks? Our Qwilt cache is reporting 25Mbps/stream average, which doesn't seem realistic by other measures. Ben Wiechman Director of Network Strategy and Engineering 320.247.3224 | ben.wiechman(a)arvig.com Arvig | 224 East Main Street | Melrose, MN 56352 | arvig.com

4 7

Google to stop advertising to MICE Route Servers
by Jay Hanke Oct. 23, 2023

Oct. 23, 2023

We have received notice that Google AS15159 will stop sending and receiving routes from the MICE route servers on November 8th, 2023. Google has asked us to share the following notice. Google will keep current BGP bilateral with individual peers on MICE. Google invites other networks that rely on Route-Servers to request a bilateral session. Bilateral session request can be done at: https://isp.google.com/iwantpeering Thanks! -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 507-327-2398 https://southfront.io/

2 2

AS57 (NorthernLights/UofM) Maintenance Complete
by Colin Murphy Oct. 14, 2023

Oct. 14, 2023

University of Minnesota Engineers have completed the software upgrades on the NorthernLights Gigapop routers. Thanks, Colin Murphy Sr. Network Engineer Office of Information Technology University of Minnesota Northern Lights Gigapop Desk: 612-626-0870

1 0

AS57 (NorthernLights/UofM) Maintenance
by Colin Murphy Oct. 12, 2023

Oct. 12, 2023

University of Minnesota Engineers will be upgrading the software on the NorthernLights Gigapop routers. The expected outage for each router will be approximately 2 hours. BGP sessions will be shutdown prior to the software upgrades. Please let us know if you have any questions. Change window: 10/14/2023 4 AM to 5 PM CDT. Thanks, Colin Murphy Sr. Network Engineer Office of Information Technology University of Minnesota Northern Lights Gigapop Desk: 612-626-0870

1 0

AS11796 Maintenance
by Charles Monson Sept. 26, 2023

Sept. 26, 2023

AS11796/WIN Technology will be disabling all BGP sessions over the MICE exchange tonight after 2300 (Central) in preparation for maintenance. Please keep your BGP sessions with us active to avoid unnecessary troubleshooting once the link is back up. Thank you, Charles Monson WIN Technology (AS11796/AS26652)

1 0

UG 44 Meeting & Election
by Richard Laager Sept. 25, 2023

Sept. 25, 2023

The MICE UG 44 meeting will be held Wednesday, October 25, 3:00 pm at UMN. Here are the details (parking, etc.) from last time: https://lists.iphouse.net/cgi-bin/wa?A2=MICE-DISCUSS;2c503e19.2209 An updated Zoom link will be coming. *Nominations* We will be holding an election for a board seat. The board consists of three seats with staggered terms, such that one seat comes up for re-election each year (at the fall meeting). This year, Anthony's seat is up for election. As in the past, we will close nominations in advance of the meeting so people have a chance to instruct a proxy appropriately. *Nominations will be open for two weeks (so until the end of October 7).* * * *Proxies * The bylaws state that you send proxies to the Chief Manager (me, Richard Laager), and electronic means are acceptable. So a simple email is sufficient: rlaager(a)wiktel.com or chiefmanager(a)micemn.net. If you send me a /vote/ by email (e.g. "We vote for <X>."), I will treat it as an a proxy appointment, appointing me to vote on your behalf, but restricted to /only/ the election item and to /only/ vote for the candidate you expressed. If you send me a proxy with different instructions (e.g. "We appoint <Y> to vote for us."), obviously that will be honored as written. -- Richard

2 1

Gateway Fiber ribbon cutting
by Michael Horwath Sept. 14, 2023

Sept. 14, 2023

They had that this moring at 1000 hours in Blaine. I made a joke to my friend that I wonder how many of 3 of us will be there. Well, I got a surprise as there were at least 8 folks who were not affilitated with the event. Talking to a couple of folks - would like to have customers up by end of year in Blaine - my area (Coon Rapids) would come afterwards but could not get them to commit or ‘about 6 months’ - GPON for delivery - using Comlink Solutions for the pulls - 511 is on their radar - mentioned expanding south from Blaine into SLP, Mounds View - mentioned expanding north-west into Andover I mentioned MICE and gave el-presidente my email address to contact me, and the website URL And I did not get a pic of their pricing flyer! But 2Gbps bidirectional is $150/month but I cannot remember the lower speeds cause I didn’t care :) -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

3 2

Global Net (AS395466) - Down
by Global Net NOC Sept. 12, 2023

Sept. 12, 2023

MICEMN Members - Our circuit to Cologix in Minneapolis is hard down due to an upstream provider issue. Our BGP sessions remain down. GLOBAL NET AS 395466 IPV4 206.108.255.97 IPV6 2001:504:27:0:6:8ca:0:1 Thanks, Global Net NOC noc(a)theglobal.net Global Net Peering Peering peering(a)theglobal.net

1 0

Route Server 2
by Tom Krenn Sept. 8, 2023

Sept. 8, 2023

Hi all, Anyone else noticing the route server at 206.108.255.2 / 2001:504:27::d1af:0:2 dropping out for a second or so the last few days? I'm seeing similar from both of my routers. LC/0/0/CPU0:Sep 8 07:29:45.717 CDT: bfd_agent[173]: %L2-BFD-6-SESSION_STATE_DOWN : BFD session to neighbor 2001:504:27::d1af:0:2 on interface HundredGigE0/0/0/20 has gone down. Reason: Control timer expired RP/0/RSP0/CPU0:Sep 8 07:29:45.718 CDT: bgp[1065]: %ROUTING-BGP-5-ADJCHANGE : neighbor 2001:504:27::d1af:0:2 Down - BFD (Bidirectional forwarding detection) session down (VRF: default) (AS: 53679) LC/0/0/CPU0:Sep 8 07:29:45.795 CDT: bfd_agent[173]: %L2-BFD-6-SESSION_STATE_DOWN : BFD session to neighbor 206.108.255.2 on interface HundredGigE0/0/0/20 has gone down. Reason: Control timer expired RP/0/RSP0/CPU0:Sep 8 07:29:45.797 CDT: bgp[1065]: %ROUTING-BGP-5-ADJCHANGE : neighbor 206.108.255.2 Down - BFD (Bidirectional forwarding detection) session down (VRF: default) (AS: 53679) LC/0/0/CPU0:Sep 8 07:29:50.384 CDT: bfd_agent[173]: %L2-BFD-6-SESSION_STATE_UP : BFD session to neighbor 2001:504:27::d1af:0:2 on interface HundredGigE0/0/0/20 is up LC/0/0/CPU0:Sep 8 07:29:50.384 CDT: bfd_agent[173]: %L2-BFD-6-SESSION_STATE_UP : BFD session to neighbor 206.108.255.2 on interface HundredGigE0/0/0/20 is up RP/0/RSP0/CPU0:Sep 8 07:30:58.517 CDT: bgp[1065]: %ROUTING-BGP-5-ADJCHANGE : neighbor 206.108.255.2 Up (VRF: default) (AS: 53679) RP/0/RSP0/CPU0:Sep 8 07:31:01.850 CDT: bgp[1065]: %ROUTING-BGP-5-ADJCHANGE : neighbor 2001:504:27::d1af:0:2 Up (VRF: default) (AS: 53679) Tom Krenn Network Architect Enterprise Architecture - Information Technology Office: 612-596-8994 tom.krenn(a)hennepin.us<mailto:tom.krenn@hennepin.us> | hennepin.us<https://hennepin.us/> Hennepin County Government Center 300 South 6th Street, A-190 Minneapolis, MN, 55487 [Hennepin County logo] Connect: Facebook<https://www.facebook.com/hennepin> | Twitter<https://twitter.com/Hennepin> | YouTube<https://www.youtube.com/user/HennepinMN> | LinkedIn<https://www.linkedin.com/company/hennepin-county> | Instagram<https://www.instagram.com/hennepincounty> Disclaimer: If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly permanently delete this message from your computer system.

4 4