- mice-discuss - lists.micemn.net

Please Welcome SW MN Broadband to MICE!

by Jason Hanke

Name: Southwest MN Broadband Port: xe-0/0/12 (NP Remote) ASN: 25715 IPv4: 206.108.255.40/24 IPv6: 2001:504:27:0:0:6473::1/64 Peering Contact: support(a)mysmbs.com Route Server: Yes BFD: No Welcome aboard! -- 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

Dec. 13, 2017

Re: Attribute Length Error today

by Frank Bulk

Here’s a tweet to the list that Jay is referring to: https://twitter.com/JobSnijders/status/939280110607327232 Frank From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jason Hanke Sent: Saturday, December 9, 2017 7:01 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today it's time for secure route servers. Job sent out a list of ixp and quite a few of them are already doing rpki or irr filtering. On Dec 8, 2017 11:06 PM, "Richard Laager" <rlaager(a)wiktel.com<mailto:rlaager@wiktel.com>> wrote: Zero length is a subset of “doesn’t start with their AS”, so if we filter on that condition, hopefully we will catch that too. -- Richard > On Dec 8, 2017, at 23:04, Frank Bulk <fbulk(a)MYPREMIERONLINE.COM<mailto:fbulk@MYPREMIERONLINE.COM>> wrote: > > If the issue was that the AS PATH was zero length, can BIRD filter those out? > > Frank > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Doug McIntyre > Sent: Friday, December 8, 2017 6:15 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > >> On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >> The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. > > They do have filters for bogons + default route. > > I suspect bad AS attribute processing is part of what made it get leaked onwards. > The BIRD servers were logging that as well during this period. > >> On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. > > Possibly. > > > -- > Doug McIntyre <merlyn(a)iphouse.net<mailto:merlyn@iphouse.net>> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 12, 2017

Re: Super Bowl Change Freeze

by DeLong, Owen

If you aren’t yet peering with Akamai and would like to before this event starts streaming, please get your peering requests in to us soon. Don’t count on a route-server session to cover this. It is greatly preferable to peer directly with our router. Details are in peeringdb and we encourage you to peer both IPv4 and IPv6. Owen > On Dec 11, 2017, at 16:19 , Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > As you have probably heard, the Super Bowl is being held in Minneapolis > on February 4. We discussed at UG 26 that it would be a good idea to > institute a change freeze for a few days to a week before. > > If you need to upgrade your port capacity or make other changes at MICE, > please plan to have those *complete* by January 26th. > > If it were me, I wouldn't even cut it that close. > > -- > Richard

Dec. 12, 2017

Super Bowl Change Freeze

by Richard Laager

As you have probably heard, the Super Bowl is being held in Minneapolis on February 4. We discussed at UG 26 that it would be a good idea to institute a change freeze for a few days to a week before. If you need to upgrade your port capacity or make other changes at MICE, please plan to have those *complete* by January 26th. If it were me, I wouldn't even cut it that close. -- Richard

Dec. 12, 2017

Re: Passive BFD support on Route-Server #1

by Doug McIntyre

On Mon, Dec 04, 2017 at 03:12:28PM -0600, Doug McIntyre wrote: >Just to close this project out, I'll set a schedule to get this done. > >On Monday, 12/11/2017 at 12:30AM, I'll turn on passive BFD on the MICE route >server #1 (206.108.255.1/ 2001:504:27::d1af:0:1) for all connections. This was completed. No complications as far as I can see. I'll let this config run for a week and schedule up the other route server. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 11, 2017

Re: Attribute Length Error today

by Andrew Hoyos

On Dec 9, 2017, at 7:00 PM, Jason Hanke <jayhanke(a)NEUTRALPATH.NET> wrote: > > it's time for secure route servers. Job sent out a list of ixp and quite a few of them are already doing rpki or irr filtering. I second this. IXPmanager makes this easy. > >> On Dec 8, 2017 11:06 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: >> Zero length is a subset of “doesn’t start with their AS”, so if we filter on that condition, hopefully we will catch that too. >> >> -- >> Richard >> >> > On Dec 8, 2017, at 23:04, Frank Bulk <fbulk(a)MYPREMIERONLINE.COM> wrote: >> > >> > If the issue was that the AS PATH was zero length, can BIRD filter those out? >> > >> > Frank >> > >> > -----Original Message----- >> > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre >> > Sent: Friday, December 8, 2017 6:15 PM >> > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >> > Subject: Re: [MICE-DISCUSS] Attribute Length Error today >> > >> >> On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >> >> The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. >> > >> > They do have filters for bogons + default route. >> > >> > I suspect bad AS attribute processing is part of what made it get leaked onwards. >> > The BIRD servers were logging that as well during this period. >> > >> >> On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. >> > >> > Possibly. >> > >> > >> > -- >> > Doug McIntyre <merlyn(a)iphouse.net> >> > ~.~ ipHouse ~.~ >> > Network Engineer/Provisioning/Jack of all Trades >> > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 10, 2017

Re: Attribute Length Error today

by Jason Hanke

it's time for secure route servers. Job sent out a list of ixp and quite a few of them are already doing rpki or irr filtering. On Dec 8, 2017 11:06 PM, "Richard Laager" <rlaager(a)wiktel.com> wrote: > Zero length is a subset of “doesn’t start with their AS”, so if we filter > on that condition, hopefully we will catch that too. > > -- > Richard > > > On Dec 8, 2017, at 23:04, Frank Bulk <fbulk(a)MYPREMIERONLINE.COM> wrote: > > > > If the issue was that the AS PATH was zero length, can BIRD filter those > out? > > > > Frank > > > > -----Original Message----- > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Doug McIntyre > > Sent: Friday, December 8, 2017 6:15 PM > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > >> On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: > >> The more important question - why didn’t the route servers drop that? > I’d assume there should be inbound filters to drop > bogons+default+$otherbadstuff. > > > > They do have filters for bogons + default route. > > > > I suspect bad AS attribute processing is part of what made it get leaked > onwards. > > The BIRD servers were logging that as well during this period. > > > >> On a larger scale, this sort of thing begs the question - do we need to > have folks in some sort of isolated VLAN with test sessions to the route > servers upon turnup? SIX does this, as well as others, I suspect to prevent > these exact issues from happening. > > > > Possibly. > > > > > > -- > > Doug McIntyre <merlyn(a)iphouse.net> > > ~.~ ipHouse ~.~ > > Network Engineer/Provisioning/Jack of all Trades > > >

Dec. 10, 2017

Re: Attribute Length Error today

by Richard Laager

Zero length is a subset of “doesn’t start with their AS”, so if we filter on that condition, hopefully we will catch that too. -- Richard > On Dec 8, 2017, at 23:04, Frank Bulk <fbulk(a)MYPREMIERONLINE.COM> wrote: > > If the issue was that the AS PATH was zero length, can BIRD filter those out? > > Frank > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre > Sent: Friday, December 8, 2017 6:15 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > >> On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >> The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. > > They do have filters for bogons + default route. > > I suspect bad AS attribute processing is part of what made it get leaked onwards. > The BIRD servers were logging that as well during this period. > >> On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. > > Possibly. > > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades >

Dec. 9, 2017

Re: Attribute Length Error today

by Frank Bulk

If the issue was that the AS PATH was zero length, can BIRD filter those out? Frank -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Friday, December 8, 2017 6:15 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. They do have filters for bogons + default route. I suspect bad AS attribute processing is part of what made it get leaked onwards. The BIRD servers were logging that as well during this period. >On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. Possibly. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 9, 2017

Re: Attribute Length Error today

by Andrew Hoyos

> On Dec 8, 2017, at 6:14 PM, Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > > On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >> The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. > > They do have filters for bogons + default route. Cool. > I suspect bad AS attribute processing is part of what made it get leaked onwards. > The BIRD servers were logging that as well during this period. Gotcha, while extra work, would it be easy enough to add first hop AS path filters on sessions on the route servers? Or do these already exist as well? Without testing, I’m not sure if that even would have prevented this specific scenario, but it seems like one we should prevent in the future, somehow. -- Andrew Hoyos hoyosa(a)gmail.com

Dec. 9, 2017

Re: Attribute Length Error today

by Doug McIntyre

On Fri, Dec 08, 2017 at 06:03:21PM -0600, Andrew Hoyos wrote: >The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. They do have filters for bogons + default route. I suspect bad AS attribute processing is part of what made it get leaked onwards. The BIRD servers were logging that as well during this period. >On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. Possibly. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 9, 2017

Re: Attribute Length Error today

by Jeremy Lumby

The route servers are dropping it, however I wonder if the error is being generated in the process of dropping it. -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Andrew Hoyos Sent: Friday, December 08, 2017 6:03 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. And yes, "set-bgp-prepend=0” on the inbound filter on the session is the correct way to handle a similar behavior to ‘no bgp enforce first-as’ in Tik world. This causes the MICE ASN to be removed from the AS Path. -- Andrew Hoyos hoyosa(a)gmail.com > On Dec 8, 2017, at 5:55 PM, Darin Steffl <darin.steffl(a)MNWIFI.COM> wrote: > > It's possible it was sending default earlier and our consultant fixed it when he logged in between 1:27pm and 1:45pm. If someone wants to verify, that'd be great. > > On Fri, Dec 8, 2017 at 5:48 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I do not know much about how Mikrotik works. I agree that the filters do not look like you are sending default, I was just seeing it from Andy's post. > > > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl > Sent: Friday, December 08, 2017 5:39 PM > > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > > Looking at route filters right now and that I attached, I don't see that I'm advertising a default route unless I'm looking in the wrong spot. I did not setup any portion of the BGP as I know I'm not an expert or comfortable setting it up, thus why I hired a consultant to do it for me. They're a big Mikrotik consultant from Missouri. > > > > I only see us advertising 204.73.77.0/24, 162.255.252.0/22 in our route filters right now that I sent. > > > > > > > > On Fri, Dec 8, 2017 at 5:29 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > In looking at it, do you happen to know why you were sending a default route? Has that been corrected? > > > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl > Sent: Friday, December 08, 2017 5:16 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > > Hey all, > > > > I sent the following to my Mikrotik consultant who set this up for me and his response is below. Anyone familiar with Mikrotik that knows the easy way to do this? We have MICE filters setup but not sure the correct way to do this without messing anything up further. He had the route filters out of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he fixed that, we're now receiving 500+ mbps from MICE and its stable on our end. But if we're still sending incorrect route announcements, I want to fix that so I don't cause issues. I found two related forum posts on how to change this in my router but I have a couple MICE filters as shown in the attachment. Thanks > > > > My cell is 507-261-7690 > > > > > > My email to consultant: > > Under the technical page of their website http://micemn.net/technical.html I see the following note "Note that your BGP sessions to the route servers likely need no bgp enforce-first-as or similar. The route servers do not add the MICE AS to the AS path." A quick search of Mikrotik forums shows that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE peer. I'm not sure of this so want clarification to see if we need to make this change in order for traffic to start going through MICE. > > https://forum.mikrotik.com/viewtopic.php?t=55798 > > https://forum.mikrotik.com/viewtopic.php?t=43498 > > > > > > Consultant response: > > Your MICE connection should have had traffic assuming that you were advertising your prefixes to them. Their BGP session should not add their AS, so that should not matter. You should not need to change that, I would have to look to see why you are not seeing traffic. > > > > > > On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: > > On 08 December 2017 at 16:15:59, Justin Krejci wrote: > > Yup > > > > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE 6CFF 5918 CC49 4D16 A2FF E8 > > > >From this UPDATE dump, this parser helps quite a bit to decode what is > going on: http://bgpaste.convergence.cx/ > > Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's > router did the only thing it knows to do on BGP errors - drop the session. > > Further from the decode: > The NEXT_HOP was 206.108.255.89 > And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 > > Looks like Minnesota WiFi should check on their route announcements. > > HTH, > Andy > > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > Like us on Facebook > > > > 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 > > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > Like us on Facebook > > > > 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 > > > > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Dec. 9, 2017

Re: Attribute Length Error today

by Andrew Hoyos

The more important question - why didn’t the route servers drop that? I’d assume there should be inbound filters to drop bogons+default+$otherbadstuff. On a larger scale, this sort of thing begs the question - do we need to have folks in some sort of isolated VLAN with test sessions to the route servers upon turnup? SIX does this, as well as others, I suspect to prevent these exact issues from happening. And yes, "set-bgp-prepend=0” on the inbound filter on the session is the correct way to handle a similar behavior to ‘no bgp enforce first-as’ in Tik world. This causes the MICE ASN to be removed from the AS Path. -- Andrew Hoyos hoyosa(a)gmail.com > On Dec 8, 2017, at 5:55 PM, Darin Steffl <darin.steffl(a)MNWIFI.COM> wrote: > > It's possible it was sending default earlier and our consultant fixed it when he logged in between 1:27pm and 1:45pm. If someone wants to verify, that'd be great. > > On Fri, Dec 8, 2017 at 5:48 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I do not know much about how Mikrotik works. I agree that the filters do not look like you are sending default, I was just seeing it from Andy's post. > > > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl > Sent: Friday, December 08, 2017 5:39 PM > > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > > Looking at route filters right now and that I attached, I don't see that I'm advertising a default route unless I'm looking in the wrong spot. I did not setup any portion of the BGP as I know I'm not an expert or comfortable setting it up, thus why I hired a consultant to do it for me. They're a big Mikrotik consultant from Missouri. > > > > I only see us advertising 204.73.77.0/24, 162.255.252.0/22 in our route filters right now that I sent. > > > > > > > > On Fri, Dec 8, 2017 at 5:29 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > In looking at it, do you happen to know why you were sending a default route? Has that been corrected? > > > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl > Sent: Friday, December 08, 2017 5:16 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Attribute Length Error today > > > > Hey all, > > > > I sent the following to my Mikrotik consultant who set this up for me and his response is below. Anyone familiar with Mikrotik that knows the easy way to do this? We have MICE filters setup but not sure the correct way to do this without messing anything up further. He had the route filters out of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he fixed that, we're now receiving 500+ mbps from MICE and its stable on our end. But if we're still sending incorrect route announcements, I want to fix that so I don't cause issues. I found two related forum posts on how to change this in my router but I have a couple MICE filters as shown in the attachment. Thanks > > > > My cell is 507-261-7690 > > > > > > My email to consultant: > > Under the technical page of their website http://micemn.net/technical.html I see the following note "Note that your BGP sessions to the route servers likely need no bgp enforce-first-as or similar. The route servers do not add the MICE AS to the AS path." A quick search of Mikrotik forums shows that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE peer. I'm not sure of this so want clarification to see if we need to make this change in order for traffic to start going through MICE. > > https://forum.mikrotik.com/viewtopic.php?t=55798 > > https://forum.mikrotik.com/viewtopic.php?t=43498 > > > > > > Consultant response: > > Your MICE connection should have had traffic assuming that you were advertising your prefixes to them. Their BGP session should not add their AS, so that should not matter. You should not need to change that, I would have to look to see why you are not seeing traffic. > > > > > > On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: > > On 08 December 2017 at 16:15:59, Justin Krejci wrote: > > Yup > > > > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE 6CFF 5918 CC49 4D16 A2FF E8 > > > >From this UPDATE dump, this parser helps quite a bit to decode what is > going on: http://bgpaste.convergence.cx/ > > Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's > router did the only thing it knows to do on BGP errors - drop the session. > > Further from the decode: > The NEXT_HOP was 206.108.255.89 > And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 > > Looks like Minnesota WiFi should check on their route announcements. > > HTH, > Andy > > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > Like us on Facebook > > > > 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 > > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > Like us on Facebook > > > > 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 > > > > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Dec. 9, 2017

Re: Attribute Length Error today

by Darin Steffl

It's possible it was sending default earlier and our consultant fixed it when he logged in between 1:27pm and 1:45pm. If someone wants to verify, that'd be great. On Fri, Dec 8, 2017 at 5:48 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I do not know much about how Mikrotik works. I agree that the filters do > not look like you are sending default, I was just seeing it from Andy's > post. > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Darin Steffl > *Sent:* Friday, December 08, 2017 5:39 PM > > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] Attribute Length Error today > > > > Looking at route filters right now and that I attached, I don't see that > I'm advertising a default route unless I'm looking in the wrong spot. I did > not setup any portion of the BGP as I know I'm not an expert or comfortable > setting it up, thus why I hired a consultant to do it for me. They're a big > Mikrotik consultant from Missouri. > > > > I only see us advertising 204.73.77.0/24, 162.255.252.0/22 in our route > filters right now that I sent. > > > > > > > > On Fri, Dec 8, 2017 at 5:29 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > In looking at it, do you happen to know why you were sending a default > route? Has that been corrected? > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Darin Steffl > *Sent:* Friday, December 08, 2017 5:16 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] Attribute Length Error today > > > > Hey all, > > > > I sent the following to my Mikrotik consultant who set this up for me and > his response is below. Anyone familiar with Mikrotik that knows the easy > way to do this? We have MICE filters setup but not sure the correct way to > do this without messing anything up further. He had the route filters out > of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he > fixed that, we're now receiving 500+ mbps from MICE and its stable on our > end. But if we're still sending incorrect route announcements, I want to > fix that so I don't cause issues. I found two related forum posts on how to > change this in my router but I have a couple MICE filters as shown in the > attachment. Thanks > > > > My cell is 507-261-7690 <(507)%20261-7690> > > > > > > My email to consultant: > > Under the technical page of their website http://micemn.net/technical.html > I see the following note "Note that your BGP sessions to the route servers > likely need no bgp enforce-first-as or similar. The route servers do not > add the MICE AS to the AS path." A quick search of Mikrotik forums shows > that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE > peer. I'm not sure of this so want clarification to see if we need to make > this change in order for traffic to start going through MICE. > > https://forum.mikrotik.com/viewtopic.php?t=55798 > > https://forum.mikrotik.com/viewtopic.php?t=43498 > > > > > > Consultant response: > > Your MICE connection should have had traffic assuming that you were > advertising your prefixes to them. Their BGP session should not add their > AS, so that should not matter. You should not need to change that, I would > have to look to see why you are not seeing traffic. > > > > > > On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: > > On 08 December 2017 at 16:15:59, Justin Krejci wrote: > > Yup > > > > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor > 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF > FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE > 6CFF 5918 CC49 4D16 A2FF E8 > > > >From this UPDATE dump, this parser helps quite a bit to decode what is > going on: http://bgpaste.convergence.cx/ > > Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's > router did the only thing it knows to do on BGP errors - drop the session. > > Further from the decode: > The NEXT_HOP was 206.108.255.89 > And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 > > Looks like Minnesota WiFi should check on their route announcements. > > HTH, > Andy > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > <http://www.facebook.com/minnesotawifi> Like us on Facebook > <http://www.facebook.com/minnesotawifi> > > > ------------------------------ > > 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 > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > <http://www.facebook.com/minnesotawifi> Like us on Facebook > <http://www.facebook.com/minnesotawifi> > > > ------------------------------ > > 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 > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>

Dec. 8, 2017

Re: Attribute Length Error today

by Jeremy Lumby

I do not know much about how Mikrotik works. I agree that the filters do not look like you are sending default, I was just seeing it from Andy's post. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl Sent: Friday, December 08, 2017 5:39 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today Looking at route filters right now and that I attached, I don't see that I'm advertising a default route unless I'm looking in the wrong spot. I did not setup any portion of the BGP as I know I'm not an expert or comfortable setting it up, thus why I hired a consultant to do it for me. They're a big Mikrotik consultant from Missouri. I only see us advertising 204.73.77.0/24, 162.255.252.0/22 in our route filters right now that I sent. On Fri, Dec 8, 2017 at 5:29 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: In looking at it, do you happen to know why you were sending a default route? Has that been corrected? From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl Sent: Friday, December 08, 2017 5:16 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today Hey all, I sent the following to my Mikrotik consultant who set this up for me and his response is below. Anyone familiar with Mikrotik that knows the easy way to do this? We have MICE filters setup but not sure the correct way to do this without messing anything up further. He had the route filters out of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he fixed that, we're now receiving 500+ mbps from MICE and its stable on our end. But if we're still sending incorrect route announcements, I want to fix that so I don't cause issues. I found two related forum posts on how to change this in my router but I have a couple MICE filters as shown in the attachment. Thanks My cell is 507-261-7690 My email to consultant: Under the technical page of their website http://micemn.net/technical.html I see the following note "Note that your BGP sessions to the route servers likely need no bgp enforce-first-as or similar. The route servers do not add the MICE AS to the AS path." A quick search of Mikrotik forums shows that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE peer. I'm not sure of this so want clarification to see if we need to make this change in order for traffic to start going through MICE. https://forum.mikrotik.com/viewtopic.php?t=55798 https://forum.mikrotik.com/viewtopic.php?t=43498 Consultant response: Your MICE connection should have had traffic assuming that you were advertising your prefixes to them. Their BGP session should not add their AS, so that should not matter. You should not need to change that, I would have to look to see why you are not seeing traffic. On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: On 08 December 2017 at 16:15:59, Justin Krejci wrote: > Yup > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE 6CFF 5918 CC49 4D16 A2FF E8 >From this UPDATE dump, this parser helps quite a bit to decode what is going on: http://bgpaste.convergence.cx/ Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's router did the only thing it knows to do on BGP errors - drop the session. Further from the decode: The NEXT_HOP was 206.108.255.89 And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 Looks like Minnesota WiFi should check on their route announcements. HTH, Andy -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook 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 -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 8, 2017

Re: Attribute Length Error today

by Darin Steffl

Looking at route filters right now and that I attached, I don't see that I'm advertising a default route unless I'm looking in the wrong spot. I did not setup any portion of the BGP as I know I'm not an expert or comfortable setting it up, thus why I hired a consultant to do it for me. They're a big Mikrotik consultant from Missouri. I only see us advertising 204.73.77.0/24, 162.255.252.0/22 in our route filters right now that I sent. On Fri, Dec 8, 2017 at 5:29 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > In looking at it, do you happen to know why you were sending a default > route? Has that been corrected? > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Darin Steffl > *Sent:* Friday, December 08, 2017 5:16 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] Attribute Length Error today > > > > Hey all, > > > > I sent the following to my Mikrotik consultant who set this up for me and > his response is below. Anyone familiar with Mikrotik that knows the easy > way to do this? We have MICE filters setup but not sure the correct way to > do this without messing anything up further. He had the route filters out > of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he > fixed that, we're now receiving 500+ mbps from MICE and its stable on our > end. But if we're still sending incorrect route announcements, I want to > fix that so I don't cause issues. I found two related forum posts on how to > change this in my router but I have a couple MICE filters as shown in the > attachment. Thanks > > > > My cell is 507-261-7690 <(507)%20261-7690> > > > > > > My email to consultant: > > Under the technical page of their website http://micemn.net/technical.html > I see the following note "Note that your BGP sessions to the route servers > likely need no bgp enforce-first-as or similar. The route servers do not > add the MICE AS to the AS path." A quick search of Mikrotik forums shows > that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE > peer. I'm not sure of this so want clarification to see if we need to make > this change in order for traffic to start going through MICE. > > https://forum.mikrotik.com/viewtopic.php?t=55798 > > https://forum.mikrotik.com/viewtopic.php?t=43498 > > > > > > Consultant response: > > Your MICE connection should have had traffic assuming that you were > advertising your prefixes to them. Their BGP session should not add their > AS, so that should not matter. You should not need to change that, I would > have to look to see why you are not seeing traffic. > > > > > > On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: > > On 08 December 2017 at 16:15:59, Justin Krejci wrote: > > Yup > > > > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor > 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF > FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE > 6CFF 5918 CC49 4D16 A2FF E8 > > > >From this UPDATE dump, this parser helps quite a bit to decode what is > going on: http://bgpaste.convergence.cx/ > > Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's > router did the only thing it knows to do on BGP errors - drop the session. > > Further from the decode: > The NEXT_HOP was 206.108.255.89 > And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 > > Looks like Minnesota WiFi should check on their route announcements. > > HTH, > Andy > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > <http://www.facebook.com/minnesotawifi> Like us on Facebook > <http://www.facebook.com/minnesotawifi> > > > ------------------------------ > > 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 > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>

Dec. 8, 2017

Re: Attribute Length Error today

by Jeremy Lumby

In looking at it, do you happen to know why you were sending a default route? Has that been corrected? From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Darin Steffl Sent: Friday, December 08, 2017 5:16 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Attribute Length Error today Hey all, I sent the following to my Mikrotik consultant who set this up for me and his response is below. Anyone familiar with Mikrotik that knows the easy way to do this? We have MICE filters setup but not sure the correct way to do this without messing anything up further. He had the route filters out of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he fixed that, we're now receiving 500+ mbps from MICE and its stable on our end. But if we're still sending incorrect route announcements, I want to fix that so I don't cause issues. I found two related forum posts on how to change this in my router but I have a couple MICE filters as shown in the attachment. Thanks My cell is 507-261-7690 My email to consultant: Under the technical page of their website http://micemn.net/technical.html I see the following note "Note that your BGP sessions to the route servers likely need no bgp enforce-first-as or similar. The route servers do not add the MICE AS to the AS path." A quick search of Mikrotik forums shows that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE peer. I'm not sure of this so want clarification to see if we need to make this change in order for traffic to start going through MICE. https://forum.mikrotik.com/viewtopic.php?t=55798 https://forum.mikrotik.com/viewtopic.php?t=43498 Consultant response: Your MICE connection should have had traffic assuming that you were advertising your prefixes to them. Their BGP session should not add their AS, so that should not matter. You should not need to change that, I would have to look to see why you are not seeing traffic. On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: On 08 December 2017 at 16:15:59, Justin Krejci wrote: > Yup > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE 6CFF 5918 CC49 4D16 A2FF E8 >From this UPDATE dump, this parser helps quite a bit to decode what is going on: http://bgpaste.convergence.cx/ Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's router did the only thing it knows to do on BGP errors - drop the session. Further from the decode: The NEXT_HOP was 206.108.255.89 And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 Looks like Minnesota WiFi should check on their route announcements. HTH, Andy -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 8, 2017

Re: Attribute Length Error today

by Darin Steffl

Hey all, I sent the following to my Mikrotik consultant who set this up for me and his response is below. Anyone familiar with Mikrotik that knows the easy way to do this? We have MICE filters setup but not sure the correct way to do this without messing anything up further. He had the route filters out of order in our Mikrotik which is why I wasn't seeing MICE traffic. Once he fixed that, we're now receiving 500+ mbps from MICE and its stable on our end. But if we're still sending incorrect route announcements, I want to fix that so I don't cause issues. I found two related forum posts on how to change this in my router but I have a couple MICE filters as shown in the attachment. Thanks My cell is 507-261-7690 <(507)%20261-7690> My email to consultant: Under the technical page of their website http://micemn.net/technical.html I see the following note "Note that your BGP sessions to the route servers likely need no bgp enforce-first-as or similar. The route servers do not add the MICE AS to the AS path." A quick search of Mikrotik forums shows that the equivalent to this setting is to "set-bgp-prepend=0" for the MICE peer. I'm not sure of this so want clarification to see if we need to make this change in order for traffic to start going through MICE. https://forum.mikrotik.com/viewtopic.php?t=55798 https://forum.mikrotik.com/viewtopic.php?t=43498 Consultant response: Your MICE connection should have had traffic assuming that you were advertising your prefixes to them. Their BGP session should not add their AS, so that should not matter. You should not need to change that, I would have to look to see why you are not seeing traffic. On Fri, Dec 8, 2017 at 4:55 PM, Andy Koch <akoch(a)wiscnet.net> wrote: > On 08 December 2017 at 16:15:59, Justin Krejci wrote: > > Yup > > > > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor > 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF > FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE > 6CFF 5918 CC49 4D16 A2FF E8 > > > >From this UPDATE dump, this parser helps quite a bit to decode what is > going on: http://bgpaste.convergence.cx/ > > Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's > router did the only thing it knows to do on BGP errors - drop the session. > > Further from the decode: > The NEXT_HOP was 206.108.255.89 > And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 > > Looks like Minnesota WiFi should check on their route announcements. > > HTH, > Andy > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>

Dec. 8, 2017

Re: Attribute Length Error today

by Andy Koch

On 08 December 2017 at 16:15:59, Justin Krejci wrote: > Yup > > > Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 > Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE 6CFF 5918 CC49 4D16 A2FF E8 >From this UPDATE dump, this parser helps quite a bit to decode what is going on: http://bgpaste.convergence.cx/ Looks like the AS_PATH was 0 bytes long, which is invalid and Frank's router did the only thing it knows to do on BGP errors - drop the session. Further from the decode: The NEXT_HOP was 206.108.255.89 And the Routes were 204.73.77.0/24, 162.255.252.0/22 and 0.0.0.0/0 Looks like Minnesota WiFi should check on their route announcements. HTH, Andy

Dec. 8, 2017

Re: Attribute Length Error today

by Justin Krejci

Yup Dec 8 13:41:40.262 CST: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.1 3/11 (invalid or corrupt AS path) 3 bytes 400200 Dec 8 13:41:40.262 CST: BGP: 206.108.255.1 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0200 0000 0E40 0101 0040 0200 4003 04CE 6CFF 5918 CC49 4D16 A2FF E8 ________________________________________ From: MICE Discuss [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] on behalf of Frank Bulk [fbulk(a)MYPREMIERONLINE.COM] Sent: Friday, December 08, 2017 4:10 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Attribute Length Error today Anyone else see this today with both MICE route reflectors? Dec 8 13:38:56 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) Dec 8 13:38:56 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) Dec 8 13:39:47 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Dec 8 13:39:47 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) Dec 8 13:39:49 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Dec 8 13:39:49 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) Dec 8 13:41:28 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Dec 8 13:41:28 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) Dec 8 13:41:36 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Dec 8 13:41:36 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) Dec 8 13:44:36 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Dec 8 13:45:23 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Frank

Dec. 8, 2017

Re: Attribute Length Error today

by Doug McIntyre

On Fri, Dec 08, 2017 at 10:10:00PM +0000, Frank Bulk wrote: >Anyone else see this today with both MICE route reflectors? > >Dec 8 13:38:56 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) >Dec 8 13:38:56 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) >Dec 8 13:39:47 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) >Dec 8 13:39:47 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) >Dec 8 13:39:49 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) >Dec 8 13:39:49 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) >Dec 8 13:41:28 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) >Dec 8 13:41:28 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) >Dec 8 13:41:36 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) >Dec 8 13:41:36 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) >Dec 8 13:44:36 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) >Dec 8 13:45:23 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Which AS are you? No, but at the same time on the BIRD side we saw 2017-12-08 13:39:55 <RMT> NASN_26794: Received: Invalid attribute length: 400200400304ce6c 2017-12-08 13:39:55 <RMT> NASN_54578: Received: Invalid attribute length: 400200400304ce6c 2017-12-08 13:39:55 <RMT> NASN_32609: Received: Malformed AS_PATH: 400200 2017-12-08 13:39:55 <RMT> NASN_22402: Received: Invalid attribute length: 400200400304ce6c 2017-12-08 13:39:55 <RMT> NASN_16842: Received: Malformed AS_PATH: 400200 2017-12-08 13:39:55 <RMT> NASN_10242: Received: Malformed AS_PATH: 400200 Which in the past meant somebody had a cisco, and wasn't doing no bgp enforce-first-as as BIRD doesn't insert the MICE AS into the AS path, and that confuses Cisco devices. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 8, 2017

Attribute Length Error today

by Frank Bulk

Anyone else see this today with both MICE route reflectors? Dec 8 13:38:56 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) Dec 8 13:38:56 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) Dec 8 13:39:47 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Dec 8 13:39:47 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) Dec 8 13:39:49 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Dec 8 13:39:49 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) Dec 8 13:41:28 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Dec 8 13:41:28 192.168.0.85 BGP: Peer 206.108.255.1 DOWN (Attribute Length Error) Dec 8 13:41:36 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Dec 8 13:41:36 192.168.0.85 BGP: Peer 206.108.255.2 DOWN (Attribute Length Error) Dec 8 13:44:36 192.168.0.85 BGP: Peer 206.108.255.1 UP (ESTABLISHED) Dec 8 13:45:23 192.168.0.85 BGP: Peer 206.108.255.2 UP (ESTABLISHED) Frank

Dec. 8, 2017

Re: SDN Communications Upgrade

by Jeremy Lumby

Correct Jeremy Lumby Minnesota VoIP 9217 17th Ave S Suite 216 Bloomington MN 55425 Main 612-355-7740 Direct 612-392-6814 EFax 952-873-7425 jlumby(a)mnvoip.com -------- Original message -------- From: Richard Laager <rlaager(a)WIKTEL.COM> Date: 12/7/17 12:30 PM (GMT-06:00) To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] SDN Communications Upgrade _____ >From : Richard Laager [rlaager(a)WIKTEL.COM] To : MICE-DISCUSS(a)LISTS.IPHOUSE.NET [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] Date : Thursday, December 7 2017 12:30:33 On 12/05/2017 03:38 PM, Jason Hanke wrote: > SDN is upgrading their connection to 20g from 10G. > > Please use Ethernet5/5 on the Main Switch to SDN. This will be Po19, I presume? -- Richard

Dec. 7, 2017

Re: SDN Communications Upgrade

by Richard Laager

On 12/05/2017 03:38 PM, Jason Hanke wrote: > SDN is upgrading their connection to 20g from 10G. > > Please use Ethernet5/5 on the Main Switch to SDN. This will be Po19, I presume? -- Richard

Dec. 7, 2017

SDN Communications Upgrade

by Jason Hanke

SDN is upgrading their connection to 20g from 10G. Please use Ethernet5/5 on the Main Switch to SDN. The LOA/CFA has been filed with Cologix. Please provide an Arista compatible SFP+ optic. Thanks! -- 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

Dec. 5, 2017

Passive BFD support on Route-Server #1

by Doug McIntyre

Just to close this project out, I'll set a schedule to get this done. On Monday, 12/11/2017 at 12:30AM, I'll turn on passive BFD on the MICE route server #1 (206.108.255.1/ 2001:504:27::d1af:0:1) for all connections. In our testing, we've seen passive listening does pretty much what everybody expects, if you want to talk BFD, it is ready to go for you off the bat, if you don't want to do it, then nothing breaks. This will be the standard moving forward, and has been testing for sometime for 17 participants already (5 active, 12 not actively partipatching). If you don't want even passive BFD enabled for your route-server connection, let me know and I can specificly configure you out of passive participation. But we have had zero problems or comments on the dozen that are in now. If it all goes well, I'll do the same on Route server #2 (206.108.255.2/2001:504:27::d1af:0:2) by the end of the year. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Dec. 4, 2017

MICE UG 26 Meeting

by Richard Laager

The MICE UG 26 meeting will be held this Tuesday (not our typical Wednesday), December 5, 3:00 pm, at the 511 Building Cafeteria, 11th Avenue South, Minneapolis, MN. The agenda and UG 25 minutes are attached. I believe the remote conferencing will be the same as before: 952-562-5400 passcode MICE (6423). -- Richard

Dec. 3, 2017

Please Welcome Otter Com to MICE!

by Jason Hanke

Name: Otter Com Inc ASN: 25637 Port: CNS Remote Ten2/3 IPv4: 206.108.255.83 IPv6: 2001:504:27:0:0:6425::1 BFD Support: NO Route Server: NO Peering Contact: noc(a)parkregion.com Please create a PeeringDB.com entry when you connect to the exchange. All members are also strongly encouraged to join the MICE-DISCUS mailing list. Welcome Aboard! -- 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

Nov. 30, 2017

HE 100G Upgrade

by Jason Hanke

Hurricane Electric is upgrading their MICE connection to 100g Ethernet3/5/1 (Main Switch) -- 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

Nov. 30, 2017

UG 26 - Call for Agenda

by Richard Laager

Reminder: UG 26 is December 5, 3:00pm, at the 511 Building Cafeteria If you have agenda items for the upcoming UG 26, please send them to me. -- Richard

Nov. 27, 2017

Re: Cacti Graphing problem

by David Farmer

Ok, I thought that might be the case. Thanks. On Tue, Nov 14, 2017 at 4:00 PM, anthonyanderberg(a)nu-telecom.net < anthonyanderberg(a)nu-telecom.net> wrote: > Oh sorry I wasn’t clear: those data points are lost because they were > above the RRD’s maximum expected value and so weren’t recorded (as if they > were bogus data.) I’ve edited your RRD file to increased that max value > so it’ll accept higher values going forward. > > > > > > Cheers, > > anthony > > > > *Anthony Anderberg* > > Sr. Systems Analyst > > [image: NUtel_email_logo_1] > > 320-234-5239 <(320)%20234-5239> > > anthonyanderberg(a)nu-telecom.net > > *www.nutelecom.net <http://www.nutelecom.net>* > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *David Farmer > *Sent:* Tuesday, November 14, 2017 3:37 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] Cacti Graphing problem > > > > Still seems to be the same, or do we have to wait until we break 34G or so > again. > > > > But, thanks for looking at it, though. > > > > > > > > On Tue, Nov 14, 2017 at 3:21 PM, anthonyanderberg(a)nu-telecom.net < > anthonyanderberg(a)nu-telecom.net> wrote: > > That’s a side effect of retaining everyone’s RRD history, I’ve had to edit > a couple RRD files to reflect their interface’s new order-of-magnitude > speed increases - have done yours now too. > > > > Cheers, > > anthony > > > > > > *Anthony Anderberg* > > Sr. Systems Analyst > > [image: NUtel_email_logo_1] > > 320-234-5239 <(320)%20234-5239> > > anthonyanderberg(a)nu-telecom.net > > *www.nutelecom.net <http://www.nutelecom.net>* > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *David Farmer > *Sent:* Tuesday, November 14, 2017 2:36 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* [MICE-DISCUSS] Cacti Graphing problem > > > > Our graph on cacti I being cut off, see the following, we moved from a 30G > lag to a 100G a few week ago and today are significantly exceeding 30G for > the first time. > > > > Thanks > > > > [image: Inline image 1] > > > > -- > > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > > ------------------------------ > > 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 > > > > > > -- > > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > > ------------------------------ > > 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 > -- =============================================== 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 ===============================================

Nov. 14, 2017

Re: Cacti Graphing problem

by anthonyanderberg＠nu-telecom.net

Oh sorry I wasn’t clear: those data points are lost because they were above the RRD’s maximum expected value and so weren’t recorded (as if they were bogus data.) I’ve edited your RRD file to increased that max value so it’ll accept higher values going forward. Cheers, anthony Anthony Anderberg Sr. Systems Analyst [NUtel_email_logo_1] 320-234-5239 anthonyanderberg(a)nu-telecom.net<mailto:anthonyanderberg@nu-telecom.net> www.nutelecom.net<http://www.nutelecom.net> From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Tuesday, November 14, 2017 3:37 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Cacti Graphing problem Still seems to be the same, or do we have to wait until we break 34G or so again. But, thanks for looking at it, though. On Tue, Nov 14, 2017 at 3:21 PM, anthonyanderberg(a)nu-telecom.net<mailto:anthonyanderberg@nu-telecom.net> <anthonyanderberg(a)nu-telecom.net<mailto:anthonyanderberg@nu-telecom.net>> wrote: That’s a side effect of retaining everyone’s RRD history, I’ve had to edit a couple RRD files to reflect their interface’s new order-of-magnitude speed increases - have done yours now too. Cheers, anthony Anthony Anderberg Sr. Systems Analyst [NUtel_email_logo_1] 320-234-5239<tel:(320)%20234-5239> anthonyanderberg(a)nu-telecom.net<mailto:anthonyanderberg@nu-telecom.net> www.nutelecom.net<http://www.nutelecom.net> From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of David Farmer Sent: Tuesday, November 14, 2017 2:36 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] Cacti Graphing problem Our graph on cacti I being cut off, see the following, we moved from a 30G lag to a 100G a few week ago and today are significantly exceeding 30G for the first time. Thanks [Inline image 1] -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE<https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> Phone: 612-626-0815<tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952<tel:(612)%20812-9952> =============================================== ________________________________ 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 -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@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 =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Nov. 14, 2017

Re: Cacti Graphing problem

by David Farmer

Still seems to be the same, or do we have to wait until we break 34G or so again. But, thanks for looking at it, though. On Tue, Nov 14, 2017 at 3:21 PM, anthonyanderberg(a)nu-telecom.net < anthonyanderberg(a)nu-telecom.net> wrote: > That’s a side effect of retaining everyone’s RRD history, I’ve had to edit > a couple RRD files to reflect their interface’s new order-of-magnitude > speed increases - have done yours now too. > > > > Cheers, > > anthony > > > > > > *Anthony Anderberg* > > Sr. Systems Analyst > > [image: NUtel_email_logo_1] > > 320-234-5239 <(320)%20234-5239> > > anthonyanderberg(a)nu-telecom.net > > *www.nutelecom.net <http://www.nutelecom.net>* > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *David Farmer > *Sent:* Tuesday, November 14, 2017 2:36 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* [MICE-DISCUSS] Cacti Graphing problem > > > > Our graph on cacti I being cut off, see the following, we moved from a 30G > lag to a 100G a few week ago and today are significantly exceeding 30G for > the first time. > > > > Thanks > > > > [image: Inline image 1] > > > > -- > > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > > ------------------------------ > > 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 > -- =============================================== 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 ===============================================

Nov. 14, 2017

Re: Cacti Graphing problem

by anthonyanderberg＠nu-telecom.net

That’s a side effect of retaining everyone’s RRD history, I’ve had to edit a couple RRD files to reflect their interface’s new order-of-magnitude speed increases - have done yours now too. Cheers, anthony Anthony Anderberg Sr. Systems Analyst [NUtel_email_logo_1] 320-234-5239 anthonyanderberg(a)nu-telecom.net<mailto:anthonyanderberg@nu-telecom.net> www.nutelecom.net<http://www.nutelecom.net> From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Tuesday, November 14, 2017 2:36 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Cacti Graphing problem Our graph on cacti I being cut off, see the following, we moved from a 30G lag to a 100G a few week ago and today are significantly exceeding 30G for the first time. Thanks [Inline image 1] -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@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 =============================================== ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Nov. 14, 2017

Cacti Graphing problem

by David Farmer

Our graph on cacti I being cut off, see the following, we moved from a 30G lag to a 100G a few week ago and today are significantly exceeding 30G for the first time. Thanks [image: Inline image 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 ===============================================

Nov. 14, 2017

Looks like Yahoo had blip

by Frank Bulk

[cid:image001.png@01D35B11.0E5E7780] Nov 11 17:00:50 192.168.0.85 BGP: Peer 206.108.255.58 DOWN (Hold Timer Expired) Nov 11 17:00:51 192.168.0.85 BGP: Peer 2001:504:27::2846:0:2 DOWN (Hold Timer Expired) Nov 11 17:00:54 192.168.0.85 BGP: Peer 206.108.255.59 DOWN (Hold Timer Expired) Nov 11 17:00:55 192.168.0.85 BGP: Peer 2001:504:27::2846:0:1 DOWN (Hold Timer Expired) Nov 11 17:05:33 192.168.0.85 BGP: Peer 206.108.255.58 UP (ESTABLISHED) Nov 11 17:05:34 192.168.0.85 BGP: Peer 206.108.255.59 UP (ESTABLISHED) Nov 11 17:05:43 192.168.0.85 BGP: Peer 2001:504:27::2846:0:2 UP (ESTABLISHED) Nov 11 17:05:43 192.168.0.85 BGP: Peer 2001:504:27::2846:0:1 UP (ESTABLISHED)

Nov. 11, 2017

Re: Looking glass

by Frank Bulk

That would be great if a *new* router could be put in place. The old one wouldn't have to be turned down until the graphing stuff is all worked out with the new one. Frank -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Justin Krejci Sent: Thursday, November 09, 2017 11:04 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Looking glass There is an old Cisco router in place now as the LG router. If a network topology change is being considered for the router, it seems like it would be a good time to swap over the *new* router, the one Jeremy and I mounted (less old hardware, less old IOS, and a bit more beefy hardware specs) a few months ago into the MICE cabinet with essentially a duplicate config. It can obviously handle multi-homing so one gig interface could be on the MICE network (as it currently sits) and one gig interface could go somewhere else (eg iphouse, USI, etc) with full Internet reachability. Especially given the bandwidth needs of such a router are quite minimal, I doubt anyone would have problems with donation. Heck, could even spin up a separate MICE VLAN for this second interface in order to just use existing cross-connects if so desired. Side note, changing out the router may require a few tweaks to the current traffic graphing scripts used for BGP route collections and what not, possibly other things/record keeping might be needed as well: DNS records, device/network documentation, some ACL's on the router for the possible new Interface being used, other things my tired brain isn't conceiving at the moment, etc. ________________________________________ From: MICE Discuss [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] on behalf of Nevin Lyne [nevin(a)ENGINEHOSTING.COM] Sent: Thursday, November 09, 2017 1:14 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Looking glass On Thursday, November 9, 2017 1:02pm, "DeLong, Owen" <00000005a669d12e-dmarc-request(a)LISTS.IPHOUSE.NET> said: > Seems to me that putting a port on the LG server on the same network as the MICE > web site wouldn't be a bad plan if there's appropriate physical > proximity to make this easy. > > Owen The MICE web site hosting is donated/provided by us, but we are not directly on the exchange, our connection to MICE is provided by IPHouse's peering on MICE. So I don't see that working for the LG. -- Nevin Lyne -- Founder & Director of Technology -- Arcustech, LLC. - arcustech.com -- Gippy's Internet Solutions, LLC. - enginehosting.com

Nov. 11, 2017

Re: Looking glass

by Justin Krejci

There is an old Cisco router in place now as the LG router. If a network topology change is being considered for the router, it seems like it would be a good time to swap over the *new* router, the one Jeremy and I mounted (less old hardware, less old IOS, and a bit more beefy hardware specs) a few months ago into the MICE cabinet with essentially a duplicate config. It can obviously handle multi-homing so one gig interface could be on the MICE network (as it currently sits) and one gig interface could go somewhere else (eg iphouse, USI, etc) with full Internet reachability. Especially given the bandwidth needs of such a router are quite minimal, I doubt anyone would have problems with donation. Heck, could even spin up a separate MICE VLAN for this second interface in order to just use existing cross-connects if so desired. Side note, changing out the router may require a few tweaks to the current traffic graphing scripts used for BGP route collections and what not, possibly other things/record keeping might be needed as well: DNS records, device/network documentation, some ACL's on the router for the possible new Interface being used, other things my tired brain isn't conceiving at the moment, etc. ________________________________________ From: MICE Discuss [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] on behalf of Nevin Lyne [nevin(a)ENGINEHOSTING.COM] Sent: Thursday, November 09, 2017 1:14 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Looking glass On Thursday, November 9, 2017 1:02pm, "DeLong, Owen" <00000005a669d12e-dmarc-request(a)LISTS.IPHOUSE.NET> said: > Seems to me that putting a port on the LG server on the same network as the MICE > web site wouldn’t be a bad plan if there’s appropriate physical > proximity to make this easy. > > Owen The MICE web site hosting is donated/provided by us, but we are not directly on the exchange, our connection to MICE is provided by IPHouse's peering on MICE. So I don't see that working for the LG. -- Nevin Lyne -- Founder & Director of Technology -- Arcustech, LLC. - arcustech.com -- Gippy's Internet Solutions, LLC. - enginehosting.com

Nov. 10, 2017

Re: Looking glass

by Nevin Lyne

On Thursday, November 9, 2017 1:02pm, "DeLong, Owen" <00000005a669d12e-dmarc-request(a)LISTS.IPHOUSE.NET> said: > Seems to me that putting a port on the LG server on the same network as the MICE > web site wouldn’t be a bad plan if there’s appropriate physical > proximity to make this easy. > > Owen The MICE web site hosting is donated/provided by us, but we are not directly on the exchange, our connection to MICE is provided by IPHouse's peering on MICE. So I don't see that working for the LG. -- Nevin Lyne -- Founder & Director of Technology -- Arcustech, LLC. - arcustech.com -- Gippy's Internet Solutions, LLC. - enginehosting.com

Nov. 9, 2017

Re: Looking glass

by DeLong, Owen

Seems to me that putting a port on the LG server on the same network as the MICE web site wouldn’t be a bad plan if there’s appropriate physical proximity to make this easy. Owen > On Nov 3, 2017, at 10:30 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > > On Fri, Nov 03, 2017 at 11:01:49AM -0500, Andrew Hoyos wrote: >> Does MICE itself have general use transit available for website, OOB, graphing servers, etc, where this LG (or at least 1 leg of it) could live instead? > > > ipHouse has donated some transit for MICE use in the past. It can > still keep doing that if this is desired to be moved to a transitable > IP address. > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades

Nov. 9, 2017

Re: Looking glass

by Doug McIntyre

On Fri, Nov 03, 2017 at 11:01:49AM -0500, Andrew Hoyos wrote: >Does MICE itself have general use transit available for website, OOB, graphing servers, etc, where this LG (or at least 1 leg of it) could live instead? ipHouse has donated some transit for MICE use in the past. It can still keep doing that if this is desired to be moved to a transitable IP address. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Nov. 3, 2017

Re: Looking glass

by Steve Howard

Nov. 3, 2017

Re: Looking glass

by Andrew Hoyos

Yeah, that seems like a bad idea. Generally speaking, folks should never really be carrying the MICE /24 in their IGP’s anyway. It’s a bad idea, and can be harmful. Not carrying it (and using next-hop-self) protects both you and MICE. The IXP prefix shouldn’t, in theory, really be reachable from any device not directly connected in to that /24. Does MICE itself have general use transit available for website, OOB, graphing servers, etc, where this LG (or at least 1 leg of it) could live instead? -- Andrew Hoyos hoyosa(a)gmail.com > On Nov 3, 2017, at 10:30 AM, Steve Howard <showard(a)paulbunyan.net> wrote: > > Note that the IP address for the Looking Glass is within the MICE IP space and probably does not have connectivity to the global internet. Perhaps something to look at in the future? > > > On 11/03/2017 07:39 AM, Doug McIntyre wrote: >> On Fri, Nov 03, 2017 at 09:15:09AM +0000, Frank Bulk wrote: >>> Is the MICE Looking Glass down? When I telnet or SSH to it, I get no prompt. >> >> Hmm, doesn't seem to be. Works for me. (both ssh & telnet). >> Which hostname are you using? >> >> $ ssh rviews(a)lg.micemn.net C >> >> ********************************************************************** >> >> >> >> MICE MN BGP Route Views >> >> http://www.micemn.net/ >> >> >> >> This router has views of the full routing table from the route reflectors >> >> of the MICEMN peering point in Minneapolis, MN, USA. >> The list of participants are located at http://www.micemn.net/participants.html >> >> >> >> Login with username 'rviews' to access the router via telnet/ssh. >> ********************************************************************** >> >> >> >> >> >> >> micemn-lg>show ip route >> Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP >> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 >> E1 - OSPF external type 1, E2 - OSPF external type 2 >> i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 >> ia - IS-IS inter area, * - candidate default, U - per-user static route >> o - ODR, P - periodic downloaded static route >> >> Gateway of last resort is 216.250.183.14 to network 0.0.0.0 >> >> B 204.221.17.0/24 [20/25] via 206.108.255.121, 2d20h >> B 203.221.22.0/24 [20/474] via 206.108.255.52, 3w1d >> B 192.170.106.0/24 [20/474] via 206.108.255.52, 7w0d >> B 199.16.214.0/24 [20/95] via 206.108.255.52, 2w0d >> B 194.50.241.0/24 [20/1265] via 206.108.255.52, 5d19h >> B 202.70.142.0/24 [20/474] via 206.108.255.52, 3w1d >> B 202.49.249.0/24 [20/260] via 206.108.255.52, 7w0d >> B 196.223.25.0/24 [20/960] via 206.108.255.52, 1d23h >> B 203.18.218.0/24 [20/474] via 206.108.255.52, 3w1d >> B 202.154.83.0/24 [20/474] via 206.108.255.52, 7w0d >> B 203.190.112.0/24 [20/1970] via 206.108.255.52, 1d07h >> B 199.5.199.0/24 [20/90] via 206.108.255.52, 3w1d >> B 208.66.148.0/24 [20/308] via 206.108.255.52, 5w3d >> B 203.142.67.0/24 [20/1970] via 206.108.255.52, 17:42:42 >> B 199.96.161.0/24 [20/265] via 206.108.255.52, 1d14h >> B 192.189.123.0/24 [20/81] via 206.108.255.52, 4w3d >> B 192.83.149.0/24 [20/482] via 206.108.255.52, 2w3d >> >> ... >> >> >> > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

Nov. 3, 2017

Re: Looking glass

by Steve Howard

Nov. 3, 2017

Re: Looking glass

by Doug McIntyre

On Fri, Nov 03, 2017 at 09:15:09AM +0000, Frank Bulk wrote: >Is the MICE Looking Glass down? When I telnet or SSH to it, I get no prompt. Hmm, doesn't seem to be. Works for me. (both ssh & telnet). Which hostname are you using? $ ssh rviews(a)lg.micemn.net C ********************************************************************** MICE MN BGP Route Views http://www.micemn.net/ This router has views of the full routing table from the route reflectors of the MICEMN peering point in Minneapolis, MN, USA. The list of participants are located at http://www.micemn.net/participants.html Login with username 'rviews' to access the router via telnet/ssh. ********************************************************************** micemn-lg>show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 216.250.183.14 to network 0.0.0.0 B 204.221.17.0/24 [20/25] via 206.108.255.121, 2d20h B 203.221.22.0/24 [20/474] via 206.108.255.52, 3w1d B 192.170.106.0/24 [20/474] via 206.108.255.52, 7w0d B 199.16.214.0/24 [20/95] via 206.108.255.52, 2w0d B 194.50.241.0/24 [20/1265] via 206.108.255.52, 5d19h B 202.70.142.0/24 [20/474] via 206.108.255.52, 3w1d B 202.49.249.0/24 [20/260] via 206.108.255.52, 7w0d B 196.223.25.0/24 [20/960] via 206.108.255.52, 1d23h B 203.18.218.0/24 [20/474] via 206.108.255.52, 3w1d B 202.154.83.0/24 [20/474] via 206.108.255.52, 7w0d B 203.190.112.0/24 [20/1970] via 206.108.255.52, 1d07h B 199.5.199.0/24 [20/90] via 206.108.255.52, 3w1d B 208.66.148.0/24 [20/308] via 206.108.255.52, 5w3d B 203.142.67.0/24 [20/1970] via 206.108.255.52, 17:42:42 B 199.96.161.0/24 [20/265] via 206.108.255.52, 1d14h B 192.189.123.0/24 [20/81] via 206.108.255.52, 4w3d B 192.83.149.0/24 [20/482] via 206.108.255.52, 2w3d ... -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Nov. 3, 2017

Looking glass

by Frank Bulk

Is the MICE Looking Glass down? When I telnet or SSH to it, I get no prompt. Kind regards, Frank

Nov. 3, 2017

Re: MICE UG 25 Meeting

by Richard Laager

The (draft) UG 25 minutes are available at the usual place: http://micemn.net/resources.html Direct link: http://micemn.net/files/MICE%20UG%2025%20-%20Minutes.pdf Thanks to Mike Johnston for taking minutes! -- Richard

Nov. 1, 2017

Re: Graph Updates

by Richard Laager

On 10/30/2017 12:39 PM, anthonyanderberg(a)nu-telecom.net wrote: > I’ve been watching the Aggregate Ingress/Egress graph values diverge > with increasing discomfort and finally had a couple free hours to look > into it yesterday and found the combination of the last round of CDN LAG > upgrades and cruft left over from migrating from the old Juniper core > was causing the Ingress values to skew high. In the end it was easier > to just create a new Aggregate graph so I’ve done that and will remove > the old graph once the web site is updated: > > http://micelg.usinternet.com/export/graph_1430.html Thanks for looking into this. I have updated the website. -- Richard

Oct. 30, 2017

Graph Updates

by anthonyanderberg＠nu-telecom.net

I've been watching the Aggregate Ingress/Egress graph values diverge with increasing discomfort and finally had a couple free hours to look into it yesterday and found the combination of the last round of CDN LAG upgrades and cruft left over from migrating from the old Juniper core was causing the Ingress values to skew high. In the end it was easier to just create a new Aggregate graph so I've done that and will remove the old graph once the web site is updated: http://micelg.usinternet.com/export/graph_1430.html I also took the time to dig into the IP4/6 Peer/Prefix graphs and think I've got them (mostly) fixed now too, they're under the "Route Server" menu item in Cacti. Thanks for everyone's suggestions on that topic. As always let me know if anything seems wrong or silly. Cheers, anthony Anthony Anderberg Sr. Systems Analyst [NUtel_email_logo_1] 320-234-5239 anthonyanderberg(a)nu-telecom.net<mailto:anthonyanderberg@nu-telecom.net> www.nutelecom.net<http://www.nutelecom.net>

Oct. 30, 2017

Re: Multi-IX Traffic Management?

by Michael Hare

We (AS 3128) are mostly a Juniper shop. There are situations where our longhaul is not redundant and less diverse than you would hope. It is a problem easily solved with $$. At times this unfortunate situation leaves us with several hundred thousand routes to converge; it takes time. We're looking at JunOS 16 for deployment this winter. In addition to RPD being slightly threaded, JunOS 16.1 has features to optimize the order of processing RIB changes (policy-statement based). Our challenge becomes defining priority, optimizing on bandwidth per AS/subnet doesn't necessarily tell the whole story, some low bandwidth things (DNS) are paramount [and thankfully rather static]. For now we also have our internet tables in global unicast table. JunOS currently has features that allow you to program a secondary forwarding next hop but it is reserved for l3vpns. Doing that for the global unicast table is an uncommitted ER. I haven't yet started to seriously explore putting the internet in a VRF. -Michael >>-----Original Message----- >>From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf >>Of Jason Hanke >>Sent: Monday, October 30, 2017 9:01 AM >>To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >>Subject: Re: [MICE-DISCUSS] Multi-IX Traffic Management? >> >>As a transport seller, We're seeing most networks most commonly buy >>linear paths to two or more IXes. Typically going opposite directions >>from their home base. We're also starting to see smaller operators >>exclusively doing remote peering. A typical set up is buying identical >>transport to the 2 adjacent IX buildings. >> >>On wavelengths, the link failure can be passed back to from end to >>end. Granted, a long-haul wavelength isn't as stable as a cross >>connect. >> >>If a network doesn't have any remote gear the convergence is governed >>by EBGP vs IBGP/IGP if there is an additional router. For remote >>setups, in particular with Ethernet transport we're seeing more and >>more BFD on the sessions. >> >>Jay >> >>On Mon, Oct 30, 2017 at 8:27 AM, Michael Hare <michael.hare(a)wisc.edu> >>wrote: >>> For those buying wavelengths (compared to an mpls circuit), are you >>buying diverse transport? If not, how are you dealing with convergence >>stability? >>> >>> -Michael >>> >>>>>-----Original Message----- >>>>>From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On >>Behalf >>>>>Of Colin Baker >>>>>Sent: Friday, October 27, 2017 3:29 PM >>>>>To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >>>>>Subject: Re: [MICE-DISCUSS] Multi-IX Traffic Management? >>>>> >>>>>On 27.10.2017 15:01, Matthew Beckwell wrote: >>>>>> For my own curiosity: >>>>>> >>>>>> I've seen quite a few networks in the last year or so connecting >>>>>> themselves to other out-of-market IX's (I presume getting some cheap >>>>>> wavelengths and bringing it back to Minnesota). >>>>>> >>>>>> A couple of questions for those of you that are doing this: >>>>>> >>>>>> 1. I'm assuming this is enabling you to accommodate requirements >>from >>>>>> other networks that require peering at multiple locations, even though >>>>>> technically your network doesn't really extend that far (or maybe it's >>>>>> something else?). >>>>> >>>>>For us, the goal is to reach networks which are not on exchanges which >>>>>we're already connected. The big ones are at MICE, but there are other >>>>>exchanges we can get to reasonably inexpensively that have such a large >>>>>number of networks connected that it makes sense financially >>(compared >>>>>to buying more transit). Traffic from a huge number of ASNs, >>>>>particularly if most are on a route server, can really add up. >>>>> >>>>>Peering in multiple locations is a nice benefit to this, but usually not >>>>>a primary goal for us. >>>>> >>>>>> 2. How are folks monitoring, managing, or manipulating this >>>>>> out-of-market traffic? (Using BGP MED, Prepending, Localpref, or some >>>>>> other mechanism to "prefer" your traffic enter and exit closer to >>>>>> where you really are?) >>>>> >>>>>If you haven't already, install as-stats >>>>>(https://github.com/manuelkasper/AS-Stats) to monitor things, which >>will >>>>>make it clear if something is out of whack. In most cases, our IGP >>>>>handles outbound traffic in a way the makes sense. Inbound traffic can >>>>>be trickier - a few networks will publish action communities or accept >>>>>MEDs, and we utilize those tools when available. Prepending is >>>>>occasionally useful. Announcing more specifics in certain spots always >>>>>felt like a jerk move so I tend to avoid that, but that's a thing I >>>>>suppose. >>>>> >>>>>-- >>>>>Colin Baker >>>>>SupraNet Communications, Inc. >>>>>(608) 572-7634 >>>>>colinb(a)supranet.net >>>>> >>>>>This message is subject to the SupraNet Email Confidentiality Policy >>>>>which is located at http://supranet.net/confidentiality >> >> >> >>-- >>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

Oct. 30, 2017