[86250] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Changing ASNs - Gotchas??

daemon@ATHENA.MIT.EDU (Flint Barber)
Fri Oct 28 16:23:51 2005

Date: Fri, 28 Oct 2005 14:23:16 -0600
From: "Flint Barber" <flintb@ninesystems.com>
To: <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu


>On Fri, 28 Oct 2005, Flint Barber wrote:

>> 	What are the real gotchas for changing ASNs that people have run

>> into? There is a minor one in terms of route-registry timeliness, I=20
>> can't update RADB until the change takes place and ISPs don't run=20
>> their update scripts on my timetable. So I see there might be a gap.=20
...
...
>> should have been updated. Anyone know of trouble beyond what I have=20
>> mentioned or have a strategy to ensure a successful migration to
mitigate the gotchas??

>Do you have and downstream customer BGP sessions to deal with, or just
transits and peers?
No downstreams fortunately!!!


>What I'd suggest:
>1) verify with each transit provider that they're hearing AND
propagating the prefixes you're announcing to them as you get the
sessions reconfigured.
>2) verify you're receiving the prefixes you should be - should be
pretty much the same as what you were receiving prior to the change
>3) verify what you're announcing appears in the public route servers,
particularly those not located on networks you're directly connected to.
>Also verify those prefixes are originated from the correct AS.
This is the plan. But this is more verification and repair than
proactively mitigating. I imagine it will be a long day Sunday anyway.

>As for the providers who generate filters based off of IRR data, some
of those may have mechanisms to do some sort of a manual filter push to
accommodate >your needs.

Anyone have a list of providers that actively use IRR data for route
control other than for direct peering session control???

>jms

-Flint

home help back first fref pref prev next nref lref last post