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 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
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???
In my experience, Teleglobe and Level3. But both also had mechanisms to force an update or work around the automated system temporarily.
This is the plan. But this is more verification and repair than proactively mitigating. I imagine it will be a long day Sunday anyway.
In the verification and repair line, iNOC-DBA seems a good tool to have. You could proactively verify your IP Phone is working... :-) Rubens
participants (3)
-
Flint Barber -
matthew zeier -
Rubens Kuhl Jr.