- mice-discuss - lists.micemn.net

Re: Juniper Switch upgrade

by James Stahr

On 8/23/2012 5:09 PM, Owen DeLong wrote: > On Aug 23, 2012, at 11:33 , James Stahr<stahr(a)mailbag.com> wrote: > > >> We can remotely verify that everyone has configured a secondary IP, but that's just the start. You've also got to duplicate ALL of your peer BGP sessions beforehand as well. Why? Well, >> I don't believe Cisco can initiate a BGP session on a secondary address so once a $C router switches their primary and secondary, they cannot initiate a BGP session. Not a problem yet. What about when the next one does it? Suddenly neither of the Cisco devices can peer with each other.. I've not been through an exchange re-address, but given this limitation, I foresee many problems and the idea of a "flag day" much more appealing - luckily though, most participants are using the route server. >> > It can, actually... You just need to add update-source<IP_ADDR> to the configuration. > > A straight IP isn't an option here on either SRE or an ASR running IOS-XE 3.4.2, only a list of 50+ different types of interfaces. Are you using IOS-XR? -James ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 24, 2012

Re: Juniper Switch upgrade

by Owen DeLong

On Aug 23, 2012, at 11:33 , James Stahr <stahr(a)mailbag.com> wrote: > On 8/22/2012 4:51 PM, Doug McIntyre wrote: >> On Wed, Aug 22, 2012 at 02:47:21PM -0500, Justin Krejci wrote: >> >>> While I agree with the general sentiment that the IP change and switch >>> change will likely be smooth, the IP change can be done more >>> transparently and has literally nothing to do with the L2 gear. >>> To that end, I don't see any reason to not configure/assign the new IP >>> block now and let folks start using it right away, even before the >>> switch switch. >>> >> But, we don't have a central router? >> >> If your border to the exchange right now got a prefix with the next >> hop of 206.108.255.3, how'd you get there? You'd have no route to host >> for 206.108.255.3. >> >> That is why I brought up the secondary IPs. Once everybody puts in a >> secondary IP in 206.108.255.0/24, they'll know how to try to get to >> 206.108.255.3 for my prefix announcement. But I can't really do the >> prefix announcement with the next-hop in 206.108.255.3 until everybody >> knows how to get to 206.108.255.0/24? >> >> > We can remotely verify that everyone has configured a secondary IP, but that's just the start. You've also got to duplicate ALL of your peer BGP sessions beforehand as well. Why? Well, > I don't believe Cisco can initiate a BGP session on a secondary address so once a $C router switches their primary and secondary, they cannot initiate a BGP session. Not a problem yet. What about when the next one does it? Suddenly neither of the Cisco devices can peer with each other.. I've not been through an exchange re-address, but given this limitation, I foresee many problems and the idea of a "flag day" much more appealing - luckily though, most participants are using the route server. It can, actually... You just need to add update-source <IP_ADDR> to the configuration. > > Hmm... I assume the BIRD configuration allows you to specify source IP's to be used for each peer? > I don't know of any router configurations that don't. Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

Re: MNNS or Digital Plains outage?

by Frank Bulk

ns[12].digitalplains.net is back up again. The A record I had for digitalplains.net _was_ old, so I was chasing a rabbit there. Frank -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, August 23, 2012 2:53 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MNNS or Digital Plains outage? I found an old A record for digitalplains.net from DNShistory.org -- looks like a routing loop on Knology's network: nagios:/home/fbulk# tcptraceroute 216.16.38.67 Selected device eth0.3, address 96.31.0.5, port 37082 for outgoing packets Tracing the path to 216.16.38.67 on TCP port 80 (www), 30 hops max 1 router-core-inside.mtcnet.net (96.31.0.254) 0.260 ms 0.179 ms 0.294 ms 2 sxct.movl.mtcnet.net (167.142.156.194) 0.201 ms 0.126 ms 0.133 ms 3 premier.movl-mlx.fbnt.netins.net (173.215.60.1) 2.005 ms 1.956 ms 1.936 ms 4 ins-kb1-te-13-2-220.kmrr.netins.net (167.142.64.253) 6.404 ms 6.402 ms 6.422 ms 5 ins-kc2-et-8-3.kmrr.netins.net (167.142.67.37) 8.122 ms 8.060 ms 8.047 ms 6 ins-dc1-et-8-1.desm.netins.net (167.142.67.29) 8.120 ms 8.091 ms 8.124 ms 7 te-3-3.car2.KansasCity1.Level3.net (4.53.34.113) 14.952 ms 41.355 ms 14.533 ms 8 ae-4-4.ebr2.Denver1.Level3.net (4.69.135.238) 35.185 ms 30.963 ms 26.955 ms 9 ae-3-3.ebr1.Chicago2.Level3.net (4.69.132.62) 51.294 ms 51.304 ms 51.312 ms 10 ae-1-51.edge4.Chicago3.Level3.net (4.69.138.134) 51.721 ms 51.737 ms 51.760 ms 11 KNOLOGY-INC.edge4.Chicago3.Level3.net (4.53.98.42) 51.487 ms 51.502 ms 51.497 ms 12 cr01.xe-1-2-0.siouxfalls.hubh.knology.net (24.214.2.6) 67.504 ms 89.639 ms 67.464 ms 13 user-24-96-198-142.knology.net (24.96.198.142) 67.610 ms 67.558 ms 67.570 ms 14 user-24-96-198-141.knology.net (24.96.198.141) 67.865 ms 67.828 ms 67.848 ms 15 user-24-96-198-142.knology.net (24.96.198.142) 67.572 ms 67.583 ms 67.611 ms 16 user-24-96-198-141.knology.net (24.96.198.141) 96.295 ms 67.852 ms 67.811 ms 17 user-24-96-198-142.knology.net (24.96.198.142) 67.694 ms 67.605 ms 67.602 ms 18 user-24-96-198-141.knology.net (24.96.198.141) 67.879 ms 67.861 ms 67.810 ms 19 user-24-96-198-142.knology.net (24.96.198.142) 67.613 ms 67.592 ms 67.660 ms 20 user-24-96-198-141.knology.net (24.96.198.141) 67.833 ms 85.509 ms 67.876 ms 21 user-24-96-198-142.knology.net (24.96.198.142) 67.620 ms 67.637 ms 67.659 ms 22 user-24-96-198-141.knology.net (24.96.198.141) 67.836 ms 67.863 ms 67.928 ms 23 user-24-96-198-142.knology.net (24.96.198.142) 67.672 ms 67.648 ms 67.682 ms 24 user-24-96-198-141.knology.net (24.96.198.141) 67.940 ms 67.955 ms 118.981 ms 25 user-24-96-198-142.knology.net (24.96.198.142) 67.727 ms 67.797 ms 67.707 ms 26 user-24-96-198-141.knology.net (24.96.198.141) 67.903 ms 67.908 ms 67.956 ms 27 user-24-96-198-142.knology.net (24.96.198.142) 67.719 ms 67.715 ms 67.736 ms 28 user-24-96-198-141.knology.net (24.96.198.141) 68.070 ms 67.926 ms 67.972 ms 29 user-24-96-198-142.knology.net (24.96.198.142) 67.835 ms 67.724 ms^C Frank -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, August 23, 2012 2:38 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] MNNS or Digital Plains outage? We have some email queued up to a domain that use digitalplains.net DNS servers (company based in Slayton). Those servers don't respond, and calling the target domain (based in Pipestone) they said that there's an issue upstream, something with Knology. Apparently Digital Plains recently assumed responsibility for all MNNS.COM services, and I can't hit any of their web properties, either. I called Digital Plains toll free support number, but it just goes to someone's voicemail. Anyone know what's going on? Frank ######################################################################## 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 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

Re: Juniper Switch upgrade

by Jay Hanke

> I don't believe Cisco can initiate a BGP session on a secondary address so > once a $C router switches their primary and secondary, they cannot initiate > a BGP session. I'm pretty sure BGP on secondary IP addresses on IOS is permitted since it's unicast and not a link-state protocol like OSPF. Jay ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

Re: MNNS or Digital Plains outage?

by Frank Bulk

I found an old A record for digitalplains.net from DNShistory.org -- looks like a routing loop on Knology's network: nagios:/home/fbulk# tcptraceroute 216.16.38.67 Selected device eth0.3, address 96.31.0.5, port 37082 for outgoing packets Tracing the path to 216.16.38.67 on TCP port 80 (www), 30 hops max 1 router-core-inside.mtcnet.net (96.31.0.254) 0.260 ms 0.179 ms 0.294 ms 2 sxct.movl.mtcnet.net (167.142.156.194) 0.201 ms 0.126 ms 0.133 ms 3 premier.movl-mlx.fbnt.netins.net (173.215.60.1) 2.005 ms 1.956 ms 1.936 ms 4 ins-kb1-te-13-2-220.kmrr.netins.net (167.142.64.253) 6.404 ms 6.402 ms 6.422 ms 5 ins-kc2-et-8-3.kmrr.netins.net (167.142.67.37) 8.122 ms 8.060 ms 8.047 ms 6 ins-dc1-et-8-1.desm.netins.net (167.142.67.29) 8.120 ms 8.091 ms 8.124 ms 7 te-3-3.car2.KansasCity1.Level3.net (4.53.34.113) 14.952 ms 41.355 ms 14.533 ms 8 ae-4-4.ebr2.Denver1.Level3.net (4.69.135.238) 35.185 ms 30.963 ms 26.955 ms 9 ae-3-3.ebr1.Chicago2.Level3.net (4.69.132.62) 51.294 ms 51.304 ms 51.312 ms 10 ae-1-51.edge4.Chicago3.Level3.net (4.69.138.134) 51.721 ms 51.737 ms 51.760 ms 11 KNOLOGY-INC.edge4.Chicago3.Level3.net (4.53.98.42) 51.487 ms 51.502 ms 51.497 ms 12 cr01.xe-1-2-0.siouxfalls.hubh.knology.net (24.214.2.6) 67.504 ms 89.639 ms 67.464 ms 13 user-24-96-198-142.knology.net (24.96.198.142) 67.610 ms 67.558 ms 67.570 ms 14 user-24-96-198-141.knology.net (24.96.198.141) 67.865 ms 67.828 ms 67.848 ms 15 user-24-96-198-142.knology.net (24.96.198.142) 67.572 ms 67.583 ms 67.611 ms 16 user-24-96-198-141.knology.net (24.96.198.141) 96.295 ms 67.852 ms 67.811 ms 17 user-24-96-198-142.knology.net (24.96.198.142) 67.694 ms 67.605 ms 67.602 ms 18 user-24-96-198-141.knology.net (24.96.198.141) 67.879 ms 67.861 ms 67.810 ms 19 user-24-96-198-142.knology.net (24.96.198.142) 67.613 ms 67.592 ms 67.660 ms 20 user-24-96-198-141.knology.net (24.96.198.141) 67.833 ms 85.509 ms 67.876 ms 21 user-24-96-198-142.knology.net (24.96.198.142) 67.620 ms 67.637 ms 67.659 ms 22 user-24-96-198-141.knology.net (24.96.198.141) 67.836 ms 67.863 ms 67.928 ms 23 user-24-96-198-142.knology.net (24.96.198.142) 67.672 ms 67.648 ms 67.682 ms 24 user-24-96-198-141.knology.net (24.96.198.141) 67.940 ms 67.955 ms 118.981 ms 25 user-24-96-198-142.knology.net (24.96.198.142) 67.727 ms 67.797 ms 67.707 ms 26 user-24-96-198-141.knology.net (24.96.198.141) 67.903 ms 67.908 ms 67.956 ms 27 user-24-96-198-142.knology.net (24.96.198.142) 67.719 ms 67.715 ms 67.736 ms 28 user-24-96-198-141.knology.net (24.96.198.141) 68.070 ms 67.926 ms 67.972 ms 29 user-24-96-198-142.knology.net (24.96.198.142) 67.835 ms 67.724 ms^C Frank -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Thursday, August 23, 2012 2:38 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] MNNS or Digital Plains outage? We have some email queued up to a domain that use digitalplains.net DNS servers (company based in Slayton). Those servers don't respond, and calling the target domain (based in Pipestone) they said that there's an issue upstream, something with Knology. Apparently Digital Plains recently assumed responsibility for all MNNS.COM services, and I can't hit any of their web properties, either. I called Digital Plains toll free support number, but it just goes to someone's voicemail. Anyone know what's going on? Frank ######################################################################## 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

Aug. 23, 2012

Re: Juniper Switch upgrade

by Doug McIntyre

On Thu, Aug 23, 2012 at 01:33:13PM -0500, James Stahr wrote: > We can remotely verify that everyone has configured a secondary IP, > but that's just the start. You've also got to duplicate ALL of your > peer BGP sessions beforehand as well. Why? Well, > I don't believe Cisco can initiate a BGP session on a secondary > address so once a $C router switches their primary and secondary, > they cannot initiate a BGP session. Not a problem yet. What about > when the next one does it? Suddenly neither of the Cisco devices > can peer with each other.. I've not been through an exchange > re-address, but given this limitation, I foresee many problems and > the idea of a "flag day" much more appealing - luckily though, most > participants are using the route server. Yeah, I was thinking of that issue as well. Perhaps subinterfaces could be used like int gig 0/0 ip address 69.147.218.100/24 int gig 0/0.0 ip address 206.108.255.100/24 router bgp 65500 neighbor 69.147.218.1 update-source gig0/0 neighbor 206.108.255.1 update-source gig0/0.0 but I don't have anything to test that out with right now. (not using cisco to talk to MICE right now). But I think my two bilateral peers can probably wait for a renumber at some future time as it is. > Hmm... I assume the BIRD configuration allows you to specify source > IP's to be used for each peer? It looks like 'router id' is allowed per AS peer. Leave the existing, and setup a new peer entry to the new IP with the new 'router id'. -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

MNNS or Digital Plains outage?

by Frank Bulk

We have some email queued up to a domain that use digitalplains.net DNS servers (company based in Slayton). Those servers don't respond, and calling the target domain (based in Pipestone) they said that there's an issue upstream, something with Knology. Apparently Digital Plains recently assumed responsibility for all MNNS.COM services, and I can't hit any of their web properties, either. I called Digital Plains toll free support number, but it just goes to someone's voicemail. Anyone know what's going on? Frank ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

Re: Juniper Switch upgrade

by James Stahr

On 8/22/2012 4:51 PM, Doug McIntyre wrote: > On Wed, Aug 22, 2012 at 02:47:21PM -0500, Justin Krejci wrote: > >> While I agree with the general sentiment that the IP change and switch >> change will likely be smooth, the IP change can be done more >> transparently and has literally nothing to do with the L2 gear. >> To that end, I don't see any reason to not configure/assign the new IP >> block now and let folks start using it right away, even before the >> switch switch. >> > But, we don't have a central router? > > If your border to the exchange right now got a prefix with the next > hop of 206.108.255.3, how'd you get there? You'd have no route to host > for 206.108.255.3. > > That is why I brought up the secondary IPs. Once everybody puts in a > secondary IP in 206.108.255.0/24, they'll know how to try to get to > 206.108.255.3 for my prefix announcement. But I can't really do the > prefix announcement with the next-hop in 206.108.255.3 until everybody > knows how to get to 206.108.255.0/24? > > We can remotely verify that everyone has configured a secondary IP, but that's just the start. You've also got to duplicate ALL of your peer BGP sessions beforehand as well. Why? Well, I don't believe Cisco can initiate a BGP session on a secondary address so once a $C router switches their primary and secondary, they cannot initiate a BGP session. Not a problem yet. What about when the next one does it? Suddenly neither of the Cisco devices can peer with each other.. I've not been through an exchange re-address, but given this limitation, I foresee many problems and the idea of a "flag day" much more appealing - luckily though, most participants are using the route server. Hmm... I assume the BIRD configuration allows you to specify source IP's to be used for each peer? -James CDW ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

Re: Juniper Switch upgrade

by Mike Horwath

On Wed, Aug 22, 2012 at 04:45:17PM -0700, Mike Tindle wrote: > Easiest migration is to leave the last octet the same for > everything. Quick regex replace and your old BGP configs have been > copied to the new address range. If you start messing with the > assigned last octets, it's just an added headache. This was a verification item. I am *not* officially involved with the transition. -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 23, 2012

Re: Juniper Switch upgrade

by Mike Tindle

Easiest migration is to leave the last octet the same for everything. Quick regex replace and your old BGP configs have been copied to the new address range. If you start messing with the assigned last octets, it's just an added headache. Regards, Mike On Aug 22, 2012, at 3:30 PM, Mike Horwath wrote: > BTW: what am I gonna use for the route servers for IP addresses? > > 69.147.218.1 > 69.147.218.2 > > I'm guessing, cause of the idea before, that it should just end in .1 > and .2 again. > > Right? > > If so I should be ready to change over to the new /24 and then > secondary these addresses for later removal - I can update the > interfaces during the switch downtime. > > -- > Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net > The universe is an island, surrounded by whatever it is > that surrounds universes. - Berkeley Fortune > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > *----------- H U R R I C A N E - E L E C T R I C ---------->> | Mike Tindle | Senior Network Engineer | mtindle(a)he.net | ASN 6939 | http://www.he.net | 510-580-4126 *---------------------------------------------------->> ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Packet loss between GigaPOP and Onvoy/Zayo

by Koch, Andrew

> -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Jay Hanke > Sent: Wednesday, August 22, 2012 15:24 > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Packet loss between GigaPOP and Onvoy/Zayo > > On Wed, Aug 22, 2012 at 3:05 PM, Larry Patterson <larry(a)atomicdata.com> > wrote: > > That being said, what is the method > > for reporting networking issues amongst peering members? > > Usually directly to the peering contact or via the MICE-DISCUSS list. Please contact direct, at least for any concerns with TDS. There are many of us that are not able to monitor the -DISCUSS list for real-time problem notification. 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: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Mike Horwath

BTW: what am I gonna use for the route servers for IP addresses? 69.147.218.1 69.147.218.2 I'm guessing, cause of the idea before, that it should just end in .1 and .2 again. Right? If so I should be ready to change over to the new /24 and then secondary these addresses for later removal - I can update the interfaces during the switch downtime. -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Owen DeLong

On Aug 22, 2012, at 14:51 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > On Wed, Aug 22, 2012 at 02:47:21PM -0500, Justin Krejci wrote: >> While I agree with the general sentiment that the IP change and switch >> change will likely be smooth, the IP change can be done more >> transparently and has literally nothing to do with the L2 gear. >> To that end, I don't see any reason to not configure/assign the new IP >> block now and let folks start using it right away, even before the >> switch switch. > > But, we don't have a central router? > > If your border to the exchange right now got a prefix with the next > hop of 206.108.255.3, how'd you get there? You'd have no route to host > for 206.108.255.3. > > That is why I brought up the secondary IPs. Once everybody puts in a > secondary IP in 206.108.255.0/24, they'll know how to try to get to > 206.108.255.3 for my prefix announcement. But I can't really do the > prefix announcement with the next-hop in 206.108.255.3 until everybody > knows how to get to 206.108.255.0/24? > Your next hop for peers that are still peering on the old address should be your old address. For peers on the new address, should be your new address. The problem you describe could only apply, therefore, to the routeservers which are providing next hop data other than their own local interface. In that case, there are multiple possibilities: 1. Run two route-server instances on each address set. 2. Run one route-server instance on each address set. The route-server instances on the old address set shouldn't be seeing new address next-hops. The route-server instances on the new address set shouldn't be seeing old-address next-hops. Yes, it means everyone that is using new addresses has to maintain their old sessions with the route-servers until everyone has a new session. As Mr. Tindle said earlier... I've been through a few of these. They're not rocket science, but trying to herd all the cats into doing it as one massive change all at the same time is an almost certain path to large-scale disruption and lots of time debugging stuff that didn't have to be debugged all at once. A little careful planning and adding sessions one at a time and then judiciously removing sessions that are no longer needed along the way can accomplish this in a reasonable timeframe with a minimal amount of fuss and no mass-scale risks. Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Mike Horwath

On Wed, Aug 22, 2012 at 02:40:09PM -0700, Owen DeLong wrote: > Suggestion instead... During switch maintenance... > > conf term > int bajilliongmillibit0/0 > ip address new-ip new-netmask > ip address old-ip old-netmask secondary > ipv6 address new-ip new-netmask > ipv6 address old-ip old-netmask secondary > > In this way, yes, there will be a brief time where the old-ip > disappears from the router and those BGP sessions will shut down > accordingly. However, since they will already be down for the switch > maintenance, no harm. > > Then, when everyone has completed their address migration, > removing the secondary address is easy and doesn't cause any > outage. There we go, smarty pants win. -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Mike Horwath

On Wed, Aug 22, 2012 at 04:33:23PM -0500, Jay Hanke wrote: > > conf term > > int bajlliongmillibit0/0 > > ip address secondary-ip secondary-netmask > > ^z > > write mem > > > > notice I didn't remove the primary address...nor the old secondary. > > > > Should work? > > That will change the primary IP. When it gets removed the neighbor > dies because that is typically the source IP of the TCP session. You > then need to add the "old" ip as a secondary. Causing the previously > mentioned blip. > > There isn't really secondaries in Junos so, not an issue. What is the > behavior on Brocade and Extreme? I'd suggest making sure BGP is already configured in ahead of time cause that seems smart. Not like it hurts to have them both operational concurrently or anything. But then sk00ling happens. Damnit. Doug explained this: neighbor (x.x.x.x|x:x:x:x:x..) update-source INTERFACE So oh well, guess you just need to change it some night. IT IS NOT THE END OF THE WORLD IF YOUR MICE CONNECTION GOES DOWN Says Nevin. -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Doug McIntyre

On Wed, Aug 22, 2012 at 02:47:21PM -0500, Justin Krejci wrote: > While I agree with the general sentiment that the IP change and switch > change will likely be smooth, the IP change can be done more > transparently and has literally nothing to do with the L2 gear. > To that end, I don't see any reason to not configure/assign the new IP > block now and let folks start using it right away, even before the > switch switch. But, we don't have a central router? If your border to the exchange right now got a prefix with the next hop of 206.108.255.3, how'd you get there? You'd have no route to host for 206.108.255.3. That is why I brought up the secondary IPs. Once everybody puts in a secondary IP in 206.108.255.0/24, they'll know how to try to get to 206.108.255.3 for my prefix announcement. But I can't really do the prefix announcement with the next-hop in 206.108.255.3 until everybody knows how to get to 206.108.255.0/24? -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Owen DeLong

On Aug 22, 2012, at 14:26 , Mike Horwath <drechsau(a)iphouse.net> wrote: > On Wed, Aug 22, 2012 at 01:55:53PM -0700, Owen DeLong wrote: >> Agreed. However, I would say that for those with Cisco gear where an >> address swap requires removing the address from the interface (and >> thus downing their BGP sessions), making the new address primary and >> the old address secondary could, ideally, be done during the switch >> upgrade and thus avoid an additional outage. > > conf term > int bajlliongmillibit0/0 > ip address secondary-ip secondary-netmask > ^z > write mem > > notice I didn't remove the primary address...nor the old secondary. > > Should work? > That will replace the old address with the new one. If your peers haven't all done the same thing and you haven't modified all your BGP sessions accordingly, then bad things happen. If you meant: ... ip address secondary-ip secondary-netmask secondary Then that postpones the problem to the day you deprecate the primary address. In either case, you forgot the IPv6 address. ;-) Suggestion instead... During switch maintenance... conf term int bajilliongmillibit0/0 ip address new-ip new-netmask ip address old-ip old-netmask secondary ipv6 address new-ip new-netmask ipv6 address old-ip old-netmask secondary In this way, yes, there will be a brief time where the old-ip disappears from the router and those BGP sessions will shut down accordingly. However, since they will already be down for the switch maintenance, no harm. Then, when everyone has completed their address migration, removing the secondary address is easy and doesn't cause any outage. Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Mike Bushard, Jr

Brocade follows the same form as Juniper, an IP is an IP. Mike Bushard, Jr | Network Engineer IV | Arvig | 320.256.7471 Office | 320.256.0178 Direct | 320.429.0837 Mobile ** NEW NUMBER ** | 320-256-7555 Fax *** Please update your address book with my new work email: mike.bushard(a)arvig.com *** -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jay Hanke Sent: Wednesday, August 22, 2012 4:33 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Juniper Switch upgrade > conf term > int bajlliongmillibit0/0 > ip address secondary-ip secondary-netmask ^z write mem > > notice I didn't remove the primary address...nor the old secondary. > > Should work? That will change the primary IP. When it gets removed the neighbor dies because that is typically the source IP of the TCP session. You then need to add the "old" ip as a secondary. Causing the previously mentioned blip. There isn't really secondaries in Junos so, not an issue. What is the behavior on Brocade and Extreme? ######################################################################## 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

Aug. 22, 2012

Re: Packet loss between GigaPOP and Onvoy/Zayo

by Mike Hemphill

FYI, no Zayo cross connect ordered as of yet. Mike Mike Hemphill General Manager | Cologix, Inc. 511 11th Ave S, Suite 450 | Minneapolis, MN 55415 P: 612.333.1922 | M: 612.812.5242 mike.hemphill(a)cologix.com cologix.com -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jay Hanke Sent: Wednesday, August 22, 2012 3:24 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Packet loss between GigaPOP and Onvoy/Zayo On Wed, Aug 22, 2012 at 3:05 PM, Larry Patterson <larry(a)atomicdata.com> wrote: > I attempted to report this issue between Zayo and UMN with BGP paths > and packet loss examples on August 15 to Zayo. But because I am not a > customer if Zayo, their support couldn't do anything with it. I'm > glad to hear that the issues are resolved. That being said, what is > the method for reporting networking issues amongst peering members? Usually directly to the peering contact or via the MICE-DISCUSS list. Zayo isn't currently directly connected to the MICE fabric they connect via the Gigapop. Zayo is in the process of turning up a direct connection. They have assignments but I'm not sure if the x-conn has been ordered yet. Jay ######################################################################## 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

Aug. 22, 2012

Re: Juniper Switch upgrade

by Jay Hanke

> conf term > int bajlliongmillibit0/0 > ip address secondary-ip secondary-netmask > ^z > write mem > > notice I didn't remove the primary address...nor the old secondary. > > Should work? That will change the primary IP. When it gets removed the neighbor dies because that is typically the source IP of the TCP session. You then need to add the "old" ip as a secondary. Causing the previously mentioned blip. There isn't really secondaries in Junos so, not an issue. What is the behavior on Brocade and Extreme? ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Mike Horwath

On Wed, Aug 22, 2012 at 01:55:53PM -0700, Owen DeLong wrote: > Agreed. However, I would say that for those with Cisco gear where an > address swap requires removing the address from the interface (and > thus downing their BGP sessions), making the new address primary and > the old address secondary could, ideally, be done during the switch > upgrade and thus avoid an additional outage. conf term int bajlliongmillibit0/0 ip address secondary-ip secondary-netmask ^z write mem notice I didn't remove the primary address...nor the old secondary. Should work? -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Owen DeLong

Agreed. However, I would say that for those with Cisco gear where an address swap requires removing the address from the interface (and thus downing their BGP sessions), making the new address primary and the old address secondary could, ideally, be done during the switch upgrade and thus avoid an additional outage. Owen On Aug 22, 2012, at 12:47 , Justin Krejci <jkrejci(a)USINTERNET.COM> wrote: > While I agree with the general sentiment that the IP change and switch change will likely be smooth, the IP change can be done more transparently and has literally nothing to do with the L2 gear. > To that end, I don't see any reason to not configure/assign the new IP block now and let folks start using it right away, even before the switch switch. > > > > > On Tue, 2012-08-21 at 15:54 -0700, Owen DeLong wrote: >> >> On Aug 21, 2012, at 14:07 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: >> >> > On Tue, Aug 21, 2012 at 03:54:19PM -0500, Jay Hanke wrote: >> >> On Tue, Aug 21, 2012 at 3:46 PM, Mike Bushard, Jr >> >> <mike.bushard(a)arvig.com> wrote: >> >>> I typically would agree Owen, but in this case it may make sense. Everyone >> >>> will be down already, and we won't have multiple outages to the entire >> >>> exchange for IP changes. There will be a considerable amount of work if >> >>> everyone changes addressing on different schedules. I think just saying >> >>> that on day x we are on the long term strategy will save time in this >> >>> case. Our topology is pretty basic today so I think the rick would be >> >>> minimal at this time. >> >> >> >> The time frame is pretty tight for everyone to coordinate bilateral >> >> changes. Esp for the bigger folks. >> >> >> >> What about enabling the new IP addresses on the existing topology and >> >> moving one of the route servers to the new block. Then setting a flag >> >> date to remove the existing IP addresses 2 months out. >> > >> > >> > I'm sorry I've been so under the weather, that I've been behind and >> > haven't started coordinating the renumbering with my co-conspirators. >> > >> > Jay, one problem with a method like that, is that there isn't a >> > central router. Everybody is talking all in the same flat space. If >> > somebody changes to talk on their 206.108.255.0/24 IP address, then >> > those that haven't changed yet won't know how to reach their routes. >> > Thus breaking the exchange apart into those that have adjusted, and >> > those that haven't adjusted. What more, the unconfigured people will >> > see the new routes, but can't reach them. >> > >> There's no reason people can't add the new addresses and migrate >> peering sessions individually, one peer at a time, then remove the >> old addresses once that's complete. >> >> I think two months would be a bit narrow on the time frame, however. >> >> > >> > What follows is the plan I had in my head (but not communicated yet) >> > until I saw the oppertunity to just do it all at once. >> > >> > We communicate everybody's new 206.108.255.0/24 IP & 2001:504:27::/48 >> > address, which almost certainly will just be reusing the same last >> > octet as the current one. >> > >> >> Might I suggest on the IPv6 block 2001:504:27:0::/64 be used for the >> exchange (we can use other parts of the /48 later if needed) and that >> we number as follows: >> 2001:504:27:0:AS:NO:XXXX:YYYY >> >> Where AS:NO is the 32 bit as number and XXXX:YYYY is a number chosen >> by the applicable AS to represent the specific router/port combination. >> (Yes, 32 bits for router/port combinations is overkill, but I can't think of >> a better use for the bits). >> >> > Everybody does a secondary of these IP addresses on their MICE facing >> > interface. This has to be completed by such-and-such date. We'd do >> > spot checks with ping to make sure people have completed this. >> > >> >> I would actually suggest making the existing address "secondary" and >> the new addresses "primary" to reduce future downtime. >> >> > Meanwhile, we build duplicate BGP sessions in the route reflectors for >> > when people are ready to cut. >> > >> >> +1 >> >> > After the such-and-such date, then people are free to cut over their >> > BGP sessions to originate from their new IP, and connect to the new >> > BGP session on the route reflectors. >> > >> >> I think the RS peering sessions can be cut this way, but suggest you >> look over my earlier proposal for managing the peer to peer sessions. >> >> > Finally, there is a drop-dead date when all use of the old IP ranges are done. >> > >> > This way, when somebody cuts onto the new BGP session, the >> > unconfigured old people still have a way to reach the new routes >> > (via. the secondary IP addresses configured on their interface). But >> > their BGP sessions don't change until they want them to. >> > >> >> An excellent solution for the RS peering sessions. >> >> > This way is slow, and requires 100% compliance in getting the >> > interface secondary addresses, and then in the final drop-dead date. >> > >> >> Actually, it doesn't require 100% compliance. People can actually add >> the interface secondaries at their convenience and everything continues >> to work with their old address until they choose to cut over. >> >> > OOTH, if everybody goes down for the switch cut, then people can bring >> > up their session when they want to after the maintenance window, but >> > that also means everybody has to be available to cut their configs >> > over that night/weekend as well if they want to continue to talk on >> > the exchange. >> >> If everyone were only peered with the RS, I'd say this might be a feasible >> approach. However, since they aren't, I'd suggest that we point out the >> switch cut as a "recommended time" to apply the new addressing to their >> interfaces and leave it at that. >> >> Owen >> >> ######################################################################## >> >> 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 > ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Fwd: TTN-0000107640 University of Minnesota 192.35.86.49 BGP Dropped Packets [ ref:_00D6079Qk._500 [ ref:_00D6079Qk._50060KY8z1:ref ]

by Frank DiGravina

/FYI/ F. -------- Original Message -------- Subject: TTN-0000107640 University of Minnesota 192.35.86.49 BGP Dropped Packets [ ref:_00D6079Qk._500 [ ref:_00D6079Qk._50060KY8z1:ref ] Date: Wed, 22 Aug 2012 19:21:40 +0000 (GMT) From: IP Support <ipsupport(a)zayo.com> To: digravin(a)umn.edu <digravin(a)umn.edu> Hello Frank, ZEN had rate-limiter on btb-border76:g1/1.3600 to GigaPop. With that removed, traffic now passing unhindered. If there are any further questions please contact NCC IP Operations, by replying to this email, or calling US 866.236.2824 UK 0-800-169-1646. Thank you, Todd Dresser NCC IP Technician | Zayo Bandwidth 13861 Sunrise Valley Dr. | Suite 450 | Herndon, VA 20171 NCC: 866.236.2824 OPT: 1,3 | O: 571.262.6288 | ncc(a)zayo.com ipsupport(a)zayo.com | http://www.zayo.com ref:_00D6079Qk._50060KY8z1:ref ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Packet loss between GigaPOP and Onvoy/Zayo

by Jay Hanke

On Wed, Aug 22, 2012 at 3:05 PM, Larry Patterson <larry(a)atomicdata.com> wrote: > I attempted to report this issue between Zayo and UMN with BGP paths and > packet loss examples on August 15 to Zayo. But because I am not a > customer if Zayo, their support couldn't do anything with it. I'm glad to > hear that the issues are resolved. That being said, what is the method > for reporting networking issues amongst peering members? Usually directly to the peering contact or via the MICE-DISCUSS list. Zayo isn't currently directly connected to the MICE fabric they connect via the Gigapop. Zayo is in the process of turning up a direct connection. They have assignments but I'm not sure if the x-conn has been ordered yet. Jay ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Packet loss between GigaPOP and Onvoy/Zayo

by Larry Patterson

I attempted to report this issue between Zayo and UMN with BGP paths and packet loss examples on August 15 to Zayo. But because I am not a customer if Zayo, their support couldn't do anything with it. I'm glad to hear that the issues are resolved. That being said, what is the method for reporting networking issues amongst peering members? Thanks, Larry Patterson Chief Technology Officer Atomic Data 615 North 3rd Street Minneapolis, MN 55401 612.466.2000 Main Line 612.466.2080 Direct Dial Twitter <http://twitter.com/AtomicData> | Facebook <http://www.facebook.com/AtomicDataCenters> | LinkedIn <http://www.linkedin.com/companies/atomic-data-centers> Simple. Safe. Smart. www.atomicdata.com <http://www.atomicdata.com/> This message and any information or attachments included therewith is intended only for the individual or entity named above. If the reader is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copy of this message or any information attached or contained therein is strictly prohibited. If you have received this message in error, please notify the sender by return e-mail and destroy all copies of the message and any attachments. Thank you. Please consider the environment before printing this email. On 8/22/12 9:34 AM, "Jeremy Lumby" <jlumby(a)MNVOIP.COM> wrote: >My contact with Onvoy is willing to work it from the other side (looks to >be a Zayo Bandwidth issue) Unfortunately without a case number, or >Circuit ID, he is stuck. > >On a side note, is there anyone I can push to have Zayo turn up their >direct connection to the exchange? > >-----Original Message----- >From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of >Jay Hanke >Sent: Wednesday, August 22, 2012 9:26 AM >To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >Subject: Re: [MICE-DISCUSS] Packet loss between GigaPOP and Onvoy/Zayo > >On Fri, Aug 17, 2012 at 3:17 PM, Mike Bushard, Jr ><mike.bushard(a)arvig.com> wrote: >> I'd have to agree Jeremy. Phil S from 7 Sigma and I have been working >> on a packet loss issue between CTC and Melrose/Benton/Albany for 2-3 >> months. We recently started noticing packet loss between Melrose and >> Perham via Zayo also, but they claim they never find anything on either >>of the complaints. >> Earlier this week I got a call about another location having issues, >> that one looked to be a L3 to TDS issue and not Zayo, but with all >> this I am having second thoughts. > >Any updates on this issue? I got an email to the peering account asking >us to fix our stuff. > >Jay > >######################################################################## > >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 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Justin Krejci

While I agree with the general sentiment that the IP change and switch change will likely be smooth, the IP change can be done more transparently and has literally nothing to do with the L2 gear. To that end, I don't see any reason to not configure/assign the new IP block now and let folks start using it right away, even before the switch switch. On Tue, 2012-08-21 at 15:54 -0700, Owen DeLong wrote: > On Aug 21, 2012, at 14:07 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > > > On Tue, Aug 21, 2012 at 03:54:19PM -0500, Jay Hanke wrote: > >> On Tue, Aug 21, 2012 at 3:46 PM, Mike Bushard, Jr > >> <mike.bushard(a)arvig.com> wrote: > >>> I typically would agree Owen, but in this case it may make sense. Everyone > >>> will be down already, and we won't have multiple outages to the entire > >>> exchange for IP changes. There will be a considerable amount of work if > >>> everyone changes addressing on different schedules. I think just saying > >>> that on day x we are on the long term strategy will save time in this > >>> case. Our topology is pretty basic today so I think the rick would be > >>> minimal at this time. > >> > >> The time frame is pretty tight for everyone to coordinate bilateral > >> changes. Esp for the bigger folks. > >> > >> What about enabling the new IP addresses on the existing topology and > >> moving one of the route servers to the new block. Then setting a flag > >> date to remove the existing IP addresses 2 months out. > > > > > > I'm sorry I've been so under the weather, that I've been behind and > > haven't started coordinating the renumbering with my co-conspirators. > > > > Jay, one problem with a method like that, is that there isn't a > > central router. Everybody is talking all in the same flat space. If > > somebody changes to talk on their 206.108.255.0/24 IP address, then > > those that haven't changed yet won't know how to reach their routes. > > Thus breaking the exchange apart into those that have adjusted, and > > those that haven't adjusted. What more, the unconfigured people will > > see the new routes, but can't reach them. > > > There's no reason people can't add the new addresses and migrate > peering sessions individually, one peer at a time, then remove the > old addresses once that's complete. > > I think two months would be a bit narrow on the time frame, however. > > > > > What follows is the plan I had in my head (but not communicated yet) > > until I saw the oppertunity to just do it all at once. > > > > We communicate everybody's new 206.108.255.0/24 IP & 2001:504:27::/48 > > address, which almost certainly will just be reusing the same last > > octet as the current one. > > > > Might I suggest on the IPv6 block 2001:504:27:0::/64 be used for the > exchange (we can use other parts of the /48 later if needed) and that > we number as follows: > 2001:504:27:0:AS:NO:XXXX:YYYY > > Where AS:NO is the 32 bit as number and XXXX:YYYY is a number chosen > by the applicable AS to represent the specific router/port combination. > (Yes, 32 bits for router/port combinations is overkill, but I can't think of > a better use for the bits). > > > Everybody does a secondary of these IP addresses on their MICE facing > > interface. This has to be completed by such-and-such date. We'd do > > spot checks with ping to make sure people have completed this. > > > > I would actually suggest making the existing address "secondary" and > the new addresses "primary" to reduce future downtime. > > > Meanwhile, we build duplicate BGP sessions in the route reflectors for > > when people are ready to cut. > > > > +1 > > > After the such-and-such date, then people are free to cut over their > > BGP sessions to originate from their new IP, and connect to the new > > BGP session on the route reflectors. > > > > I think the RS peering sessions can be cut this way, but suggest you > look over my earlier proposal for managing the peer to peer sessions. > > > Finally, there is a drop-dead date when all use of the old IP ranges are done. > > > > This way, when somebody cuts onto the new BGP session, the > > unconfigured old people still have a way to reach the new routes > > (via. the secondary IP addresses configured on their interface). But > > their BGP sessions don't change until they want them to. > > > > An excellent solution for the RS peering sessions. > > > This way is slow, and requires 100% compliance in getting the > > interface secondary addresses, and then in the final drop-dead date. > > > > Actually, it doesn't require 100% compliance. People can actually add > the interface secondaries at their convenience and everything continues > to work with their old address until they choose to cut over. > > > OOTH, if everybody goes down for the switch cut, then people can bring > > up their session when they want to after the maintenance window, but > > that also means everybody has to be available to cut their configs > > over that night/weekend as well if they want to continue to talk on > > the exchange. > > If everyone were only peered with the RS, I'd say this might be a feasible > approach. However, since they aren't, I'd suggest that we point out the > switch cut as a "recommended time" to apply the new addressing to their > interfaces and leave it at that. > > Owen > > ######################################################################## > > 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

Aug. 22, 2012

Re: Packet loss issue

by Jeremy Lumby

It looks better to me Jeremy -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank DiGravina Sent: Wednesday, August 22, 2012 2:13 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Packet loss issue Dan, Zayo believes they have fixed the problem. Let me know if you concur. Frank -- Frank DiGravina University of Minnesota Networking & Telecommunications Network Operations Phone: 612-626-9074 Cell: 612-386-0449 E-Mail: digravin(a)umn.edu Helpline: 612-301-HELP ######################################################################## 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

Aug. 22, 2012

Re: Packet loss issue

by Frank DiGravina

Dan, Zayo believes they have fixed the problem. Let me know if you concur. Frank -- Frank DiGravina University of Minnesota Networking & Telecommunications Network Operations Phone: 612-626-9074 Cell: 612-386-0449 E-Mail: digravin(a)umn.edu Helpline: 612-301-HELP ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Packet loss between GigaPOP and Onvoy/Zayo

by Frank DiGravina

On 8/22/12 9:26 AM, Jay Hanke wrote: > On Fri, Aug 17, 2012 at 3:17 PM, Mike Bushard, Jr > <mike.bushard(a)arvig.com> wrote: >> I'd have to agree Jeremy. Phil S from 7 Sigma and I have been working on a >> packet loss issue between CTC and Melrose/Benton/Albany for 2-3 months. We >> recently started noticing packet loss between Melrose and Perham via Zayo >> also, but they claim they never find anything on either of the complaints. >> Earlier this week I got a call about another location having issues, that >> one looked to be a L3 to TDS issue and not Zayo, but with all this I am >> having second thoughts. > Any updates on this issue? I got an email to the peering account > asking us to fix our stuff. > > Jay > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 All, A case was opened the latter part of last week with Zayo Bandwidth upon the observation made by Dan Ruda of the State Of Mn DNR that packets were being lost as they traversed the connection between the Northernlights GigaPOP and Zayo. The case opened with Zayo is 107640. A promised call-back from their noc never happened. I spoke to their noc a few minutes ago and poked at them a bit. Their was no resolution. They promised a call-back in an hour. I will keep you posted as things develop. Frank Frank -- Frank DiGravina University of Minnesota Networking & Telecommunications Network Operations Phone: 612-626-9074 Cell: 612-386-0449 E-Mail: digravin(a)umn.edu Helpline: 612-301-HELP ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Packet loss between GigaPOP and Onvoy/Zayo

by Mike Bushard, Jr

I am working on it from my side since we have a couple issues (on 3 different circuits), but it's a slow road. Mike Bushard, Jr -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jay Hanke Sent: Wednesday, August 22, 2012 9:26 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Packet loss between GigaPOP and Onvoy/Zayo On Fri, Aug 17, 2012 at 3:17 PM, Mike Bushard, Jr <mike.bushard(a)arvig.com> wrote: > I'd have to agree Jeremy. Phil S from 7 Sigma and I have been working > on a packet loss issue between CTC and Melrose/Benton/Albany for 2-3 > months. We recently started noticing packet loss between Melrose and > Perham via Zayo also, but they claim they never find anything on either of the complaints. > Earlier this week I got a call about another location having issues, > that one looked to be a L3 to TDS issue and not Zayo, but with all > this I am having second thoughts. Any updates on this issue? I got an email to the peering account asking us to fix our stuff. Jay ######################################################################## 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

Aug. 22, 2012

Re: Packet loss between GigaPOP and Onvoy/Zayo

by Jeremy Lumby

My contact with Onvoy is willing to work it from the other side (looks to be a Zayo Bandwidth issue) Unfortunately without a case number, or Circuit ID, he is stuck. On a side note, is there anyone I can push to have Zayo turn up their direct connection to the exchange? -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jay Hanke Sent: Wednesday, August 22, 2012 9:26 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Packet loss between GigaPOP and Onvoy/Zayo On Fri, Aug 17, 2012 at 3:17 PM, Mike Bushard, Jr <mike.bushard(a)arvig.com> wrote: > I'd have to agree Jeremy. Phil S from 7 Sigma and I have been working > on a packet loss issue between CTC and Melrose/Benton/Albany for 2-3 > months. We recently started noticing packet loss between Melrose and > Perham via Zayo also, but they claim they never find anything on either of the complaints. > Earlier this week I got a call about another location having issues, > that one looked to be a L3 to TDS issue and not Zayo, but with all > this I am having second thoughts. Any updates on this issue? I got an email to the peering account asking us to fix our stuff. Jay ######################################################################## 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

Aug. 22, 2012

Re: Packet loss between GigaPOP and Onvoy/Zayo

by Jay Hanke

On Fri, Aug 17, 2012 at 3:17 PM, Mike Bushard, Jr <mike.bushard(a)arvig.com> wrote: > I'd have to agree Jeremy. Phil S from 7 Sigma and I have been working on a > packet loss issue between CTC and Melrose/Benton/Albany for 2-3 months. We > recently started noticing packet loss between Melrose and Perham via Zayo > also, but they claim they never find anything on either of the complaints. > Earlier this week I got a call about another location having issues, that > one looked to be a L3 to TDS issue and not Zayo, but with all this I am > having second thoughts. Any updates on this issue? I got an email to the peering account asking us to fix our stuff. Jay ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 22, 2012

Re: Juniper Switch upgrade

by Owen DeLong

On Aug 21, 2012, at 14:07 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > On Tue, Aug 21, 2012 at 03:54:19PM -0500, Jay Hanke wrote: >> On Tue, Aug 21, 2012 at 3:46 PM, Mike Bushard, Jr >> <mike.bushard(a)arvig.com> wrote: >>> I typically would agree Owen, but in this case it may make sense. Everyone >>> will be down already, and we won't have multiple outages to the entire >>> exchange for IP changes. There will be a considerable amount of work if >>> everyone changes addressing on different schedules. I think just saying >>> that on day x we are on the long term strategy will save time in this >>> case. Our topology is pretty basic today so I think the rick would be >>> minimal at this time. >> >> The time frame is pretty tight for everyone to coordinate bilateral >> changes. Esp for the bigger folks. >> >> What about enabling the new IP addresses on the existing topology and >> moving one of the route servers to the new block. Then setting a flag >> date to remove the existing IP addresses 2 months out. > > > I'm sorry I've been so under the weather, that I've been behind and > haven't started coordinating the renumbering with my co-conspirators. > > Jay, one problem with a method like that, is that there isn't a > central router. Everybody is talking all in the same flat space. If > somebody changes to talk on their 206.108.255.0/24 IP address, then > those that haven't changed yet won't know how to reach their routes. > Thus breaking the exchange apart into those that have adjusted, and > those that haven't adjusted. What more, the unconfigured people will > see the new routes, but can't reach them. > There's no reason people can't add the new addresses and migrate peering sessions individually, one peer at a time, then remove the old addresses once that's complete. I think two months would be a bit narrow on the time frame, however. > > What follows is the plan I had in my head (but not communicated yet) > until I saw the oppertunity to just do it all at once. > > We communicate everybody's new 206.108.255.0/24 IP & 2001:504:27::/48 > address, which almost certainly will just be reusing the same last > octet as the current one. > Might I suggest on the IPv6 block 2001:504:27:0::/64 be used for the exchange (we can use other parts of the /48 later if needed) and that we number as follows: 2001:504:27:0:AS:NO:XXXX:YYYY Where AS:NO is the 32 bit as number and XXXX:YYYY is a number chosen by the applicable AS to represent the specific router/port combination. (Yes, 32 bits for router/port combinations is overkill, but I can't think of a better use for the bits). > Everybody does a secondary of these IP addresses on their MICE facing > interface. This has to be completed by such-and-such date. We'd do > spot checks with ping to make sure people have completed this. > I would actually suggest making the existing address "secondary" and the new addresses "primary" to reduce future downtime. > Meanwhile, we build duplicate BGP sessions in the route reflectors for > when people are ready to cut. > +1 > After the such-and-such date, then people are free to cut over their > BGP sessions to originate from their new IP, and connect to the new > BGP session on the route reflectors. > I think the RS peering sessions can be cut this way, but suggest you look over my earlier proposal for managing the peer to peer sessions. > Finally, there is a drop-dead date when all use of the old IP ranges are done. > > This way, when somebody cuts onto the new BGP session, the > unconfigured old people still have a way to reach the new routes > (via. the secondary IP addresses configured on their interface). But > their BGP sessions don't change until they want them to. > An excellent solution for the RS peering sessions. > This way is slow, and requires 100% compliance in getting the > interface secondary addresses, and then in the final drop-dead date. > Actually, it doesn't require 100% compliance. People can actually add the interface secondaries at their convenience and everything continues to work with their old address until they choose to cut over. > OOTH, if everybody goes down for the switch cut, then people can bring > up their session when they want to after the maintenance window, but > that also means everybody has to be available to cut their configs > over that night/weekend as well if they want to continue to talk on > the exchange. If everyone were only peered with the RS, I'd say this might be a feasible approach. However, since they aren't, I'd suggest that we point out the switch cut as a "recommended time" to apply the new addressing to their interfaces and leave it at that. Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Owen DeLong

On Aug 21, 2012, at 14:26 , Jay Hanke <jayhanke(a)mankatonetworks.net> wrote: >> Jay, one problem with a method like that, is that there isn't a >> central router. Everybody is talking all in the same flat space. If >> somebody changes to talk on their 206.108.255.0/24 IP address, then >> those that haven't changed yet won't know how to reach their routes. >> Thus breaking the exchange apart into those that have adjusted, and >> those that haven't adjusted. What more, the unconfigured people will >> see the new routes, but can't reach them. > > I didn't specifically say it but I meant add an additional IP's to > each members interfaces. The next hop should follow the session IP. > Then set up sessions to the route-servers using both blocks. On flag > day we remove the old IP addresses (stick). New entrants would only be > assigned in the new block (carrot). > > If you're not configured yet, you should see two next hops in BGP. One > on the old range and one on the new range with an unreachable next hop > which won't install in the FIB. > > The minor PITA is legacy routers that have definite ideas on what > address is secondary. I don't remember off hand if a BGP session will > survive a move from secondary to primary on an interface in old school > IOS. I think it will drop it and then reestablish causing a little > outage. The current primary could be flipped to secondary when the > switches are down... > It won't, but the smple solution to that problem is to make the old address the secondary one during the address configuration which can, ideally, be done during the switch cut. Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Mike Tindle

As someone who has been through a couple renumberings on other exchanges, I can say it's very easy to let the two IP ranges exist side by side for a good while and allow folks to migrate at their leisure. We've usually been one of the first to configure the new IPs and last to deconfigure old IPs and it's a fairly straightforward process and does not disrupt traffic. The renumbering can be far less intrusive to the operation of the exchange than the switch upgrade. Also to chime in with Owen, making two major changes in the same window means that an issue can be less obvious for trouble shooting in case something does go wrong with a peer or the exchange as a whole. Regards, Mike On Aug 21, 2012, at 2:07 PM, Doug McIntyre wrote: > On Tue, Aug 21, 2012 at 03:54:19PM -0500, Jay Hanke wrote: >> On Tue, Aug 21, 2012 at 3:46 PM, Mike Bushard, Jr >> <mike.bushard(a)arvig.com> wrote: >>> I typically would agree Owen, but in this case it may make sense. Everyone >>> will be down already, and we won't have multiple outages to the entire >>> exchange for IP changes. There will be a considerable amount of work if >>> everyone changes addressing on different schedules. I think just saying >>> that on day x we are on the long term strategy will save time in this >>> case. Our topology is pretty basic today so I think the rick would be >>> minimal at this time. >> >> The time frame is pretty tight for everyone to coordinate bilateral >> changes. Esp for the bigger folks. >> >> What about enabling the new IP addresses on the existing topology and >> moving one of the route servers to the new block. Then setting a flag >> date to remove the existing IP addresses 2 months out. > > > I'm sorry I've been so under the weather, that I've been behind and > haven't started coordinating the renumbering with my co-conspirators. > > Jay, one problem with a method like that, is that there isn't a > central router. Everybody is talking all in the same flat space. If > somebody changes to talk on their 206.108.255.0/24 IP address, then > those that haven't changed yet won't know how to reach their routes. > Thus breaking the exchange apart into those that have adjusted, and > those that haven't adjusted. What more, the unconfigured people will > see the new routes, but can't reach them. > > > What follows is the plan I had in my head (but not communicated yet) > until I saw the oppertunity to just do it all at once. > > We communicate everybody's new 206.108.255.0/24 IP & 2001:504:27::/48 > address, which almost certainly will just be reusing the same last > octet as the current one. > > Everybody does a secondary of these IP addresses on their MICE facing > interface. This has to be completed by such-and-such date. We'd do > spot checks with ping to make sure people have completed this. > > Meanwhile, we build duplicate BGP sessions in the route reflectors for > when people are ready to cut. > > After the such-and-such date, then people are free to cut over their > BGP sessions to originate from their new IP, and connect to the new > BGP session on the route reflectors. > > Finally, there is a drop-dead date when all use of the old IP ranges are done. > > This way, when somebody cuts onto the new BGP session, the > unconfigured old people still have a way to reach the new routes > (via. the secondary IP addresses configured on their interface). But > their BGP sessions don't change until they want them to. > > This way is slow, and requires 100% compliance in getting the > interface secondary addresses, and then in the final drop-dead date. > > OOTH, if everybody goes down for the switch cut, then people can bring > up their session when they want to after the maintenance window, but > that also means everybody has to be available to cut their configs > over that night/weekend as well if they want to continue to talk on > the exchange. > > -- > Doug McIntyre <merlyn(a)iphouse.net> > -- ipHouse/Goldengate/Bitstream/ProNS -- > Network Engineer/Provisioning/Jack of all Trades > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > *----------- H U R R I C A N E - E L E C T R I C ---------->> | Mike Tindle | Senior Network Engineer | mtindle(a)he.net | ASN 6939 | http://www.he.net | 510-580-4126 *---------------------------------------------------->> ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Mike Horwath

On Tue, Aug 21, 2012 at 01:37:43PM -0700, Owen DeLong wrote: > As tempting as it is, I would suggest... NO! > > Multiple changes at the same time are rarely a good idea on critical > infrastructure. You end up not knowing which change broke what when > it comes time to troubleshoot. While overlapping problems are > unlikely in this case, I would say it's still best to do the > renumbering as more of an over-time process. There's no reason to > do renumbering as a flag day. Just one switch, is it really 'critical'? :) (I know, I shouldn't poke the sleeping dragon) -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Jay Hanke

> Jay, one problem with a method like that, is that there isn't a > central router. Everybody is talking all in the same flat space. If > somebody changes to talk on their 206.108.255.0/24 IP address, then > those that haven't changed yet won't know how to reach their routes. > Thus breaking the exchange apart into those that have adjusted, and > those that haven't adjusted. What more, the unconfigured people will > see the new routes, but can't reach them. I didn't specifically say it but I meant add an additional IP's to each members interfaces. The next hop should follow the session IP. Then set up sessions to the route-servers using both blocks. On flag day we remove the old IP addresses (stick). New entrants would only be assigned in the new block (carrot). If you're not configured yet, you should see two next hops in BGP. One on the old range and one on the new range with an unreachable next hop which won't install in the FIB. The minor PITA is legacy routers that have definite ideas on what address is secondary. I don't remember off hand if a BGP session will survive a move from secondary to primary on an interface in old school IOS. I think it will drop it and then reestablish causing a little outage. The current primary could be flipped to secondary when the switches are down... <back to fundraising and contracts/> ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Doug McIntyre

On Tue, Aug 21, 2012 at 03:54:19PM -0500, Jay Hanke wrote: > On Tue, Aug 21, 2012 at 3:46 PM, Mike Bushard, Jr > <mike.bushard(a)arvig.com> wrote: > > I typically would agree Owen, but in this case it may make sense. Everyone > > will be down already, and we won't have multiple outages to the entire > > exchange for IP changes. There will be a considerable amount of work if > > everyone changes addressing on different schedules. I think just saying > > that on day x we are on the long term strategy will save time in this > > case. Our topology is pretty basic today so I think the rick would be > > minimal at this time. > > The time frame is pretty tight for everyone to coordinate bilateral > changes. Esp for the bigger folks. > > What about enabling the new IP addresses on the existing topology and > moving one of the route servers to the new block. Then setting a flag > date to remove the existing IP addresses 2 months out. I'm sorry I've been so under the weather, that I've been behind and haven't started coordinating the renumbering with my co-conspirators. Jay, one problem with a method like that, is that there isn't a central router. Everybody is talking all in the same flat space. If somebody changes to talk on their 206.108.255.0/24 IP address, then those that haven't changed yet won't know how to reach their routes. Thus breaking the exchange apart into those that have adjusted, and those that haven't adjusted. What more, the unconfigured people will see the new routes, but can't reach them. What follows is the plan I had in my head (but not communicated yet) until I saw the oppertunity to just do it all at once. We communicate everybody's new 206.108.255.0/24 IP & 2001:504:27::/48 address, which almost certainly will just be reusing the same last octet as the current one. Everybody does a secondary of these IP addresses on their MICE facing interface. This has to be completed by such-and-such date. We'd do spot checks with ping to make sure people have completed this. Meanwhile, we build duplicate BGP sessions in the route reflectors for when people are ready to cut. After the such-and-such date, then people are free to cut over their BGP sessions to originate from their new IP, and connect to the new BGP session on the route reflectors. Finally, there is a drop-dead date when all use of the old IP ranges are done. This way, when somebody cuts onto the new BGP session, the unconfigured old people still have a way to reach the new routes (via. the secondary IP addresses configured on their interface). But their BGP sessions don't change until they want them to. This way is slow, and requires 100% compliance in getting the interface secondary addresses, and then in the final drop-dead date. OOTH, if everybody goes down for the switch cut, then people can bring up their session when they want to after the maintenance window, but that also means everybody has to be available to cut their configs over that night/weekend as well if they want to continue to talk on the exchange. -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Jay Hanke

On Tue, Aug 21, 2012 at 3:46 PM, Mike Bushard, Jr <mike.bushard(a)arvig.com> wrote: > I typically would agree Owen, but in this case it may make sense. Everyone > will be down already, and we won't have multiple outages to the entire > exchange for IP changes. There will be a considerable amount of work if > everyone changes addressing on different schedules. I think just saying > that on day x we are on the long term strategy will save time in this > case. Our topology is pretty basic today so I think the rick would be > minimal at this time. The time frame is pretty tight for everyone to coordinate bilateral changes. Esp for the bigger folks. What about enabling the new IP addresses on the existing topology and moving one of the route servers to the new block. Then setting a flag date to remove the existing IP addresses 2 months out. Jay ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Hannigan, Martin

That works for me. If we were talking about hundreds of gigs, I might think otherwise, but I expect that this will go relatively smoothly and less complex is better IMHO. Best, -M< On 8/21/12 4:46 PM, "Mike Bushard, Jr" <mike.bushard(a)ARVIG.COM> wrote: > I typically would agree Owen, but in this case it may make sense. Everyone > will be down already, and we won't have multiple outages to the entire > exchange for IP changes. There will be a considerable amount of work if > everyone changes addressing on different schedules. I think just saying > that on day x we are on the long term strategy will save time in this > case. Our topology is pretty basic today so I think the rick would be > minimal at this time. > > > > Mike Bushard, Jr > > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Owen DeLong > Sent: Tuesday, August 21, 2012 3:38 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Juniper Switch upgrade > > As tempting as it is, I would suggest... NO! > > Multiple changes at the same time are rarely a good idea on critical > infrastructure. > You end up not knowing which change broke what when it comes time to > troubleshoot. While overlapping problems are unlikely in this case, I > would say it's still best to do the renumbering as more of an over-time > process. > > There's no reason to do renumbering as a flag day. > > Owen > > On Aug 21, 2012, at 12:28 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > >> On Mon, Aug 20, 2012 at 11:51:10AM -0500, Mike Horwath wrote: >>> On Mon, Aug 20, 2012 at 10:43:43AM -0500, Justin Krejci wrote: >>>> That said any time can be convenient if we have some time to adjust >>>> BGP configs to move traffic away in advance, which during business >>>> hours is typically convenient. >>> >>> A shutdown of the routing daemons on the reflectors should take care >>> of things and no manual BGP configuratin adjustments are needed. >> >> Do we want to maybe do the big renumbering at the same time as this >> switch swapout too? Since things are going to be down, everybody stays >> down until they manually redo their interface and BGP configurations >> after the switch change? >> >> Or do we want to do it more gradually? >> >> -- >> Doug McIntyre <merlyn(a)iphouse.net> >> -- ipHouse/Goldengate/Bitstream/ProNS -- >> Network Engineer/Provisioning/Jack of all Trades >> >> ###################################################################### >> ## >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > ######################################################################## > > 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 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Mike Bushard, Jr

I typically would agree Owen, but in this case it may make sense. Everyone will be down already, and we won't have multiple outages to the entire exchange for IP changes. There will be a considerable amount of work if everyone changes addressing on different schedules. I think just saying that on day x we are on the long term strategy will save time in this case. Our topology is pretty basic today so I think the rick would be minimal at this time. Mike Bushard, Jr -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Owen DeLong Sent: Tuesday, August 21, 2012 3:38 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Juniper Switch upgrade As tempting as it is, I would suggest... NO! Multiple changes at the same time are rarely a good idea on critical infrastructure. You end up not knowing which change broke what when it comes time to troubleshoot. While overlapping problems are unlikely in this case, I would say it's still best to do the renumbering as more of an over-time process. There's no reason to do renumbering as a flag day. Owen On Aug 21, 2012, at 12:28 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > On Mon, Aug 20, 2012 at 11:51:10AM -0500, Mike Horwath wrote: >> On Mon, Aug 20, 2012 at 10:43:43AM -0500, Justin Krejci wrote: >>> That said any time can be convenient if we have some time to adjust >>> BGP configs to move traffic away in advance, which during business >>> hours is typically convenient. >> >> A shutdown of the routing daemons on the reflectors should take care >> of things and no manual BGP configuratin adjustments are needed. > > Do we want to maybe do the big renumbering at the same time as this > switch swapout too? Since things are going to be down, everybody stays > down until they manually redo their interface and BGP configurations > after the switch change? > > Or do we want to do it more gradually? > > -- > Doug McIntyre <merlyn(a)iphouse.net> > -- ipHouse/Goldengate/Bitstream/ProNS -- > Network Engineer/Provisioning/Jack of all Trades > > ###################################################################### > ## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ######################################################################## 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

Aug. 21, 2012

Re: Juniper Switch upgrade

by Owen DeLong

As a follow-on, I'll propose a suggested renumbering process... 1. Provide new addresses to all participants. 2. Each participant adds new addresses to their routers in accordance with their internal maintenance procedures and announces their readiness to cut over peering sessions. 3. Each participant reviews all announcements prior to theirs from the list and takes responsibility for contacting those peers that have previously announced and cutting over their peering sessions on a schedule by mutual agreement. 4. Once more than 50% of participants have announced readiness with the new addresses, a flag day for deprecating the old addresses can be projected and determined by the board, announced on this list. The remaining stragglers have until that flag day to cut over their peering sessions. In this way, there's an incentive to do your cutover as early as possible (then you can sit back and cut over peering sessions as your peers become ready, instead of having to reach out to each and every one of them). Additionally, it provides for cutting peering sessions over in a controlled manner without requiring any downtime and still on a fairly aggressive time table. Thoughts? Owen ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Owen DeLong

As tempting as it is, I would suggest... NO! Multiple changes at the same time are rarely a good idea on critical infrastructure. You end up not knowing which change broke what when it comes time to troubleshoot. While overlapping problems are unlikely in this case, I would say it's still best to do the renumbering as more of an over-time process. There's no reason to do renumbering as a flag day. Owen On Aug 21, 2012, at 12:28 , Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > On Mon, Aug 20, 2012 at 11:51:10AM -0500, Mike Horwath wrote: >> On Mon, Aug 20, 2012 at 10:43:43AM -0500, Justin Krejci wrote: >>> That said any time can be convenient if we have some time to adjust BGP >>> configs to move traffic away in advance, which during business hours is >>> typically convenient. >> >> A shutdown of the routing daemons on the reflectors should take care >> of things and no manual BGP configuratin adjustments are needed. > > Do we want to maybe do the big renumbering at the same time as this > switch swapout too? Since things are going to be down, everybody stays > down until they manually redo their interface and BGP configurations > after the switch change? > > Or do we want to do it more gradually? > > -- > Doug McIntyre <merlyn(a)iphouse.net> > -- ipHouse/Goldengate/Bitstream/ProNS -- > Network Engineer/Provisioning/Jack of all Trades > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Mike Bushard, Jr

May as well get it all over with if we can. Mike Bushard, Jr | Network Engineer IV | *Arvig* | 320.256.7471 Office | 320.256.0178 Direct | 320.429.0837 Mobile ** NEW NUMBER ** | 320-256-7555 Fax [image: Description: Description: http://ipstats.arvig.net/arviglogo.jpeg] *** Please update your address book with my new work email: mike.bushard(a)arvig.com *** *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf Of *Brian Mort *Sent:* Tuesday, August 21, 2012 2:47 PM *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET *Subject:* Re: [MICE-DISCUSS] Juniper Switch upgrade 2nd On Tue, Aug 21, 2012 at 2:46 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: I am in favor of doing it all at once -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Tuesday, August 21, 2012 2:29 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Juniper Switch upgrade On Mon, Aug 20, 2012 at 11:51:10AM -0500, Mike Horwath wrote: > On Mon, Aug 20, 2012 at 10:43:43AM -0500, Justin Krejci wrote: > > That said any time can be convenient if we have some time to adjust > > BGP configs to move traffic away in advance, which during business > > hours is typically convenient. > > A shutdown of the routing daemons on the reflectors should take care > of things and no manual BGP configuratin adjustments are needed. Do we want to maybe do the big renumbering at the same time as this switch swapout too? Since things are going to be down, everybody stays down until they manually redo their interface and BGP configurations after the switch change? Or do we want to do it more gradually? -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 -- Brian Mort Network Engineer IV (ENA,ENS,ECDP) visit our website: arvig <http://www.arvig.com> (218) 346-8231 brian.mort(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

Aug. 21, 2012

Re: Juniper Switch upgrade

by Anthony Anderberg

Doing everything at once certainly does solve a whole bunch of logistical problems, if we all are looking at it at (roughly) the same time we can probably make short work of it. Anthony Anderberg Sr. Systems Analyst 320-234-5239 anthonyanderberg(a)nu-telecom.net -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Tuesday, August 21, 2012 2:29 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Juniper Switch upgrade On Mon, Aug 20, 2012 at 11:51:10AM -0500, Mike Horwath wrote: > On Mon, Aug 20, 2012 at 10:43:43AM -0500, Justin Krejci wrote: > > That said any time can be convenient if we have some time to adjust > > BGP configs to move traffic away in advance, which during business > > hours is typically convenient. > > A shutdown of the routing daemons on the reflectors should take care > of things and no manual BGP configuratin adjustments are needed. Do we want to maybe do the big renumbering at the same time as this switch swapout too? Since things are going to be down, everybody stays down until they manually redo their interface and BGP configurations after the switch change? Or do we want to do it more gradually? -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Brian Mort

2nd On Tue, Aug 21, 2012 at 2:46 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I am in favor of doing it all at once > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Doug McIntyre > Sent: Tuesday, August 21, 2012 2:29 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Juniper Switch upgrade > > On Mon, Aug 20, 2012 at 11:51:10AM -0500, Mike Horwath wrote: > > On Mon, Aug 20, 2012 at 10:43:43AM -0500, Justin Krejci wrote: > > > That said any time can be convenient if we have some time to adjust > > > BGP configs to move traffic away in advance, which during business > > > hours is typically convenient. > > > > A shutdown of the routing daemons on the reflectors should take care > > of things and no manual BGP configuratin adjustments are needed. > > Do we want to maybe do the big renumbering at the same time as this switch > swapout too? Since things are going to be down, everybody stays down until > they manually redo their interface and BGP configurations after the switch > change? > > Or do we want to do it more gradually? > > -- > Doug McIntyre <merlyn(a)iphouse.net> > -- ipHouse/Goldengate/Bitstream/ProNS -- > Network Engineer/Provisioning/Jack of all Trades > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- Brian Mort Network Engineer IV (ENA,ENS,ECDP) visit our website: arvig <http://www.arvig.com> (218) 346-8231 brian.mort(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

Aug. 21, 2012

Re: Juniper Switch upgrade

by Jeremy Lumby

I am in favor of doing it all at once -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Tuesday, August 21, 2012 2:29 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Juniper Switch upgrade On Mon, Aug 20, 2012 at 11:51:10AM -0500, Mike Horwath wrote: > On Mon, Aug 20, 2012 at 10:43:43AM -0500, Justin Krejci wrote: > > That said any time can be convenient if we have some time to adjust > > BGP configs to move traffic away in advance, which during business > > hours is typically convenient. > > A shutdown of the routing daemons on the reflectors should take care > of things and no manual BGP configuratin adjustments are needed. Do we want to maybe do the big renumbering at the same time as this switch swapout too? Since things are going to be down, everybody stays down until they manually redo their interface and BGP configurations after the switch change? Or do we want to do it more gradually? -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: Juniper Switch upgrade

by Doug McIntyre

On Mon, Aug 20, 2012 at 11:51:10AM -0500, Mike Horwath wrote: > On Mon, Aug 20, 2012 at 10:43:43AM -0500, Justin Krejci wrote: > > That said any time can be convenient if we have some time to adjust BGP > > configs to move traffic away in advance, which during business hours is > > typically convenient. > > A shutdown of the routing daemons on the reflectors should take care > of things and no manual BGP configuratin adjustments are needed. Do we want to maybe do the big renumbering at the same time as this switch swapout too? Since things are going to be down, everybody stays down until they manually redo their interface and BGP configurations after the switch change? Or do we want to do it more gradually? -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 21, 2012

Re: MICE Finances 8/15/2012

by Steve Howard

Jay, On 08/15/2012 11:03 PM, Jay Hanke wrote: > As of 8/15/2012: > > Paypal $990.40 > Checking $8100 > Total Cash $9090.40 > > Liabilities: > Accounts Payable $10,015.18 > > Owners Equity: -$924.78 > > We're currently $924.78 from being break even. > CNS will donate $500.00 Paul Bunyan will donate $500.00 That should get us to break even! Thanks, Steve ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 20, 2012

Re: Juniper Switch upgrade

by Mike Horwath

On Mon, Aug 20, 2012 at 10:43:43AM -0500, Justin Krejci wrote: > That said any time can be convenient if we have some time to adjust BGP > configs to move traffic away in advance, which during business hours is > typically convenient. A shutdown of the routing daemons on the reflectors should take care of things and no manual BGP configuratin adjustments are needed. Even in a bi-lateral peering arrangement this shouldn't be needed. > On Mon, 2012-08-20 at 08:19 -0500, Mike Bushard, Jr wrote: > > > Fellow Members, > > > > Anthony and I are looking for input on when to do the switch > > upgrade/change out. We are looking at the 30th of this month for the date > > of the cut. > > > > What are the general thoughts for time? Obviously during the day would be > > nicest for us, but we realize that may create issues for some members so > > we are asking for some input on a time. If your OK with a "Business Hour" > > cut, let us know that also. > > > > Mike Bushard, Jr > > > > ######################################################################## > > > > 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 -- Mike Horwath ipHouse - Welcome home! drechsau(a)iphouse.net The universe is an island, surrounded by whatever it is that surrounds universes. - Berkeley Fortune ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Aug. 20, 2012