January 2020 - mice-discuss - lists.micemn.net

DCN 100G Port Upgrade

by Jay Hanke

DCN will be adding a 100G port and keeping their existing 10G port. The new 100G port assignment is Ethernet3/17/1 on the main switch. The new port will use existing IP assignments (labeled Fargo) 206.108.255.60 2001:504:27:0:0:68AA::1 Please provide your Arista compatible optic to Cologix or to Jeremy for installation in the main switch. This email will serve as your LOA/CFA. Welcome Aboard! -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

Jan. 28, 2020

Re: Blackholing DoS traffic

by Andrew Hoyos

Relevant: http://instituut.net/~job/LINX99_route_servers.pdf > On Jan 24, 2020, at 8:38 AM, Chris Wopat <wopat(a)wiscnet.net> wrote: > > On 1/24/20 8:01 AM, Frank Bulk wrote: >> This seems reasonable to me -- what is the timeline to IRR filter implementation? >> > > I would suspect this would require reaching out to MICE participants to > find their AS-SETs to build IRR off of, which should also help reveal > who is actually using IRR, which irrdb their data is at, and so on. > > I would think the best source of this data would be PeeringDB, instead > of MICE generating and maintaining its own list on the participants page. > > An API call to MICE's internal id shows the needed data: asn, irr_as_set: > > https://www.peeringdb.com/api/net?ix_id=446 > > It appears that 50 of the 88 participants have irr_as_set defined in > peeringdb, which is a pretty good start ('work' attached as text file) > > grep name mice.txt | wc -l > 88 > > grep irr_as_set mice.txt | grep \"\" | wc -l > 38 > > Apologies if methods for this have already been discussed, I didn't dig > in the archives. > > Cheers, > -- > Chris Wopat > Network Engineer, WiscNet > wopat(a)wiscnet.net 608-210-3965 > <mice-rr-data.txt>

Jan. 24, 2020

Re: Blackholing DoS traffic

by Chris Wopat

On 1/24/20 8:01 AM, Frank Bulk wrote: > This seems reasonable to me -- what is the timeline to IRR filter implementation? > I would suspect this would require reaching out to MICE participants to find their AS-SETs to build IRR off of, which should also help reveal who is actually using IRR, which irrdb their data is at, and so on. I would think the best source of this data would be PeeringDB, instead of MICE generating and maintaining its own list on the participants page. An API call to MICE's internal id shows the needed data: asn, irr_as_set: https://www.peeringdb.com/api/net?ix_id=446 It appears that 50 of the 88 participants have irr_as_set defined in peeringdb, which is a pretty good start ('work' attached as text file) grep name mice.txt | wc -l 88 grep irr_as_set mice.txt | grep \"\" | wc -l 38 Apologies if methods for this have already been discussed, I didn't dig in the archives. Cheers, -- Chris Wopat Network Engineer, WiscNet wopat(a)wiscnet.net 608-210-3965

Jan. 24, 2020

Re: Blackholing DoS traffic

by Frank Bulk

This seems reasonable to me -- what is the timeline to IRR filter implementation? Frank -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Thursday, January 23, 2020 2:54 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Blackholing DoS traffic On 1/23/20 2:45 PM, Frank Bulk wrote: > Has support for a blackhole community been added? We’d like to start > doing that. AFAIK, no. I think we'd need: - A BGP community* - which when set** causes the route servers to set a next hop of a specific IP address (and probably set no-export too) - which the route servers (?) ARP for, returning a specific MAC - which is blocked by a layer 2 ACL on the core switch and any remotes that are able to do so * At least the well-known blackhole community 65535:666 from RFC 7999. ** The route servers would also have to allow smaller prefixes when the blackhole community is set, so that you could blackhole as small as a single address (in IPv4 at least). See also: https://www.seattleix.net/blackholing In practice, this is probably behind IRR filtering in implemetation priority, because we really should be using IRR filtering so that you can only blackhole your own prefixes. -- Richard

Jan. 24, 2020

Re: Blackholing DoS traffic

by Richard Laager

On 1/23/20 2:45 PM, Frank Bulk wrote: > Has support for a blackhole community been added? We’d like to start > doing that. AFAIK, no. I think we'd need: - A BGP community* - which when set** causes the route servers to set a next hop of a specific IP address (and probably set no-export too) - which the route servers (?) ARP for, returning a specific MAC - which is blocked by a layer 2 ACL on the core switch and any remotes that are able to do so * At least the well-known blackhole community 65535:666 from RFC 7999. ** The route servers would also have to allow smaller prefixes when the blackhole community is set, so that you could blackhole as small as a single address (in IPv4 at least). See also: https://www.seattleix.net/blackholing In practice, this is probably behind IRR filtering in implemetation priority, because we really should be using IRR filtering so that you can only blackhole your own prefixes. -- Richard

Jan. 23, 2020

Re: Blackholing DoS traffic

by Frank Bulk

Has support for a blackhole community been added? We’d like to start doing that. Frank From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Steve Howard Sent: Friday, July 05, 2019 12:33 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Blackholing DoS traffic Hmmm... That is interesting. It would be nice to see functionality added to MICE someday. I especially like the 65535:666 community support because it would work nicely with our existing DDoS handling configuration. On a somewhat related note, we use the free CYMRU Unwanted Traffic Renewal Service ( http://www.team-cymru.com/utrs.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.team-2Dcymru.com_ut…> ) to reduce our DDoS traffic. I encourage MICE members to check it out -- as more ASes use it, it becomes more effective. On 06/20/2019 11:33 AM, Frank Bulk wrote: https://www.seattleix.net/blackholing<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.seattleix.net_blac…> Does MICE have an blackholng functionality equivalent to SIX? I was visiting with a DDoS mitigation vendor this morning and was curious if there was a way we could automatically mitigate DoS attack traffic coming from a MICE peer. Regards, Frank ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.iphouse.net_cgi-2…>

Jan. 23, 2020

Re: Debian Mirrors

by Ryan Nelson

For a MICE accessible option, the U of M Computer Science department hosts a mirror that has both Ubuntu and Debian repositories (plus some others). The website is http://mirror.umn.edu/. Ubuntu repositories: http://mirror.cs.umn.edu/ubuntu/ Debian repositories: http://mirror.cs.umn.edu/debian/ Ryan Nelson | Senior Network Architect Compudyne | 306 W Michigan Street - Suite 200 | Duluth, MN 55802 rnelson(a)compudyne.com | 218.336.2220 | compudyne.com -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Mike Horwath Sent: Monday, January 13, 2020 12:30 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Debian Mirrors On Mon, Jan 13, 2020 at 06:10:06PM +0000, Justin Krejci wrote: > Do they have separate ISOs and packages/updates mirrors? Is that for > everything? Everything that I have downloaded - I find ISOs out there. -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

Jan. 17, 2020

Re: FW: Prefix Hijack: 206.108.255.0/24

by Frank Bulk

Thanks for sorting that out! Frank -----Original Message----- From: Brandon Mulligan <brandon(a)nocix.net> Sent: Tuesday, January 14, 2020 4:51 PM To: Frank Bulk <fbulk(a)mypremieronline.com>; MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Cc: noc(a)wholesaleinternet.net Subject: Re: FW: Prefix Hijack: 206.108.255.0/24 Frank + MICE, This was sent to a new customer by mistake who then sent it to a route collector. I did not detect this in Cogent's looking glass. This should be resolved now. Sorry for the alert and thanks for the notification! On 1/14/2020 3:37 PM, Frank Bulk wrote: > Not sure if it's valid, but Hurricane Electric says that MICE's /24 is being infringed upon by AS32097 (WholeSale Internet, Inc.) > > Copying WII. > > Frank > > -----Original Message----- > From: no-reply(a)he.net <no-reply(a)he.net> > Sent: Tuesday, January 14, 2020 3:26 PM > Subject: Prefix Hijack: 206.108.255.0/24 > > # Hijack Alert > > You are receiving this e-mail because one of your prefix registrations > matched this alarm. > > Prefix: 206.108.255.0/24 > Infringing AS: 32097 (via peer 23.139.160.84) > AS Path: 26073 32097 > When: 2020-01-14 21:16:50 UTC

Jan. 14, 2020

FW: Prefix Hijack: 206.108.255.0/24

by Frank Bulk

Not sure if it's valid, but Hurricane Electric says that MICE's /24 is being infringed upon by AS32097 (WholeSale Internet, Inc.) Copying WII. Frank -----Original Message----- From: no-reply(a)he.net <no-reply(a)he.net> Sent: Tuesday, January 14, 2020 3:26 PM Subject: Prefix Hijack: 206.108.255.0/24 # Hijack Alert You are receiving this e-mail because one of your prefix registrations matched this alarm. Prefix: 206.108.255.0/24 Infringing AS: 32097 (via peer 23.139.160.84) AS Path: 26073 32097 When: 2020-01-14 21:16:50 UTC

Jan. 14, 2020

Re: WiscNet Remote Switch / Dedicated Remote Switches

by Richard Laager

The board decision is: We encourage remote switch operators to use dedicated switches, which seems like the best solution technically, but we will continue to evaluate proposals on a case-by-case basis with no firm requirement for dedicated switches. The WiscNet proposal is approved. -- Richard

Jan. 14, 2020