Hi,
You didn't say if you own your current prefixes and will advertise both the old and new prefixes (until you migrate). You also didn't say how many peers do you have, so i assumed there are 2 peers.
You could try this:
1. create an aggregate route which you'd like to advertise to you peers;
2. create a policy which will advertise this aggregate (and your current prefixes if there is such need; if you're going to advertise these prefixes, perhaps it's wise to prepend the as-path (output policy) and lower local-pref (input policy) to make the reconfigured session less preferred just in case);
2a. Connect the newly created policy to output of the reconfigured session;
2b. Commit your configuration; even if your neighbor rejects the new aggregate it's not so important now, cause the only reason for commiting here is to switch traffic to the alternate path;
3. reconfigure bgp for one peering using 'local-as' statement, so that there is no need for global 'autonomous-system' change;
4. after the session becomes operational, check whether the aggregate (and rest of prefixes) is being advertised: '> show route advertising-protocol bgp IP_OF_THE_PEER'
5. check using looking glass of you provider, how your prefixes looks like in it's bgp table (especially important for those which you use right now); if you feel fine about that, you could try to remove as-path prepending and local-pref lowering from reconfigured session; the traffic should switch to this new session.
If you provide more details such as
a) how many peers do you have?
b) are you allowed to advertise your current prefixes using new ASN? if not, are you allowed to transit your current prefixes via your new ASN?
we could find much fitting solution.
Have a nice day,
G.
Message Edited by Gniewko on 06-03-2008 09:46 AM