- mice-discuss - lists.micemn.net

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