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
can't update RADB until the change takes place and ISPs don't run
their update scripts on my timetable. So I see there might be a gap.
...
...
should have been updated. Anyone know of trouble beyond what I have
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
