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
> <[log in to unmask]> 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                            <[log in to unmask]>
          -- 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