- mice-discuss - lists.micemn.net

Re: Fwd: [#ZMH-397-87500]: Legacy IP Space from Airstream

by Richard Laager

Looking at my ARP table, I converted as many MAC addresses as possible back to IPs in the new block. Then I looked those up in the participants list. I've copied the direct email addresses. Hopefully that will get the relevant networks to remove the old addresses faster. On Mon, 2014-08-18 at 15:39, Charles Monson <support(a)wins.net> wrote: > We noticed there are still a few address with the legacy > 69.147.218.0/24 IP space from Airstream Communications (WIN) still > configured on the MICE exchange. I would expect everyone has moved to > the new address space by now and probably just didn't remove the > secondary IP addresses. We would like use this space for other > purposes now that everyone should be migrated, but don't want to have > routing issues for anyone with it still configured. > > Listed below are the IP addresses and corresponding MAC addresses > still showing up when I check the ARP table (our side has > 69.147.218.10 configured). > #show arp gig1/11 | i 69.147.218 > Internet 69.147.218.101 22 5c5e.abd5.9ef0 ARPA GigabitEthernet1/11 > Internet 69.147.218.103 48 000c.2923.4e35 ARPA GigabitEthernet1/11 > Internet 69.147.218.44 0 b0c6.9ade.0640 ARPA GigabitEthernet1/11 > Internet 69.147.218.50 150 0023.33c6.a0c0 ARPA GigabitEthernet1/11 > Internet 69.147.218.53 164 10f3.1134.e6de ARPA GigabitEthernet1/11 > Internet 69.147.218.104 16 5c5e.abd0.da78 ARPA GigabitEthernet1/11 > Internet 69.147.218.250 175 0004.9ba4.3000 ARPA GigabitEthernet1/11 Here's what I found: 206.108.255.101 Compudyne ipadmin(a)compudyne.net 206.108.255.103 Genesis Wireless/RevNetData info(a)genesiswireless.com b0c6.9ade.0640 Mankato MICE Switch, already being looked at. 206.108.255.50 Cooperative Network Services (CNS) peering(a)paulbunyan.net 206.108.255.53 Stellar Association ipadmin(a)stellarllc.net 206.108.255.104 Windomnet (City of Windom) noc(a)windomnet.com 0004.9ba4.3000 ??? -- Richard

Aug. 18, 2014

Re: Fwd: [#ZMH-397-87500]: Legacy IP Space from Airstream

by Doug McIntyre

> Internet 69.147.218.101 22 5c5e.abd5.9ef0 ARPA GigabitEthernet1/11 Mankato Switch 5c:5e:ab:d5:9e:f0 Learn 0 ge-0/0/8.0 > Internet 69.147.218.103 48 000c.2923.4e35 ARPA GigabitEthernet1/11 Mankato Switch 00:0c:29:23:4e:35 Learn 0 ge-0/0/23.0 > Internet 69.147.218.44 0 b0c6.9ade.0640 ARPA GigabitEthernet1/11 Mankato Switch b0:c6:9a:de:06:40 Learn 0 ge-0/0/23.0 > Internet 69.147.218.50 150 0023.33c6.a0c0 ARPA GigabitEthernet1/11 CNS Remote Switch (don't have a login there) > Internet 69.147.218.53 164 10f3.1134.e6de ARPA GigabitEthernet1/11 CNS Remote Switch (don't have a login there) > Internet 69.147.218.104 16 5c5e.abd0.da78 ARPA GigabitEthernet1/11 Mankato Switch 5c:5e:ab:d0:da:78 Learn 0 ge-0/0/1.0 > Internet 69.147.218.250 175 0004.9ba4.3000 ARPA GigabitEthernet1/11 Looking-glass. I removed the secondary IP on it finally. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Aug. 18, 2014

Re: Fwd: [#ZMH-397-87500]: Legacy IP Space from Airstream

by Levi Pederson

Mark, Mankato Networks - MICE Switch is currently using 69.147.218.44 on VLAN 899 Currently looking into other IPs as well as whether or not this IP is being used by our system. Thank you *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipederson(a)mankatonetworks.net On Mon, Aug 18, 2014 at 4:08 PM, Jay Hanke <jayhanke(a)mankatonetworks.net> wrote: > ---------- Forwarded message ---------- > From: Charles Monson <support(a)wins.net> > Date: Mon, Aug 18, 2014 at 3:39 PM > Subject: [#ZMH-397-87500]: Legacy IP Space from Airstream > To: peering(a)micemn.net > > > Good Afternoon, > > We noticed there are still a few address with the legacy > 69.147.218.0/24 IP space from Airstream Communications (WIN) still > configured on the MICE exchange. I would expect everyone has moved to > the new address space by now and probably just didn't remove the > secondary IP addresses. We would like use this space for other > purposes now that everyone should be migrated, but don't want to have > routing issues for anyone with it still configured. > > Listed below are the IP addresses and corresponding MAC addresses > still showing up when I check the ARP table (our side has > 69.147.218.10 configured). Can you contact whoever is still using this > space or is that something you'd prefer us to do? > > #show arp gig1/11 | i 69.147.218 > Internet 69.147.218.101 22 5c5e.abd5.9ef0 ARPA GigabitEthernet1/11 > Internet 69.147.218.103 48 000c.2923.4e35 ARPA GigabitEthernet1/11 > Internet 69.147.218.44 0 b0c6.9ade.0640 ARPA GigabitEthernet1/11 > Internet 69.147.218.50 150 0023.33c6.a0c0 ARPA GigabitEthernet1/11 > Internet 69.147.218.53 164 10f3.1134.e6de ARPA GigabitEthernet1/11 > Internet 69.147.218.104 16 5c5e.abd0.da78 ARPA GigabitEthernet1/11 > Internet 69.147.218.250 175 0004.9ba4.3000 ARPA GigabitEthernet1/11 > > Thank you, > > Charles Monson > Associate Network Administrator > Wisconsin Independent Network > Airstream Communications > Phone: 866-206-2027 > > Ticket Details > ________________________________ > Ticket ID: ZMH-397-87500 > Department: Network Admins > Type: Request > Status: In Progress > Priority: Normal > > Support Center: https://support.wins.net/index.php? > > > -- > Jay Hanke > CEO, CCIE #19093 > Mankato Networks LLC > PO Box 54 > 619 S Front St > Mankato, MN 56001-3838 > Google 530-618-2398 > jayhanke(a)mankatonetworks.net > http://www.mankatonetworks.com > http://www.neutralpath.net >

Aug. 18, 2014

Fwd: [#ZMH-397-87500]: Legacy IP Space from Airstream

by Jay Hanke

---------- Forwarded message ---------- From: Charles Monson <support(a)wins.net> Date: Mon, Aug 18, 2014 at 3:39 PM Subject: [#ZMH-397-87500]: Legacy IP Space from Airstream To: peering(a)micemn.net Good Afternoon, We noticed there are still a few address with the legacy 69.147.218.0/24 IP space from Airstream Communications (WIN) still configured on the MICE exchange. I would expect everyone has moved to the new address space by now and probably just didn't remove the secondary IP addresses. We would like use this space for other purposes now that everyone should be migrated, but don't want to have routing issues for anyone with it still configured. Listed below are the IP addresses and corresponding MAC addresses still showing up when I check the ARP table (our side has 69.147.218.10 configured). Can you contact whoever is still using this space or is that something you'd prefer us to do? #show arp gig1/11 | i 69.147.218 Internet 69.147.218.101 22 5c5e.abd5.9ef0 ARPA GigabitEthernet1/11 Internet 69.147.218.103 48 000c.2923.4e35 ARPA GigabitEthernet1/11 Internet 69.147.218.44 0 b0c6.9ade.0640 ARPA GigabitEthernet1/11 Internet 69.147.218.50 150 0023.33c6.a0c0 ARPA GigabitEthernet1/11 Internet 69.147.218.53 164 10f3.1134.e6de ARPA GigabitEthernet1/11 Internet 69.147.218.104 16 5c5e.abd0.da78 ARPA GigabitEthernet1/11 Internet 69.147.218.250 175 0004.9ba4.3000 ARPA GigabitEthernet1/11 Thank you, Charles Monson Associate Network Administrator Wisconsin Independent Network Airstream Communications Phone: 866-206-2027 Ticket Details ________________________________ Ticket ID: ZMH-397-87500 Department: Network Admins Type: Request Status: In Progress Priority: Normal Support Center: https://support.wins.net/index.php? -- Jay Hanke CEO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 jayhanke(a)mankatonetworks.net http://www.mankatonetworks.com http://www.neutralpath.net

Aug. 18, 2014

Re: Stormy exchange?

by Andrew Hoyos

If you look at the MICE traffic stats, pretty apparent spike of traffic on all ports at same time in same volume (ie: broadcast traffic/loop) Might also consider graphing PPS on all the ports. On Aug 8, 2014, at 10:18 AM, Doug McIntyre wrote: > On Fri, Aug 08, 2014 at 10:02:57AM -0500, Thomas Johnson wrote: >> Our switch port just bounced due to storm control. Is someone breaking >> things on a Friday? > > Hmm, on the MICE Switch side of things, it looks like we lost light > just from you. > > Aug 8 09:44:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low alarm set > Aug 8 09:44:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low warning set > Aug 8 09:49:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low alarm cleared > Aug 8 09:49:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low warning cleared > > My port didn't error out (which is usually pretty sensative to it). > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades -- Andrew Hoyos hoyosa(a)gmail.com

Aug. 8, 2014

Re: Stormy exchange?

by Thomas Johnson

Cacti seems to show that *something* was going on. We haven't touched our switch today, but perhaps I have the storm threshold set too low. Aug 8 09:44:43 sw-j eswd[1303]: ESWD_ST_CTL_ERROR_IN_EFFECT: ge-1/1/0.0: storm control in effect on the port Aug 8 09:44:43 sw-j eswd[1303]: ESWD_ST_CTL_ERROR_DISABLED: ge-1/1/0.0: storm control disabled port Aug 8 09:44:43 sw-j eswd[1303]: ESWD_ST_CTL_ERROR_IN_EFFECT: ge-1/1/0.0: storm control in effect on the port Aug 8 09:49:43 sw-j eswd[1303]: ESWD_ST_CTL_ERROR_ENABLED: ge-1/1/0.0: storm control enabled port > show configuration ethernet-switching-options storm-control action-shutdown; /* MICE */ interface ge-1/1/0.0 { level 50; } On Fri, Aug 8, 2014 at 10:18 AM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > On Fri, Aug 08, 2014 at 10:02:57AM -0500, Thomas Johnson wrote: >> Our switch port just bounced due to storm control. Is someone breaking >> things on a Friday? > > Hmm, on the MICE Switch side of things, it looks like we lost light > just from you. > > Aug 8 09:44:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low alarm set > Aug 8 09:44:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low warning set > Aug 8 09:49:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low alarm cleared > Aug 8 09:49:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low warning cleared > > My port didn't error out (which is usually pretty sensative to it). > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades -- Thomas Johnson ClaimLynx, Inc. 952-593-5969 x2302 -- This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender or call ClaimLynx at (952) 593-5969.

Aug. 8, 2014

Re: Stormy exchange?

by Doug McIntyre

On Fri, Aug 08, 2014 at 10:02:57AM -0500, Thomas Johnson wrote: > Our switch port just bounced due to storm control. Is someone breaking > things on a Friday? Hmm, on the MICE Switch side of things, it looks like we lost light just from you. Aug 8 09:44:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low alarm set Aug 8 09:44:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low warning set Aug 8 09:49:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low alarm cleared Aug 8 09:49:49 MICE-SW1 chassism[1053]: link 6 SFP receive power low warning cleared My port didn't error out (which is usually pretty sensative to it). -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Aug. 8, 2014

Stormy exchange?

by Thomas Johnson

Our switch port just bounced due to storm control. Is someone breaking things on a Friday? -- Thomas Johnson ClaimLynx, Inc. 952-593-5969 x2302 -- This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender or call ClaimLynx at (952) 593-5969.

Aug. 8, 2014

Re: MICE MTU

by Hannigan, Martin

Anthony, that makes perfect sense. Thanks! On Jul 25, 2014, at 10:21 AM, Anthony Anderberg <anthonyanderberg(a)NU-TELECOM.NET> wrote: > To be clear: the exchange doesn't support jumbo frames everywhere at the moment but it is our intention to add support. It isn't that there is demand, we just don't want the exchange to silently drop traffic should two members want to exchange traffic at a larger MTU. > > > Anthony Anderberg > Sr. Systems Analyst > 320-234-5239 > anthonyanderberg(a)nu-telecom.net > www.nutelecom.net > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Hannigan, Martin > Sent: Thursday, July 24, 2014 11:40 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] MICE MTU > > > > If everyone really wants to, I'm happy to go along. I just can't imagine its worth the effort. I have to wonder why 99.99% of all other IXPs and peers in the world seem to think its not worth the effort either. > > Best, > > -M< > > > On Jul 25, 2014, at 12:27 AM, Owen DeLong <owend(a)HE.NET> wrote: > >> I think it is desirable for the fabric to be jumbo-frame compatible. >> >> In general, jumbo frame support can be a good thing and we are fully jumbo-frame capable on our backbone. >> >> I don't know of any downside to enabling jumbo frames on the fabric. Obviously enabling them on router interfaces requires the cooperation of all peers. While I'd like to see that happen, I'm guessing it's not as easy as one might hope. >> >> Owen >> >> On Jul 24, 2014, at 21:06 , Shaun Carlson <shaun.carlson(a)ARVIG.COM> wrote: >> >>> The discussion at the meeting is unfortunately missed in the briefness of the minutes. >>> >>> The IX is configured to support jumbo frames and we felt we should keep it that way going forward. This allows maximum flexibility to support possible applications of jumbo frames. >>> >>> That being said, nobody is using them or has any concrete plans (that we could identify at the meeting) to use jumbo frames. If a member has a specific application or desire to use jumbo frames, it's up to that member to work with whomever their peer is to work through the technicalities and concerns of that application. >>> >>> s >>> >>> On Thursday, July 24, 2014, Hannigan, Martin <marty(a)akamai.com> wrote: >>> >>> >>> Generally, the general IXP community has determined that the minimum exchange services configuration should be: >>> >>> http://www.open-ix.org/certification/ixp-technical-requirements/ >>> >>> If we all thought it was desired as a minimum configuration at an IXP, it would've made it in there IMHO. It didn't. If someone thinks all IXPs should do this, they should take a run at this and see if they can get the rest of the IXP community to support it (Not just Netnod and NASA). >>> >>> We have the same issue as Andrew, and we have zero interest to go to an MTU of 9000. >>> >>> >>> Best, >>> >>> -M< >>> >>> >>> >>> >>> On Jul 24, 2014, at 6:29 PM, "Koch, Andrew" <andrew.koch(a)TDSTELECOM.COM> wrote: >>> >>>> The UG 13 minutes make note that the exchange MTU is 9000 bytes. Are other members configuring their routers for an MTU of 9000? >>>> >>>> I ask as TDS has not - we have stuck with the Ethernet standard >>>> 1500 bytes. If anyone on the exchange has set an MTU of 9000 and >>>> tries to send jumbo traffic to us, it will not be accepted and no >>>> indication will be sent back to the originator. (10d in the linked >>>> document below) >>>> >>>> If no one (or few) has setup their routers for an MTU of 9000, but we as a community wish to enable this, I would recommend that we schedule a flag day so that we can minimize blackholing of traffic across the exchange. >>>> >>>> While only a draft, see >>>> http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00 for >>>> further information on IXP Jumbo Frame operation and conversion. >>>> For those that like presentations more than IETF drafts, Martin >>>> Levy (of Hurricane Electric at the time) presented this at RIPE 64 >>>> - >>>> https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Mart >>>> in_Levy_-_IX_Jumbo_Frames_-_RIPE64_EIX-WG_-_Slovenia.pdf >>>> >>>> >>>> Best Regards, >>>> >>>> Andy Koch >>>> TDS Telecom - IP Network Operations andrew.koch(a)tdstelecom.com >>>> Desk: 608-664-4694 >>>> Cell: 608-616-0072 >>>> >>>> >>>> >>>> ######################################################################## >>>> >>>> To unsubscribe from the MICE-DISCUSS list, click the following link: >>>> ?SUBED1=MICE-DISCUSS&A=1 >>> >>> >>> >>> -- >>> >>> Shaun Carlson >>> Network Engineering Manager | Arvig >>> ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com >>> >>> >>> 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 >>

July 26, 2014

Re: MICE MTU

by Anthony Anderberg

To be clear: the exchange doesn't support jumbo frames everywhere at the moment but it is our intention to add support. It isn't that there is demand, we just don't want the exchange to silently drop traffic should two members want to exchange traffic at a larger MTU. Anthony Anderberg Sr. Systems Analyst 320-234-5239 anthonyanderberg(a)nu-telecom.net www.nutelecom.net -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Hannigan, Martin Sent: Thursday, July 24, 2014 11:40 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE MTU If everyone really wants to, I'm happy to go along. I just can't imagine its worth the effort. I have to wonder why 99.99% of all other IXPs and peers in the world seem to think its not worth the effort either. Best, -M< On Jul 25, 2014, at 12:27 AM, Owen DeLong <owend(a)HE.NET> wrote: > I think it is desirable for the fabric to be jumbo-frame compatible. > > In general, jumbo frame support can be a good thing and we are fully jumbo-frame capable on our backbone. > > I don't know of any downside to enabling jumbo frames on the fabric. Obviously enabling them on router interfaces requires the cooperation of all peers. While I'd like to see that happen, I'm guessing it's not as easy as one might hope. > > Owen > > On Jul 24, 2014, at 21:06 , Shaun Carlson <shaun.carlson(a)ARVIG.COM> wrote: > >> The discussion at the meeting is unfortunately missed in the briefness of the minutes. >> >> The IX is configured to support jumbo frames and we felt we should keep it that way going forward. This allows maximum flexibility to support possible applications of jumbo frames. >> >> That being said, nobody is using them or has any concrete plans (that we could identify at the meeting) to use jumbo frames. If a member has a specific application or desire to use jumbo frames, it's up to that member to work with whomever their peer is to work through the technicalities and concerns of that application. >> >> s >> >> On Thursday, July 24, 2014, Hannigan, Martin <marty(a)akamai.com> wrote: >> >> >> Generally, the general IXP community has determined that the minimum exchange services configuration should be: >> >> http://www.open-ix.org/certification/ixp-technical-requirements/ >> >> If we all thought it was desired as a minimum configuration at an IXP, it would've made it in there IMHO. It didn't. If someone thinks all IXPs should do this, they should take a run at this and see if they can get the rest of the IXP community to support it (Not just Netnod and NASA). >> >> We have the same issue as Andrew, and we have zero interest to go to an MTU of 9000. >> >> >> Best, >> >> -M< >> >> >> >> >> On Jul 24, 2014, at 6:29 PM, "Koch, Andrew" <andrew.koch(a)TDSTELECOM.COM> wrote: >> >> > The UG 13 minutes make note that the exchange MTU is 9000 bytes. Are other members configuring their routers for an MTU of 9000? >> > >> > I ask as TDS has not - we have stuck with the Ethernet standard >> > 1500 bytes. If anyone on the exchange has set an MTU of 9000 and >> > tries to send jumbo traffic to us, it will not be accepted and no >> > indication will be sent back to the originator. (10d in the linked >> > document below) >> > >> > If no one (or few) has setup their routers for an MTU of 9000, but we as a community wish to enable this, I would recommend that we schedule a flag day so that we can minimize blackholing of traffic across the exchange. >> > >> > While only a draft, see >> > http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00 for >> > further information on IXP Jumbo Frame operation and conversion. >> > For those that like presentations more than IETF drafts, Martin >> > Levy (of Hurricane Electric at the time) presented this at RIPE 64 >> > - >> > https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Mart >> > in_Levy_-_IX_Jumbo_Frames_-_RIPE64_EIX-WG_-_Slovenia.pdf >> > >> > >> > Best Regards, >> > >> > Andy Koch >> > TDS Telecom - IP Network Operations andrew.koch(a)tdstelecom.com >> > Desk: 608-664-4694 >> > Cell: 608-616-0072 >> > >> > >> > >> > ######################################################################## >> > >> > To unsubscribe from the MICE-DISCUSS list, click the following link: >> > ?SUBED1=MICE-DISCUSS&A=1 >> >> >> >> -- >> >> Shaun Carlson >> Network Engineering Manager | Arvig >> ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com >> >> >> 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 >

July 25, 2014

Re: UG 13 Minutes

by Koch, Andrew

Thanks Doug! Your support of MICE by providing the mailing list is appreciated. Andy > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Doug McIntyre > Sent: Thursday, July 24, 2014 22:40 > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] UG 13 Minutes > > On Thu, Jul 24, 2014 at 05:57:46PM -0500, Doug McIntyre wrote: > > On Thu, Jul 24, 2014 at 05:34:15PM -0500, Shaun Carlson wrote: > > > Both of the public MICE lists appear to have broken archives at > lists.iphouse.net since May. Is there someone that can take a peek at > this? > > > > Sure, I'll look into the issue. > > (Nothing amiss on the system AFAIK, it'll take a deeper view to find). > > This is fixed up now. > Sorry some variables got reset on the last software updates. :-( > (but the list has a method for DMARC delivery type issues if needed). > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades

July 25, 2014

Re: MICE MTU

by Hannigan, Martin

If everyone really wants to, I'm happy to go along. I just can't imagine its worth the effort. I have to wonder why 99.99% of all other IXPs and peers in the world seem to think its not worth the effort either. Best, -M< On Jul 25, 2014, at 12:27 AM, Owen DeLong <owend(a)HE.NET> wrote: > I think it is desirable for the fabric to be jumbo-frame compatible. > > In general, jumbo frame support can be a good thing and we are fully jumbo-frame capable on our backbone. > > I don't know of any downside to enabling jumbo frames on the fabric. Obviously enabling them on router interfaces requires the cooperation of all peers. While I'd like to see that happen, I'm guessing it's not as easy as one might hope. > > Owen > > On Jul 24, 2014, at 21:06 , Shaun Carlson <shaun.carlson(a)ARVIG.COM> wrote: > >> The discussion at the meeting is unfortunately missed in the briefness of the minutes. >> >> The IX is configured to support jumbo frames and we felt we should keep it that way going forward. This allows maximum flexibility to support possible applications of jumbo frames. >> >> That being said, nobody is using them or has any concrete plans (that we could identify at the meeting) to use jumbo frames. If a member has a specific application or desire to use jumbo frames, it's up to that member to work with whomever their peer is to work through the technicalities and concerns of that application. >> >> s >> >> On Thursday, July 24, 2014, Hannigan, Martin <marty(a)akamai.com> wrote: >> >> >> Generally, the general IXP community has determined that the minimum exchange services configuration should be: >> >> http://www.open-ix.org/certification/ixp-technical-requirements/ >> >> If we all thought it was desired as a minimum configuration at an IXP, it would've made it in there IMHO. It didn't. If someone thinks all IXPs should do this, they should take a run at this and see if they can get the rest of the IXP community to support it (Not just Netnod and NASA). >> >> We have the same issue as Andrew, and we have zero interest to go to an MTU of 9000. >> >> >> Best, >> >> -M< >> >> >> >> >> On Jul 24, 2014, at 6:29 PM, "Koch, Andrew" <andrew.koch(a)TDSTELECOM.COM> wrote: >> >> > The UG 13 minutes make note that the exchange MTU is 9000 bytes. Are other members configuring their routers for an MTU of 9000? >> > >> > I ask as TDS has not - we have stuck with the Ethernet standard 1500 bytes. If anyone on the exchange has set an MTU of 9000 and tries to send jumbo traffic to us, it will not be accepted and no indication will be sent back to the originator. (10d in the linked document below) >> > >> > If no one (or few) has setup their routers for an MTU of 9000, but we as a community wish to enable this, I would recommend that we schedule a flag day so that we can minimize blackholing of traffic across the exchange. >> > >> > While only a draft, see http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00 for further information on IXP Jumbo Frame operation and conversion. For those that like presentations more than IETF drafts, Martin Levy (of Hurricane Electric at the time) presented this at RIPE 64 - https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Martin_Levy_… >> > >> > >> > Best Regards, >> > >> > Andy Koch >> > TDS Telecom - IP Network Operations >> > andrew.koch(a)tdstelecom.com >> > Desk: 608-664-4694 >> > Cell: 608-616-0072 >> > >> > >> > >> > ######################################################################## >> > >> > To unsubscribe from the MICE-DISCUSS list, click the following link: >> > ?SUBED1=MICE-DISCUSS&A=1 >> >> >> >> -- >> >> Shaun Carlson >> Network Engineering Manager | Arvig >> ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com >> >> >> 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 >

July 25, 2014

Re: MICE MTU

by Owen DeLong

I think it is desirable for the fabric to be jumbo-frame compatible. In general, jumbo frame support can be a good thing and we are fully jumbo-frame capable on our backbone. I don't know of any downside to enabling jumbo frames on the fabric. Obviously enabling them on router interfaces requires the cooperation of all peers. While I'd like to see that happen, I'm guessing it's not as easy as one might hope. Owen On Jul 24, 2014, at 21:06 , Shaun Carlson <shaun.carlson(a)ARVIG.COM> wrote: > The discussion at the meeting is unfortunately missed in the briefness of the minutes. > > The IX is configured to support jumbo frames and we felt we should keep it that way going forward. This allows maximum flexibility to support possible applications of jumbo frames. > > That being said, nobody is using them or has any concrete plans (that we could identify at the meeting) to use jumbo frames. If a member has a specific application or desire to use jumbo frames, it's up to that member to work with whomever their peer is to work through the technicalities and concerns of that application. > > s > > On Thursday, July 24, 2014, Hannigan, Martin <marty(a)akamai.com> wrote: > > > Generally, the general IXP community has determined that the minimum exchange services configuration should be: > > http://www.open-ix.org/certification/ixp-technical-requirements/ > > If we all thought it was desired as a minimum configuration at an IXP, it would've made it in there IMHO. It didn't. If someone thinks all IXPs should do this, they should take a run at this and see if they can get the rest of the IXP community to support it (Not just Netnod and NASA). > > We have the same issue as Andrew, and we have zero interest to go to an MTU of 9000. > > > Best, > > -M< > > > > > On Jul 24, 2014, at 6:29 PM, "Koch, Andrew" <andrew.koch(a)TDSTELECOM.COM> wrote: > > > The UG 13 minutes make note that the exchange MTU is 9000 bytes. Are other members configuring their routers for an MTU of 9000? > > > > I ask as TDS has not - we have stuck with the Ethernet standard 1500 bytes. If anyone on the exchange has set an MTU of 9000 and tries to send jumbo traffic to us, it will not be accepted and no indication will be sent back to the originator. (10d in the linked document below) > > > > If no one (or few) has setup their routers for an MTU of 9000, but we as a community wish to enable this, I would recommend that we schedule a flag day so that we can minimize blackholing of traffic across the exchange. > > > > While only a draft, see http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00 for further information on IXP Jumbo Frame operation and conversion. For those that like presentations more than IETF drafts, Martin Levy (of Hurricane Electric at the time) presented this at RIPE 64 - https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Martin_Levy_… > > > > > > Best Regards, > > > > Andy Koch > > TDS Telecom - IP Network Operations > > andrew.koch(a)tdstelecom.com > > Desk: 608-664-4694 > > Cell: 608-616-0072 > > > > > > > > ######################################################################## > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > > ?SUBED1=MICE-DISCUSS&A=1 > > > > -- > > Shaun Carlson > Network Engineering Manager | Arvig > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

July 25, 2014

Re: MICE MTU

by Shaun Carlson

The discussion at the meeting is unfortunately missed in the briefness of the minutes. The IX is configured to support jumbo frames and we felt we should keep it that way going forward. This allows maximum flexibility to support possible applications of jumbo frames. That being said, nobody is using them or has any concrete plans (that we could identify at the meeting) to use jumbo frames. If a member has a specific application or desire to use jumbo frames, it's up to that member to work with whomever their peer is to work through the technicalities and concerns of that application. s On Thursday, July 24, 2014, Hannigan, Martin <marty(a)akamai.com> wrote: > > > Generally, the general IXP community has determined that the minimum > exchange services configuration should be: > > http://www.open-ix.org/certification/ixp-technical-requirements/ > > If we all thought it was desired as a minimum configuration at an IXP, it > would've made it in there IMHO. It didn't. If someone thinks all IXPs > should do this, they should take a run at this and see if they can get the > rest of the IXP community to support it (Not just Netnod and NASA). > > We have the same issue as Andrew, and we have zero interest to go to an > MTU of 9000. > > > Best, > > -M< > > > > > On Jul 24, 2014, at 6:29 PM, "Koch, Andrew" <andrew.koch(a)TDSTELECOM.COM > <javascript:;>> wrote: > > > The UG 13 minutes make note that the exchange MTU is 9000 bytes. Are > other members configuring their routers for an MTU of 9000? > > > > I ask as TDS has not - we have stuck with the Ethernet standard 1500 > bytes. If anyone on the exchange has set an MTU of 9000 and tries to send > jumbo traffic to us, it will not be accepted and no indication will be sent > back to the originator. (10d in the linked document below) > > > > If no one (or few) has setup their routers for an MTU of 9000, but we as > a community wish to enable this, I would recommend that we schedule a flag > day so that we can minimize blackholing of traffic across the exchange. > > > > While only a draft, see > http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00 for further > information on IXP Jumbo Frame operation and conversion. For those that > like presentations more than IETF drafts, Martin Levy (of Hurricane > Electric at the time) presented this at RIPE 64 - > https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Martin_Levy_… > > > > > > Best Regards, > > > > Andy Koch > > TDS Telecom - IP Network Operations > > andrew.koch(a)tdstelecom.com <javascript:;> > > Desk: 608-664-4694 > > Cell: 608-616-0072 > > > > > > > > ######################################################################## > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > > ?SUBED1=MICE-DISCUSS&A=1 > > -- *Shaun Carlson*Network Engineering Manager | Arvig ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com

July 25, 2014

Re: MICE MTU

by Doug McIntyre

On Thu, Jul 24, 2014 at 10:29:38PM +0000, Koch, Andrew wrote: > The UG 13 minutes make note that the exchange MTU is 9000 bytes. Are other members configuring their routers for an MTU of 9000? I don't know if this number came from anybody technical, or somebody just stuck it in there as a desire to move to? The Juniper switch stack is NOT configured for an MTU of 9000. Nor is the Mankato extension. dmcintyre@MICE-SW1> show int | match MTU Link-level type: Ethernet, MTU: 1514, Speed: 10Gbps, Duplex: Full-Duplex, ... every other interface matching MTU ... In Juniper speak, MTU of 1514 == 1500 of Cisco (and just about everybody else). So, if anybody has thought of doing Jumbo frames, it isn't supported at the core Juniper switch stack without updating the config. The CMS switch may be different. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

July 25, 2014

Re: UG 13 Minutes

by Doug McIntyre

On Thu, Jul 24, 2014 at 05:57:46PM -0500, Doug McIntyre wrote: > On Thu, Jul 24, 2014 at 05:34:15PM -0500, Shaun Carlson wrote: > > Both of the public MICE lists appear to have broken archives at lists.iphouse.net since May. Is there someone that can take a peek at this? > > Sure, I'll look into the issue. > (Nothing amiss on the system AFAIK, it'll take a deeper view to find). This is fixed up now. Sorry some variables got reset on the last software updates. :-( (but the list has a method for DMARC delivery type issues if needed). -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

July 25, 2014

Re: UG 13 Minutes

by Hannigan, Martin

Thanks Shaun! Best, -M< On Jul 24, 2014, at 6:35 PM, Shaun Carlson <shaun.carlson(a)ARVIG.COM> wrote: > Marty, > > To date, our policy has been to not fund the transit requirements and our plan is to maintain that position. We did not vote one way or another as we did not meet quorum requirements. > > s > > Shaun Carlson > Network Engineering Manager | Arvig > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > On July 24, 2014 at 16:31:09 CDT, Hannigan, Martin <marty(a)akamai.com> wrote: >> >> >> Its not entirely clear from the minutes; did the members vote for or against funding googles transit requirement? >> >> Best, >> >> -M< >> >> >> >> On Jul 24, 2014, at 5:23 PM, Shaun Carlson wrote: >> >> > Please see attached, send me any corrections or updates. >> > >> > As an important note: >> > >> > The next meeting will be on Wednesday, October 22nd from 4pm to 7pm at the 511 Building; please mark your calendars now and plan on being there! >> > >> > Thanks and see you all in October! >> > >> > s >> > >> > Shaun Carlson >> > Network Engineering Manager | Arvig >> > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com >> > >> > To unsubscribe from the MICE-DISCUSS list, click the following link: >> > ?SUBED1=MICE-DISCUSS&A=1 >> > >> > >> >> >> ######################################################################## >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> ?SUBED1=MICE-DISCUSS&A=1 > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 >

July 25, 2014

Open-IX OIX-1 Was: Re: [MICE-DISCUSS] MICE MTU

by Hannigan, Martin

Btw, I would like to see PVLAN implemented if possible. It's not just for big IXPs, its for all. And MICE is getting big regardless. The compliance pieces fit well here IMHO. OIX-1 is an open standard; IXP's can choose to either be compliant or be certified. Ether way, it's open and recommended. Best, -M< On Jul 24, 2014, at 10:12 PM, "Hannigan, Martin" <marty(a)AKAMAI.COM> wrote: > > > Generally, the general IXP community has determined that the minimum exchange services configuration should be: > > http://www.open-ix.org/certification/ixp-technical-requirements/ > > If we all thought it was desired as a minimum configuration at an IXP, it would've made it in there IMHO. It didn't. If someone thinks all IXPs should do this, they should take a run at this and see if they can get the rest of the IXP community to support it (Not just Netnod and NASA). > > We have the same issue as Andrew, and we have zero interest to go to an MTU of 9000. > > > Best, > > -M< > > > > > On Jul 24, 2014, at 6:29 PM, "Koch, Andrew" <andrew.koch(a)TDSTELECOM.COM> wrote: > >> The UG 13 minutes make note that the exchange MTU is 9000 bytes. Are other members configuring their routers for an MTU of 9000? >> >> I ask as TDS has not - we have stuck with the Ethernet standard 1500 bytes. If anyone on the exchange has set an MTU of 9000 and tries to send jumbo traffic to us, it will not be accepted and no indication will be sent back to the originator. (10d in the linked document below) >> >> If no one (or few) has setup their routers for an MTU of 9000, but we as a community wish to enable this, I would recommend that we schedule a flag day so that we can minimize blackholing of traffic across the exchange. >> >> While only a draft, see http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00 for further information on IXP Jumbo Frame operation and conversion. For those that like presentations more than IETF drafts, Martin Levy (of Hurricane Electric at the time) presented this at RIPE 64 - https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Martin_Levy_… >> >> >> Best Regards, >> >> Andy Koch >> TDS Telecom - IP Network Operations >> andrew.koch(a)tdstelecom.com >> Desk: 608-664-4694 >> Cell: 608-616-0072 >> >> >> >> ######################################################################## >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> ?SUBED1=MICE-DISCUSS&A=1 >

July 25, 2014

Re: MICE MTU

by Hannigan, Martin

Generally, the general IXP community has determined that the minimum exchange services configuration should be: http://www.open-ix.org/certification/ixp-technical-requirements/ If we all thought it was desired as a minimum configuration at an IXP, it would've made it in there IMHO. It didn't. If someone thinks all IXPs should do this, they should take a run at this and see if they can get the rest of the IXP community to support it (Not just Netnod and NASA). We have the same issue as Andrew, and we have zero interest to go to an MTU of 9000. Best, -M< On Jul 24, 2014, at 6:29 PM, "Koch, Andrew" <andrew.koch(a)TDSTELECOM.COM> wrote: > The UG 13 minutes make note that the exchange MTU is 9000 bytes. Are other members configuring their routers for an MTU of 9000? > > I ask as TDS has not - we have stuck with the Ethernet standard 1500 bytes. If anyone on the exchange has set an MTU of 9000 and tries to send jumbo traffic to us, it will not be accepted and no indication will be sent back to the originator. (10d in the linked document below) > > If no one (or few) has setup their routers for an MTU of 9000, but we as a community wish to enable this, I would recommend that we schedule a flag day so that we can minimize blackholing of traffic across the exchange. > > While only a draft, see http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00 for further information on IXP Jumbo Frame operation and conversion. For those that like presentations more than IETF drafts, Martin Levy (of Hurricane Electric at the time) presented this at RIPE 64 - https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Martin_Levy_… > > > Best Regards, > > Andy Koch > TDS Telecom - IP Network Operations > andrew.koch(a)tdstelecom.com > Desk: 608-664-4694 > Cell: 608-616-0072 > > > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1

July 25, 2014

Re: UG 13 Minutes

by Doug McIntyre

On Thu, Jul 24, 2014 at 05:34:15PM -0500, Shaun Carlson wrote: > Both of the public MICE lists appear to have broken archives at lists.iphouse.net since May. Is there someone that can take a peek at this? Sure, I'll look into the issue. (Nothing amiss on the system AFAIK, it'll take a deeper view to find). > A final item on the mailing lists - there is a footer appended to every message sent. The footer indicates that unsubscribe is available by clicking on a link, but there is not a functional URL. This footer also breaks any PGP signed messages as it modifies the message part. If possible, can this be removed or fixed and relocated to the message headers? I think it was supposed to generate HTML on an HTML style feed, but this is a text style feed. I've removed it rather than to reword it for text-processing. -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

July 24, 2014

Re: UG 13 Minutes

by Shaun Carlson

Marty, To date, our policy has been to not fund the transit requirements and our plan is to maintain that position. We did not vote one way or another as we did not meet quorum requirements. s Shaun CarlsonNetwork Engineering Manager | Arvigph: (218) 346-8673 | em: shaun.carlson(a)arvig.com Its not entirely clear from the minutes; did the members vote for or against funding googles transit requirement? Best, -M< On Jul 24, 2014, at 5:23 PM, Shaun Carlson <shaun.carlson(a)ARVIG.COM> wrote: > Please see attached, send me any corrections or updates. > > As an important note: > > The next meeting will be on Wednesday, October 22nd from 4pm to 7pm at the 511 Building; please mark your calendars now and plan on being there! > > Thanks and see you all in October! > > s > > Shaun Carlson > Network Engineering Manager | Arvig > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > > <MICE UG 13 - Minutes.pdf> ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Re: UG 13 Minutes

by Shaun Carlson

Thanks Andy, those issues are what prompted this discussion. I'll see that we get them addressed. s Shaun CarlsonNetwork Engineering Manager | Arvigph: (218) 346-8673 | em: shaun.carlson(a)arvig.com A comment in regards to the mailing lists and meeting notices: I believe that we want to have as many participants as possible. As such, meeting notices, agendas and minutes should always be sent to MICE-ANNOUNCE, which may have folks that don't want the increased volume that -DISCUSS has, but still wish to be participants. None of the meeting emails for this UG appear to have been sent to -ANNOUNCE (at least none were received at the address I had subscribed with). Both of the public MICE lists appear to have broken archives at lists.iphouse.net since May. Is there someone that can take a peek at this? A final item on the mailing lists - there is a footer appended to every message sent. The footer indicates that unsubscribe is available by clicking on a link, but there is not a functional URL. This footer also breaks any PGP signed messages as it modifies the message part. If possible, can this be removed or fixed and relocated to the message headers? Thanks, Andy Koch TDS Telecom - IP Network Operations andrew.koch(a)tdstelecom.com Desk: 608-664-4694 Cell: 608-616-0072 > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Shaun Carlson > Sent: Thursday, July 24, 2014 16:24 > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] UG 13 Minutes > > Please see attached, send me any corrections or updates. > > As an important note: > > The next meeting will be on Wednesday, October 22nd from 4pm to 7pm at the > 511 Building; please mark your calendars now and plan on being there! > > Thanks and see you all in October! > > s > > Shaun Carlson > Network Engineering Manager | Arvig > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > > ________________________________ > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

MICE MTU

by Koch, Andrew

The UG 13 minutes make note that the exchange MTU is 9000 bytes. Are other members configuring their routers for an MTU of 9000? I ask as TDS has not - we have stuck with the Ethernet standard 1500 bytes. If anyone on the exchange has set an MTU of 9000 and tries to send jumbo traffic to us, it will not be accepted and no indication will be sent back to the originator. (10d in the linked document below) If no one (or few) has setup their routers for an MTU of 9000, but we as a community wish to enable this, I would recommend that we schedule a flag day so that we can minimize blackholing of traffic across the exchange. While only a draft, see http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00 for further information on IXP Jumbo Frame operation and conversion. For those that like presentations more than IETF drafts, Martin Levy (of Hurricane Electric at the time) presented this at RIPE 64 - https://ripe64.ripe.net/presentations/139-Hurricane_Electric_-_Martin_Levy_… Best Regards, Andy Koch TDS Telecom - IP Network Operations andrew.koch(a)tdstelecom.com Desk: 608-664-4694 Cell: 608-616-0072 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Re: UG 13 Minutes

by Reid Fishler

The exchange does not provide transit for anyone. If any exchange member decides to provide service that is of the own volition, but the exchange doesn't provide anything more than exchange services. Reid On Jul 24, 2014 4:31 PM, "Hannigan, Martin" <marty(a)akamai.com> wrote: > > > Its not entirely clear from the minutes; did the members vote for or > against funding googles transit requirement? > > Best, > > -M< > > > > On Jul 24, 2014, at 5:23 PM, Shaun Carlson <shaun.carlson(a)ARVIG.COM> > wrote: > > > Please see attached, send me any corrections or updates. > > > > As an important note: > > > > The next meeting will be on Wednesday, October 22nd from 4pm to 7pm at > the 511 Building; please mark your calendars now and plan on being there! > > > > Thanks and see you all in October! > > > > s > > > > Shaun Carlson > > Network Engineering Manager | Arvig > > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > > ?SUBED1=MICE-DISCUSS&A=1 > > > > <MICE UG 13 - Minutes.pdf> > > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Re: UG 13 Minutes

by Koch, Andrew

A comment in regards to the mailing lists and meeting notices: I believe that we want to have as many participants as possible. As such, meeting notices, agendas and minutes should always be sent to MICE-ANNOUNCE, which may have folks that don't want the increased volume that -DISCUSS has, but still wish to be participants. None of the meeting emails for this UG appear to have been sent to -ANNOUNCE (at least none were received at the address I had subscribed with). Both of the public MICE lists appear to have broken archives at lists.iphouse.net since May. Is there someone that can take a peek at this? A final item on the mailing lists - there is a footer appended to every message sent. The footer indicates that unsubscribe is available by clicking on a link, but there is not a functional URL. This footer also breaks any PGP signed messages as it modifies the message part. If possible, can this be removed or fixed and relocated to the message headers? Thanks, Andy Koch TDS Telecom - IP Network Operations andrew.koch(a)tdstelecom.com Desk: 608-664-4694 Cell: 608-616-0072 > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Shaun Carlson > Sent: Thursday, July 24, 2014 16:24 > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] UG 13 Minutes > > Please see attached, send me any corrections or updates. > > As an important note: > > The next meeting will be on Wednesday, October 22nd from 4pm to 7pm at the > 511 Building; please mark your calendars now and plan on being there! > > Thanks and see you all in October! > > s > > Shaun Carlson > Network Engineering Manager | Arvig > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > > ________________________________ > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Re: UG 13 Minutes

by Hannigan, Martin

Its not entirely clear from the minutes; did the members vote for or against funding googles transit requirement? Best, -M< On Jul 24, 2014, at 5:23 PM, Shaun Carlson <shaun.carlson(a)ARVIG.COM> wrote: > Please see attached, send me any corrections or updates. > > As an important note: > > The next meeting will be on Wednesday, October 22nd from 4pm to 7pm at the 511 Building; please mark your calendars now and plan on being there! > > Thanks and see you all in October! > > s > > Shaun Carlson > Network Engineering Manager | Arvig > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > > <MICE UG 13 - Minutes.pdf> ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

UG 13 Minutes

by Shaun Carlson

Please see attached, send me any corrections or updates. As an important note: *The next meeting will be on Wednesday, October 22nd from 4pm to 7pm at the 511 Building; please mark your calendars now and plan on being there!* Thanks and see you all in October! s *Shaun Carlson*Network Engineering Manager | Arvig ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Re: MICE Meeting Google Hangout

by Hannigan, Martin

hannigan(a)gmail.com On Jul 24, 2014, at 4:30 PM, Brady Kittel <bkittel(a)GMAIL.COM> wrote: > Can you invite bkittel(a)gmail.com too? > > On Jul 24, 2014 2:51 PM, "David Farmer" <farmer(a)umn.edu> wrote: > Please send me your email so I can invite you to the google hangout. > > -- > =============================================== > 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 > =============================================== > > > On Jul 24, 2014, at 14:24, Russell Berg <berg(a)wins.net> wrote: > >> Tried joining but it says the party is over. 8-( >> >> >> >> From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer >> Sent: Thursday, July 24, 2014 2:12 PM >> To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >> Subject: [MICE-DISCUSS] MICE Meeting Google Hangout >> >> >> >> we will get started shortly >> >> >> >> https://plus.google.com/hangouts/_/gvdyimpkvxef2lb3ua75qf4dnea >> >> >> >> -- >> =============================================== >> 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 >> =============================================== >> >> >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> ?SUBED1=MICE-DISCUSS&A=1 >> > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Re: MICE Meeting Google Hangout

by Levi Pederson

levipederson(a)mankatonetworks.net *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipederson(a)mankatonetworks.net On Thu, Jul 24, 2014 at 2:51 PM, David Farmer <farmer(a)umn.edu> wrote: > Please send me your email so I can invite you to the google hangout. > > -- > =============================================== > 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 > =============================================== > > > On Jul 24, 2014, at 14:24, Russell Berg <berg(a)wins.net> wrote: > > Tried joining but it says the party is over. 8-( > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET > <MICE-DISCUSS(a)LISTS.IPHOUSE.NET>] *On Behalf Of *David Farmer > *Sent:* Thursday, July 24, 2014 2:12 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* [MICE-DISCUSS] MICE Meeting Google Hangout > > > > we will get started shortly > > > > https://plus.google.com/hangouts/_/gvdyimpkvxef2lb3ua75qf4dnea > > > > -- > =============================================== > 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 > =============================================== > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Re: MICE Meeting Google Hangout

by Brady Kittel

Can you invite bkittel(a)gmail.com too? On Jul 24, 2014 2:51 PM, "David Farmer" <farmer(a)umn.edu> wrote: > Please send me your email so I can invite you to the google hangout. > > -- > =============================================== > 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 > =============================================== > > > On Jul 24, 2014, at 14:24, Russell Berg <berg(a)wins.net> wrote: > > Tried joining but it says the party is over. 8-( > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET > <MICE-DISCUSS(a)LISTS.IPHOUSE.NET>] *On Behalf Of *David Farmer > *Sent:* Thursday, July 24, 2014 2:12 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* [MICE-DISCUSS] MICE Meeting Google Hangout > > > > we will get started shortly > > > > https://plus.google.com/hangouts/_/gvdyimpkvxef2lb3ua75qf4dnea > > > > -- > =============================================== > 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 > =============================================== > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Re: MICE Meeting Google Hangout

by Russell Berg

Sounding and looking good, but can the camera be easily tipped downward a bit… seeing foreheads and hairlines. Thanks! From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Thursday, July 24, 2014 2:51 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Meeting Google Hangout Please send me your email so I can invite you to the google hangout. -- =============================================== David Farmer Email:farmer@umn.edu<http://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 =============================================== On Jul 24, 2014, at 14:24, Russell Berg <berg(a)wins.net<mailto:berg@wins.net>> wrote: Tried joining but it says the party is over. 8-( From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer Sent: Thursday, July 24, 2014 2:12 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] MICE Meeting Google Hangout we will get started shortly https://plus.google.com/hangouts/_/gvdyimpkvxef2lb3ua75qf4dnea -- =============================================== 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: ?SUBED1=MICE-DISCUSS&A=1 ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Re: MICE Meeting Google Hangout

by David Farmer

Please send me your email so I can invite you to the google hangout. -- =============================================== 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 =============================================== > On Jul 24, 2014, at 14:24, Russell Berg <berg(a)wins.net> wrote: > > Tried joining but it says the party is over. 8-( > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of David Farmer > Sent: Thursday, July 24, 2014 2:12 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] MICE Meeting Google Hangout > > we will get started shortly > > https://plus.google.com/hangouts/_/gvdyimpkvxef2lb3ua75qf4dnea > > -- > =============================================== > 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 > =============================================== > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

MICE Meeting Google Hangout

by David Farmer

we will get started shortly https://plus.google.com/hangouts/_/gvdyimpkvxef2lb3ua75qf4dnea -- =============================================== 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 =============================================== ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 24, 2014

Meeting Reminder and Agenda

by Shaun Carlson

All, Just a quick, last reminder of our meeting tomorrow *Date*: Thursday, July 24th *Time*: 2:00 pm (1400 Hours) David Farmer has the facility reserved until 5PM *Location*: University of Minnesota, Duluth campus, Griggs Center, located in the Kirby Student Center (KSC) http://www.d.umn.edu/maps/KSC/ We have discussed a web attendance option. I don't have that information handy right now and I'll send it as soon as I get confirmation. Attached is the current agenda, if you have any other items you would like added to the agenda, please drop me a note prior to the meeting and I'll get them on there! Thanks and see you tomorrow! s *Shaun Carlson*Network Engineering Manager | Arvig ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 23, 2014

Re: Agenda Items - Last Call

by Doug McIntyre

On Tue, Jul 22, 2014 at 03:10:21PM -0500, Richard Laager wrote: > I'm not attending*, but maybe others should discuss the IPv6 numbering > plan? Specifically: should we be putting the ASN bytes at the end of the > IPv6 address for multicast group reasons? I'm sorry, but I'm trying to understand the "problem". (I'm not the one who originally suggested the layout, but did initially redeploy the IPv6 addressing from the borrowed addressing. First off, we are talking about a total of 26 IPv6 end-points. Maybe if MICE grows a lot, we'll double that? Up to 52 end-points? >From what I've read on it, the purpose of the multicast group mainly is to break up the ND announcements into separate smaller groups, since ARP broadcasts on truely huge networks can get to be quite large and problematic when you have 10,000 hosts responding. As far as I can tell, the purpose of the multicast group grouping the lowest 24bits is not to put each endpoint into its own multicast group, but only to break it up into smaller and more manageable traffic bursts in order to avoid the multi-megabit ARP storms that can happen on truely huge networks. Either way, we are talking about a potential of 26 hosts reponding to ND requests. The only problem I see is that somebody following a CoPP guide that put the ND policing limit at too low of a limit is saying that he is getting more ND traffic than his CoPP guide suggests. Am I totally confused about this? -- 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: ?SUBED1=MICE-DISCUSS&A=1

July 22, 2014

Re: Agenda Items - Last Call

by Reid Fishler

I think there is a web based option...Also, you wont be there?! What is a MICE meeting without you? :-P Reid On Tue, Jul 22, 2014 at 4:10 PM, Richard Laager <rlaager(a)wiktel.com> wrote: > On Tue, 2014-07-22 at 08:43 -0500, Shaun Carlson wrote: > > > Please send any additional agenda (business, technical or discussion) > > items you may have. I plan to have the Agenda out this afternoon for > > Thursday's meeting. > > I'm not attending*, but maybe others should discuss the IPv6 numbering > plan? Specifically: should we be putting the ASN bytes at the end of the > IPv6 address for multicast group reasons? > > * At least not in person. Was there going to be any sort of remote > option? > > -- > Richard > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > > -- Reid Fishler Director Hurricane Electric +1-510-580-4178 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 22, 2014

Re: Agenda Items - Last Call

by Richard Laager

On Tue, 2014-07-22 at 08:43 -0500, Shaun Carlson wrote: > Please send any additional agenda (business, technical or discussion) > items you may have. I plan to have the Agenda out this afternoon for > Thursday's meeting. I'm not attending*, but maybe others should discuss the IPv6 numbering plan? Specifically: should we be putting the ASN bytes at the end of the IPv6 address for multicast group reasons? * At least not in person. Was there going to be any sort of remote option? -- Richard ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 22, 2014

Re: Agenda Items - Last Call

by Justin Krejci

AS10242 - zero attending Agenda item I recommend - application of the variously discussed MICE switch security policy configurations for storm controls, mac learning limits, L2 bpdu handling, etc. ________________________________ From: MICE Discuss [MICE-DISCUSS(a)LISTS.IPHOUSE.NET] on behalf of Shaun Carlson [shaun.carlson(a)ARVIG.COM] Sent: Tuesday, July 22, 2014 8:43 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] Agenda Items - Last Call All, Please send any additional agenda (business, technical or discussion) items you may have. I plan to have the Agenda out this afternoon for Thursday's meeting. Also, one more quick reminder. If you haven't responded yet, please let me know your AS and number of people attending. Thanks! s Shaun Carlson Network Engineering Manager | Arvig ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com<mailto:shaun.carlson@arvig.com> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1<UrlBlockedError.aspx> ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 22, 2014

Agenda Items - Last Call

by Shaun Carlson

All, Please send any additional agenda (business, technical or discussion) items you may have. I plan to have the Agenda out this afternoon for Thursday's meeting. Also, one more quick reminder. If you haven't responded yet, please let me know your AS and number of people attending. Thanks! s *Shaun Carlson*Network Engineering Manager | Arvig ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 22, 2014

Re: IPv6 neighbor solicitation at the exchange

by James Stahr

On 07/18/2014 2:06 PM, Rob Mosher wrote: > You shouldn't be grouping neighbor discovery in the same rate limits > as other type of icmpv6. If someone starts pinging your router at a > high rate Echo/echo-reply isn't handled in this section. > or if there is a routing loop that generates a bunch of time exceeded > messages it will cause your neighbor discovery to fail and will be > unable to reach your peers. Those are just two examples, but you > really need neighbor discovery to be handled elsewhere. > Time exceeded's will only go back to the router originating the traffic so if there's a routing loop, the messages go back to the individual sources. It's unlikely that my router is going to generate a lot of traffic to cause ND to fail. And hopefully the upstream routers with the loop also has a policy to limit their time exceeded messages... Given the neighbor solicitations I'm seeing, I do think that this points out a 'flaw' in the exchange's IPv6 address assignments. It seems like we should be using hextet's 7 for16bit ASNs and hextets 6 and 7 for 32bit ASNs - I'm not sure if there is a policy for 32bit ASN IPv6 addressing as no one appears to have one yet. If anyone is interested, I used this as my basis for my IPv6 policy and I appear to have used smaller values policing values than what had been suggested: http://archiv.cesnet.cz/doc/techzpravy/2010/ipv6-copp/ipv6-copp.pdf > -- > Rob Mosher > Senior Network and Software Engineer > Hurricane Electric / AS6939 > > On 7/17/2014 5:07 PM, James Stahr wrote: >> First off, Did anyone make any changes on 07/15/2014 around 08:00? >> >> The reason is that I think I've resolved an issue with our IPv6 >> peering with the MICE route servers, Charter, and TDS and I'm looking >> for a larger audience to see if it's my issue or perhaps an issue at >> the exchange. I believe it to be the latter, but I'm not an IPv6 >> expert. >> >> Starting two days ago around 8am CDT, we started experiencing BGP >> timeouts on some of our IPv6 BGP sessions. I was able to work around >> the issue by removing our COPP policy and the BGP sessions were >> stable for 24 hours. Reapplied the policy, sessions started to drop >> again. Looked at the policy to see which category is being exceeded, >> it's not the routing section which allows BGP/BFD/etc, but the >> ICMP-v6 one: >> >> >> ipv6 access-list COPP-icmp-v6 >> remark ICMP type 1/3,2,3/0,3/1,4/0,4/1,4/2,130,143 >> permit icmp any any destination-unreachable >> permit icmp any any packet-too-big >> permit icmp any any time-exceeded >> permit icmp any any parameter-problem >> remark nd-na, nd-ns, ra, rs >> permit icmp any any nd-na >> permit icmp any any nd-ns >> permit icmp any any router-advertisement >> permit icmp any any router-solicitation >> remark MLD - query, report_v2 >> permit icmp any any mld-query >> permit icmp any any 143 >> >> >> which is being policed like this: >> >> class Icmp-v6 >> police 32000 60000 120000 conform-action transmit exceed-action drop >> >> I've worked around the issue by making a 4x increase in the policing, >> but the question I have is what happened at the exchange to provoke >> my COPP policy? Alternatively, is this normal or indicate who has >> the problem: >> >> >> >> r-pop-min-1#deb ipv6 icmp >> ICMP Packet debugging is on >> r-pop-min-1# >> Jul 17 14:36:08.143 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::56E0:3200:50CE:4178, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.285 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.359 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.433 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.435 CDT: ICMPv6: Sent N-Solicit, >> Src=FE80::CA4C:75FF:FE23:805, Dst=2001:504:27::8252:0:1 >> Jul 17 14:36:08.459 CDT: ICMPv6: Received N-Advert, >> Src=2001:504:27::8252:0:1, Dst=FE80::CA4C:75FF:FE23:805 >> Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.539 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.559 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.586 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.617 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.687 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.782 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> r-pop-min-1# >> Jul 17 14:36:08.842 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.990 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.028 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.070 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.148 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.203 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.327 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.399 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.439 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.481 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.533 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.581 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.608 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::2E21:72FF:FE71:37B1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.613 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 >> r-pop-min-1# >> Jul 17 14:36:09.659 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.884 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.069 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.172 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.240 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.320 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.364 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.441 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.521 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.588 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.622 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.659 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.684 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.817 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.853 CDT: ICMPv6: Received type 130, >> Src=FE80::21B:DFF:FEE7:15C0, Dst=FF02::1 >> r-pop-min-1# >> Jul 17 14:36:10.908 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.925 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> >> I'm thinking that the answer is that this is not normal, as it looks >> like I'm getting duplicate solicitations in the same second. >> >> -James >> >> ######################################################################## >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> ?SUBED1=MICE-DISCUSS&A=1 > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > > ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 21, 2014

Re: MICE UG 13 - Duluth July 24th Note 2PM start

by Mike Wilker

15011, none this time. Thank You, Mike Wilker CTO ( Office: (507) 214-0259 - Email: mwilker(a)jagcom.net www.JagCom.net <http://www.jagcom.net/> 213 South Oak Avenue Owatonna, MN 55060 On Fri, Jul 18, 2014 at 8:12 AM, Shaun Carlson <shaun.carlson(a)arvig.com> wrote: > All, > > In order to get a good head count for planning, can you respond with your > ASN and how many people will be attending the Duluth meeting? > > Thanks! > > s > > > > *Shaun Carlson *Network Engineering Manager | Arvig > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > > > On Tue, Jul 8, 2014 at 1:01 PM, Mike Hemphill <mike.hemphill(a)cologix.com> > wrote: > >> Good Afternoon All! >> >> >> >> MICE UG 13 has been scheduled, as follows: >> >> >> >> Date: Thursday, July 24th >> >> Time: 2:00 pm (1400 Hours) David Farmer has the facility reserved until >> 5PM >> >> Location: University of Minnesota, Duluth campus, Griggs Center, located >> in the *Kirby Student Center (KSC) * http://www.d.umn.edu/maps/KSC/ >> >> >> >> Please send your agenda items when you have a chance! >> >> >> >> Also please invite business & other entities that may have an interest in >> connecting to MICE. >> >> Our goal is to extend the reach of MICE connectivity to outstate >> institutions & companies. >> >> >> >> Thanks! >> >> Reid, Shaun & Mike >> >> >> >> *Mike Hemphill* >> *General Manager | **Cologix, Inc. <http://www.cologix.com/>* >> >> >> *511 11th Ave S, Suite 450 | Minneapolis, MN 55415P: 1+612.333.1922 | M: >> 1+612.812.5242 mike.hemphill(a)cologix.com <mike.hemphill(a)cologix.com>* >> >> >> >> ------------------------------ >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> ?SUBED1=MICE-DISCUSS&A=1 >> > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 21, 2014

Re: IPv6 neighbor solicitation at the exchange

by Rob Mosher

You shouldn't be grouping neighbor discovery in the same rate limits as other type of icmpv6. If someone starts pinging your router at a high rate or if there is a routing loop that generates a bunch of time exceeded messages it will cause your neighbor discovery to fail and will be unable to reach your peers. Those are just two examples, but you really need neighbor discovery to be handled elsewhere. -- Rob Mosher Senior Network and Software Engineer Hurricane Electric / AS6939 On 7/17/2014 5:07 PM, James Stahr wrote: > First off, Did anyone make any changes on 07/15/2014 around 08:00? > > The reason is that I think I've resolved an issue with our IPv6 > peering with the MICE route servers, Charter, and TDS and I'm looking > for a larger audience to see if it's my issue or perhaps an issue at > the exchange. I believe it to be the latter, but I'm not an IPv6 expert. > > Starting two days ago around 8am CDT, we started experiencing BGP > timeouts on some of our IPv6 BGP sessions. I was able to work around > the issue by removing our COPP policy and the BGP sessions were stable > for 24 hours. Reapplied the policy, sessions started to drop again. > Looked at the policy to see which category is being exceeded, it's not > the routing section which allows BGP/BFD/etc, but the ICMP-v6 one: > > > ipv6 access-list COPP-icmp-v6 > remark ICMP type 1/3,2,3/0,3/1,4/0,4/1,4/2,130,143 > permit icmp any any destination-unreachable > permit icmp any any packet-too-big > permit icmp any any time-exceeded > permit icmp any any parameter-problem > remark nd-na, nd-ns, ra, rs > permit icmp any any nd-na > permit icmp any any nd-ns > permit icmp any any router-advertisement > permit icmp any any router-solicitation > remark MLD - query, report_v2 > permit icmp any any mld-query > permit icmp any any 143 > > > which is being policed like this: > > class Icmp-v6 > police 32000 60000 120000 conform-action transmit exceed-action drop > > I've worked around the issue by making a 4x increase in the policing, > but the question I have is what happened at the exchange to provoke my > COPP policy? Alternatively, is this normal or indicate who has the > problem: > > > > r-pop-min-1#deb ipv6 icmp > ICMP Packet debugging is on > r-pop-min-1# > Jul 17 14:36:08.143 CDT: ICMPv6: Received N-Solicit, > Src=FE80::56E0:3200:50CE:4178, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.285 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.359 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.433 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.435 CDT: ICMPv6: Sent N-Solicit, > Src=FE80::CA4C:75FF:FE23:805, Dst=2001:504:27::8252:0:1 > Jul 17 14:36:08.459 CDT: ICMPv6: Received N-Advert, > Src=2001:504:27::8252:0:1, Dst=FE80::CA4C:75FF:FE23:805 > Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.539 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.559 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.586 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.617 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.687 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.782 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > r-pop-min-1# > Jul 17 14:36:08.842 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.990 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.028 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.070 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.148 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.203 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.327 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.399 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.439 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.481 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.533 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.581 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.608 CDT: ICMPv6: Received N-Solicit, > Src=FE80::2E21:72FF:FE71:37B1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.613 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 > r-pop-min-1# > Jul 17 14:36:09.659 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.884 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.069 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.172 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.240 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.320 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.364 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.441 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.521 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.588 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.622 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.659 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.684 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.817 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.853 CDT: ICMPv6: Received type 130, > Src=FE80::21B:DFF:FEE7:15C0, Dst=FF02::1 > r-pop-min-1# > Jul 17 14:36:10.908 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.925 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > > I'm thinking that the answer is that this is not normal, as it looks > like I'm getting duplicate solicitations in the same second. > > -James > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 18, 2014

Re: IPv6 neighbor solicitation at the exchange

by Koch, Andrew

The multiple NS is expected - as we all have the last 2 hextets of our assigned address as 0:1, we all end up in multicast group ff02::1:ff00:1 as our solicited node multicast (uses the last 6 hex digits in this format - ff02::1:ffxx:xxxx) So, your address 2001:504:27::e0f:0:1, ends with the last 6 digits 00:0001 and creating a solicited node multicast you listen on ff02::1:ff00:0001. I end up the same with our global unicast address 2001:504:27::1055:0:1. Poor numbering scheme results in everyone in the same multicast group. My link local address is fe80::21d:a2ff:fef2:a32a, so I also join group ff02::1:fff2:a32a, but I am the only member there as my link local is the only that ends in f2:a32a. HTH, Andy Koch TDS Telecom - IP Network Operations andrew.koch(a)tdstelecom.com Desk: 608-664-4694 Cell: 608-616-0072 Andy > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > James Stahr > Sent: Thursday, July 17, 2014 16:07 > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] IPv6 neighbor solicitation at the exchange > > First off, Did anyone make any changes on 07/15/2014 around 08:00? > > The reason is that I think I've resolved an issue with our IPv6 peering > with the MICE route servers, Charter, and TDS and I'm looking for a > larger audience to see if it's my issue or perhaps an issue at the > exchange. I believe it to be the latter, but I'm not an IPv6 expert. > > Starting two days ago around 8am CDT, we started experiencing BGP > timeouts on some of our IPv6 BGP sessions. I was able to work around > the issue by removing our COPP policy and the BGP sessions were stable > for 24 hours. Reapplied the policy, sessions started to drop again. > Looked at the policy to see which category is being exceeded, it's not > the routing section which allows BGP/BFD/etc, but the ICMP-v6 one: > > > ipv6 access-list COPP-icmp-v6 > remark ICMP type 1/3,2,3/0,3/1,4/0,4/1,4/2,130,143 > permit icmp any any destination-unreachable > permit icmp any any packet-too-big > permit icmp any any time-exceeded > permit icmp any any parameter-problem > remark nd-na, nd-ns, ra, rs > permit icmp any any nd-na > permit icmp any any nd-ns > permit icmp any any router-advertisement > permit icmp any any router-solicitation > remark MLD - query, report_v2 > permit icmp any any mld-query > permit icmp any any 143 > > > which is being policed like this: > > class Icmp-v6 > police 32000 60000 120000 conform-action transmit exceed-action drop > > I've worked around the issue by making a 4x increase in the policing, > but the question I have is what happened at the exchange to provoke my > COPP policy? Alternatively, is this normal or indicate who has the > problem: > > > > r-pop-min-1#deb ipv6 icmp > ICMP Packet debugging is on > r-pop-min-1# > Jul 17 14:36:08.143 CDT: ICMPv6: Received N-Solicit, > Src=FE80::56E0:3200:50CE:4178, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.285 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.359 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.433 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.435 CDT: ICMPv6: Sent N-Solicit, > Src=FE80::CA4C:75FF:FE23:805, Dst=2001:504:27::8252:0:1 > Jul 17 14:36:08.459 CDT: ICMPv6: Received N-Advert, > Src=2001:504:27::8252:0:1, Dst=FE80::CA4C:75FF:FE23:805 > Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.539 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.559 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.586 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.617 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.687 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.782 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > r-pop-min-1# > Jul 17 14:36:08.842 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:08.990 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.028 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.070 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.148 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.203 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.327 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.399 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.439 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.481 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.533 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.581 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.608 CDT: ICMPv6: Received N-Solicit, > Src=FE80::2E21:72FF:FE71:37B1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.613 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 > r-pop-min-1# > Jul 17 14:36:09.659 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:09.884 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.069 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.172 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.240 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.320 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.364 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.441 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.521 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.588 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.622 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.659 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.684 CDT: ICMPv6: Received N-Solicit, > Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.817 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.853 CDT: ICMPv6: Received type 130, > Src=FE80::21B:DFF:FEE7:15C0, Dst=FF02::1 > r-pop-min-1# > Jul 17 14:36:10.908 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > Jul 17 14:36:10.925 CDT: ICMPv6: Received N-Solicit, > Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 > > I'm thinking that the answer is that this is not normal, as it looks > like I'm getting duplicate solicitations in the same second. > > -James > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 18, 2014

Re: IPv6 neighbor solicitation at the exchange

by James Stahr

On 07/18/2014 10:01 AM, Derek Poehls wrote: > We turned up that morning, and looking at logs that’s about the time I > put my IPv6 address on. Looking at my debug it’s similar. I took my > IPv6 address off the interface, please let me know if that resolved it. > > I have a ticket in with support. > > Thanks, > > I had a side email going with TDS on this issue before I emailed the MICE list. Their explanation is that this is actually expected behavior because of how the exchange has decided to assign IPv6 addresses to exchange members and how solicited node multicast works - everyone has the same last 24 bits (actually 32 bits) of their IPv6 address, so we all share the same solicited-node multicast address. http://en.wikipedia.org/wiki/Solicited-node_multicast_address > -=-=-=-=-=-=-=-=- > > * > Derek Poehls* > *NOC Supervisor/Senior Network Engineer* > *(218) 284-5775* > > On Jul 17, 2014, at 4:07 PM, James Stahr <stahr(a)MAILBAG.COM > <mailto:stahr@MAILBAG.COM>> wrote: > >> First off, Did anyone make any changes on 07/15/2014 around 08:00? >> >> The reason is that I think I've resolved an issue with our IPv6 >> peering with the MICE route servers, Charter, and TDS and I'm looking >> for a larger audience to see if it's my issue or perhaps an issue at >> the exchange. I believe it to be the latter, but I'm not an IPv6 expert. >> >> Starting two days ago around 8am CDT, we started experiencing BGP >> timeouts on some of our IPv6 BGP sessions. I was able to work around >> the issue by removing our COPP policy and the BGP sessions were >> stable for 24 hours. Reapplied the policy, sessions started to drop >> again. Looked at the policy to see which category is being exceeded, >> it's not the routing section which allows BGP/BFD/etc, but the >> ICMP-v6 one: >> >> >> ipv6 access-list COPP-icmp-v6 >> remark ICMP type 1/3,2,3/0,3/1,4/0,4/1,4/2,130,143 >> permit icmp any any destination-unreachable >> permit icmp any any packet-too-big >> permit icmp any any time-exceeded >> permit icmp any any parameter-problem >> remark nd-na, nd-ns, ra, rs >> permit icmp any any nd-na >> permit icmp any any nd-ns >> permit icmp any any router-advertisement >> permit icmp any any router-solicitation >> remark MLD - query, report_v2 >> permit icmp any any mld-query >> permit icmp any any 143 >> >> >> which is being policed like this: >> >> class Icmp-v6 >> police 32000 60000 120000 conform-action transmit exceed-action drop >> >> I've worked around the issue by making a 4x increase in the policing, >> but the question I have is what happened at the exchange to provoke >> my COPP policy? Alternatively, is this normal or indicate who has >> the problem: >> >> >> >> r-pop-min-1#deb ipv6 icmp >> ICMP Packet debugging is on >> r-pop-min-1# >> Jul 17 14:36:08.143 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::56E0:3200:50CE:4178, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.285 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.359 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.433 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.435 CDT: ICMPv6: Sent N-Solicit, >> Src=FE80::CA4C:75FF:FE23:805, Dst=2001:504:27::8252:0:1 >> Jul 17 14:36:08.459 CDT: ICMPv6: Received N-Advert, >> Src=2001:504:27::8252:0:1, Dst=FE80::CA4C:75FF:FE23:805 >> Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.539 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.559 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.586 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.617 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.687 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.782 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> r-pop-min-1# >> Jul 17 14:36:08.842 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:08.990 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.028 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.070 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.148 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.203 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.327 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.399 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.439 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.481 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.533 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.581 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.608 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::2E21:72FF:FE71:37B1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.613 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 >> r-pop-min-1# >> Jul 17 14:36:09.659 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:09.884 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.069 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.172 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.240 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.320 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.364 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.441 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.521 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.588 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.622 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.659 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.684 CDT: ICMPv6: Received N-Solicit, >> Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.817 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.853 CDT: ICMPv6: Received type 130, >> Src=FE80::21B:DFF:FEE7:15C0, Dst=FF02::1 >> r-pop-min-1# >> Jul 17 14:36:10.908 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> Jul 17 14:36:10.925 CDT: ICMPv6: Received N-Solicit, >> Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 >> >> I'm thinking that the answer is that this is not normal, as it looks >> like I'm getting duplicate solicitations in the same second. >> >> -James >> >> ######################################################################## >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> ?SUBED1=MICE-DISCUSS&A=1 >> > > > ------------------------------------------------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 <?SUBED1=MICE-DISCUSS&A=1> > ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 18, 2014

Re: IPv6 neighbor solicitation at the exchange

by Derek Poehls

We turned up that morning, and looking at logs that’s about the time I put my IPv6 address on. Looking at my debug it’s similar. I took my IPv6 address off the interface, please let me know if that resolved it. I have a ticket in with support. Thanks, -=-=-=-=-=-=-=-=- [cid:BADDE7B8-E50D-42F2-8E20-30FD7618126E] Derek Poehls NOC Supervisor/Senior Network Engineer (218) 284-5775 On Jul 17, 2014, at 4:07 PM, James Stahr <stahr(a)MAILBAG.COM<mailto:stahr@MAILBAG.COM>> wrote: First off, Did anyone make any changes on 07/15/2014 around 08:00? The reason is that I think I've resolved an issue with our IPv6 peering with the MICE route servers, Charter, and TDS and I'm looking for a larger audience to see if it's my issue or perhaps an issue at the exchange. I believe it to be the latter, but I'm not an IPv6 expert. Starting two days ago around 8am CDT, we started experiencing BGP timeouts on some of our IPv6 BGP sessions. I was able to work around the issue by removing our COPP policy and the BGP sessions were stable for 24 hours. Reapplied the policy, sessions started to drop again. Looked at the policy to see which category is being exceeded, it's not the routing section which allows BGP/BFD/etc, but the ICMP-v6 one: ipv6 access-list COPP-icmp-v6 remark ICMP type 1/3,2,3/0,3/1,4/0,4/1,4/2,130,143 permit icmp any any destination-unreachable permit icmp any any packet-too-big permit icmp any any time-exceeded permit icmp any any parameter-problem remark nd-na, nd-ns, ra, rs permit icmp any any nd-na permit icmp any any nd-ns permit icmp any any router-advertisement permit icmp any any router-solicitation remark MLD - query, report_v2 permit icmp any any mld-query permit icmp any any 143 which is being policed like this: class Icmp-v6 police 32000 60000 120000 conform-action transmit exceed-action drop I've worked around the issue by making a 4x increase in the policing, but the question I have is what happened at the exchange to provoke my COPP policy? Alternatively, is this normal or indicate who has the problem: r-pop-min-1#deb ipv6 icmp ICMP Packet debugging is on r-pop-min-1# Jul 17 14:36:08.143 CDT: ICMPv6: Received N-Solicit, Src=FE80::56E0:3200:50CE:4178, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.285 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.359 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.433 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.435 CDT: ICMPv6: Sent N-Solicit, Src=FE80::CA4C:75FF:FE23:805, Dst=2001:504:27::8252:0:1 Jul 17 14:36:08.459 CDT: ICMPv6: Received N-Advert, Src=2001:504:27::8252:0:1, Dst=FE80::CA4C:75FF:FE23:805 Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.539 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.559 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.586 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.617 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.687 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.782 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 r-pop-min-1# Jul 17 14:36:08.842 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.990 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.028 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.070 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.148 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.203 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.327 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.399 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.439 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.481 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.533 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.581 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.608 CDT: ICMPv6: Received N-Solicit, Src=FE80::2E21:72FF:FE71:37B1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.613 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 r-pop-min-1# Jul 17 14:36:09.659 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.884 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.069 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.172 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.240 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.320 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.364 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.441 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.521 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.588 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.622 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.659 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.684 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.817 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.853 CDT: ICMPv6: Received type 130, Src=FE80::21B:DFF:FEE7:15C0, Dst=FF02::1 r-pop-min-1# Jul 17 14:36:10.908 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.925 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 I'm thinking that the answer is that this is not normal, as it looks like I'm getting duplicate solicitations in the same second. -James ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 18, 2014

Re: MICE UG 13 - Duluth July 24th Note 2PM start

by Mike Johnston

On 7/18/2014 8:12 AM, Shaun Carlson wrote: > > In order to get a good head count for planning, can you respond with > your ASN and how many people will be attending the Duluth meeting? 33362: Two of us ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 18, 2014

Re: MICE UG 13 - Duluth July 24th Note 2PM start

by Thomas Johnson

Eric Crist and myself will be driving up from the cities, AS62708. On Fri, Jul 18, 2014 at 8:12 AM, Shaun Carlson <shaun.carlson(a)arvig.com> wrote: > All, > > In order to get a good head count for planning, can you respond with your > ASN and how many people will be attending the Duluth meeting? > > Thanks! > > s > > > Shaun Carlson > Network Engineering Manager | Arvig > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > > > On Tue, Jul 8, 2014 at 1:01 PM, Mike Hemphill <mike.hemphill(a)cologix.com> > wrote: >> >> Good Afternoon All! >> >> >> >> MICE UG 13 has been scheduled, as follows: >> >> >> >> Date: Thursday, July 24th >> >> Time: 2:00 pm (1400 Hours) David Farmer has the facility reserved until >> 5PM >> >> Location: University of Minnesota, Duluth campus, Griggs Center, located >> in the Kirby Student Center (KSC) http://www.d.umn.edu/maps/KSC/ >> >> >> >> Please send your agenda items when you have a chance! >> >> >> >> Also please invite business & other entities that may have an interest in >> connecting to MICE. >> >> Our goal is to extend the reach of MICE connectivity to outstate >> institutions & companies. >> >> >> >> Thanks! >> >> Reid, Shaun & Mike >> >> >> >> Mike Hemphill >> General Manager | Cologix, Inc. >> 511 11th Ave S, Suite 450 | Minneapolis, MN 55415 >> P: 1+612.333.1922 | M: 1+612.812.5242 >> mike.hemphill(a)cologix.com >> >> >> >> >> ________________________________ >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> ?SUBED1=MICE-DISCUSS&A=1 > > > > ________________________________ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 -- Thomas Johnson ClaimLynx, Inc. 952-593-5969 x2302 -- This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender or call ClaimLynx at (952) 593-5969. ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 18, 2014

Re: MICE UG 13 - Duluth July 24th Note 2PM start

by Eric Crist

AS62708. Two of us. On Friday, July 18, 2014, Shaun Carlson <shaun.carlson(a)arvig.com> wrote: > All, > > In order to get a good head count for planning, can you respond with your > ASN and how many people will be attending the Duluth meeting? > > Thanks! > > s > > > > *Shaun Carlson *Network Engineering Manager | Arvig > ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com > <javascript:_e(%7B%7D,'cvml','shaun.carlson(a)arvig.com');> > > > On Tue, Jul 8, 2014 at 1:01 PM, Mike Hemphill <mike.hemphill(a)cologix.com > <javascript:_e(%7B%7D,'cvml','mike.hemphill(a)cologix.com');>> wrote: > >> Good Afternoon All! >> >> >> >> MICE UG 13 has been scheduled, as follows: >> >> >> >> Date: Thursday, July 24th >> >> Time: 2:00 pm (1400 Hours) David Farmer has the facility reserved until >> 5PM >> >> Location: University of Minnesota, Duluth campus, Griggs Center, located >> in the *Kirby Student Center (KSC) * http://www.d.umn.edu/maps/KSC/ >> >> >> >> Please send your agenda items when you have a chance! >> >> >> >> Also please invite business & other entities that may have an interest in >> connecting to MICE. >> >> Our goal is to extend the reach of MICE connectivity to outstate >> institutions & companies. >> >> >> >> Thanks! >> >> Reid, Shaun & Mike >> >> >> >> *Mike Hemphill* >> *General Manager | **Cologix, Inc. <http://www.cologix.com/>* >> >> >> *511 11th Ave S, Suite 450 | Minneapolis, MN 55415P: 1+612.333.1922 | M: >> 1+612.812.5242 mike.hemphill(a)cologix.com >> <javascript:_e(%7B%7D,'cvml','mike.hemphill(a)cologix.com');>* >> >> >> >> ------------------------------ >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> ?SUBED1=MICE-DISCUSS&A=1 >> > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > -- Eric F Crist System Administrator ClaimLynx, Inc (952) 593-5969 x2301 -- This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender or call ClaimLynx at (952) 593-5969. ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 18, 2014

Re: MICE UG 13 - Duluth July 24th Note 2PM start

by Shaun Carlson

All, In order to get a good head count for planning, can you respond with your ASN and how many people will be attending the Duluth meeting? Thanks! s *Shaun Carlson*Network Engineering Manager | Arvig ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com On Tue, Jul 8, 2014 at 1:01 PM, Mike Hemphill <mike.hemphill(a)cologix.com> wrote: > Good Afternoon All! > > > > MICE UG 13 has been scheduled, as follows: > > > > Date: Thursday, July 24th > > Time: 2:00 pm (1400 Hours) David Farmer has the facility reserved until 5PM > > Location: University of Minnesota, Duluth campus, Griggs Center, located > in the *Kirby Student Center (KSC) * http://www.d.umn.edu/maps/KSC/ > > > > Please send your agenda items when you have a chance! > > > > Also please invite business & other entities that may have an interest in > connecting to MICE. > > Our goal is to extend the reach of MICE connectivity to outstate > institutions & companies. > > > > Thanks! > > Reid, Shaun & Mike > > > > *Mike Hemphill* > *General Manager | **Cologix, Inc. <http://www.cologix.com/>* > > > *511 11th Ave S, Suite 450 | Minneapolis, MN 55415P: 1+612.333.1922 | M: > 1+612.812.5242mike.hemphill(a)cologix.com <mike.hemphill(a)cologix.com>* > > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > ?SUBED1=MICE-DISCUSS&A=1 > ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 18, 2014

IPv6 neighbor solicitation at the exchange

by James Stahr

First off, Did anyone make any changes on 07/15/2014 around 08:00? The reason is that I think I've resolved an issue with our IPv6 peering with the MICE route servers, Charter, and TDS and I'm looking for a larger audience to see if it's my issue or perhaps an issue at the exchange. I believe it to be the latter, but I'm not an IPv6 expert. Starting two days ago around 8am CDT, we started experiencing BGP timeouts on some of our IPv6 BGP sessions. I was able to work around the issue by removing our COPP policy and the BGP sessions were stable for 24 hours. Reapplied the policy, sessions started to drop again. Looked at the policy to see which category is being exceeded, it's not the routing section which allows BGP/BFD/etc, but the ICMP-v6 one: ipv6 access-list COPP-icmp-v6 remark ICMP type 1/3,2,3/0,3/1,4/0,4/1,4/2,130,143 permit icmp any any destination-unreachable permit icmp any any packet-too-big permit icmp any any time-exceeded permit icmp any any parameter-problem remark nd-na, nd-ns, ra, rs permit icmp any any nd-na permit icmp any any nd-ns permit icmp any any router-advertisement permit icmp any any router-solicitation remark MLD - query, report_v2 permit icmp any any mld-query permit icmp any any 143 which is being policed like this: class Icmp-v6 police 32000 60000 120000 conform-action transmit exceed-action drop I've worked around the issue by making a 4x increase in the policing, but the question I have is what happened at the exchange to provoke my COPP policy? Alternatively, is this normal or indicate who has the problem: r-pop-min-1#deb ipv6 icmp ICMP Packet debugging is on r-pop-min-1# Jul 17 14:36:08.143 CDT: ICMPv6: Received N-Solicit, Src=FE80::56E0:3200:50CE:4178, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.178 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.281 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.285 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.359 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.433 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.435 CDT: ICMPv6: Sent N-Solicit, Src=FE80::CA4C:75FF:FE23:805, Dst=2001:504:27::8252:0:1 Jul 17 14:36:08.459 CDT: ICMPv6: Received N-Advert, Src=2001:504:27::8252:0:1, Dst=FE80::CA4C:75FF:FE23:805 Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.535 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:08.539 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.559 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.586 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.617 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.687 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.782 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:08.783 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 r-pop-min-1# Jul 17 14:36:08.842 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:08.990 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.028 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.070 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.148 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.191 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.203 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.322 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.327 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.399 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.439 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.481 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.533 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.572 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:09.581 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.608 CDT: ICMPv6: Received N-Solicit, Src=FE80::2E21:72FF:FE71:37B1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.613 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 r-pop-min-1# Jul 17 14:36:09.659 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.831 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:09.884 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.069 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.172 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.223 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.240 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.320 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.364 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.441 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.521 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.573 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.588 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::B664:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.622 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.659 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::8252:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.684 CDT: ICMPv6: Received N-Solicit, Src=FE80::221:9BFF:FE8A:D29D, Dst=FF02::1:FF00:1 Jul 17 14:36:10.817 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.830 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::3BA3:0:1, Dst=FF02::1:FF00:1 Jul 17 14:36:10.853 CDT: ICMPv6: Received type 130, Src=FE80::21B:DFF:FEE7:15C0, Dst=FF02::1 r-pop-min-1# Jul 17 14:36:10.908 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 Jul 17 14:36:10.925 CDT: ICMPv6: Received N-Solicit, Src=2001:504:27::D1AF:0:2, Dst=FF02::1:FF00:1 I'm thinking that the answer is that this is not normal, as it looks like I'm getting duplicate solicitations in the same second. -James ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: ?SUBED1=MICE-DISCUSS&A=1

July 17, 2014