ASN - Migration 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. If someone knows a strategy there, I would be most appreciative. Beyond that, what extended trouble have engineers seen from remote networks? As background, I am changing an ASN at one location that has 5 ISP peers( all ranked in the top 20) connected to it over the weekend. I have made all of the arrangements with those ISPs the best I can, but am concerned some about propagation beyond them. The ASN was assigned about 60 days ago by ARIN and I have added it to RADB so most filters 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?? -Flint
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. If someone knows a strategy there, I would be most appreciative. Beyond that, what extended trouble have engineers seen from remote networks? As background, I am changing an ASN at one location that has 5 ISP peers( all ranked in the top 20) connected to it over the weekend. I have made all of the arrangements with those ISPs the best I can, but am concerned some about propagation beyond them. The ASN was assigned about 60 days ago by ARIN and I have added it to RADB so most filters 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? There really isn't a nice, auto-magic way to guarantee that everything is OK after a change like this. The best you can do immediately is establish a reasonable level of confidence. 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. You may run into places with isolated reachability issues if the remote site does very aggressive BGP flap damping, but those will correct themselves over time. As long as 'the world' sees what you announce and vice versa, you should be in good shape. 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. jms
participants (2)
-
Flint Barber
-
Justin M. Streiner