If you are using an IOS that supports it, you can add the "replace- as" option to the "neighbor x.x.x.x local-as" command, and it will not prepend the AS configured for the routing process, only the one defined via "local-as". If you add the dual-as option, it will allow the EBGP peers to connect to either the AS defined using "local- as" or the routing process AS. IMHO the best option is to change the BGP process ASN to the new AS and use the local-as feature with those options until you can get the EBGP peers to change to the new AS.
Phil On Sep 6, 2007, at 4:26 PM, Andrew Melton wrote: > I have two routers which are IBGP neighbors of each other, and EBGP > neighbors with upstream providers. I need to change the ASN runnig > on the > boxes with the least impact to either the IBGP or EBGP processes. > After > pouring over the config, it seems that there are at least two > options. I am > looking for some advice and best practice guidance, and ultimately, > choosing > a method to make the change. > > The basic config is: > > Existing AS = 36113 > New AS = 25113 > > RTA Config > > <snip> > router bgp 36113 > neighbor 172.16.213.6 remote-as 36113 > neighbor 172.16.213.6 description IBGP Peer > neighbor 172.16.213.6 version 4 > neighbor 4.4.4.4 remote-as 4 > neighbor 4.4.4.4 description EBGP Peer > neighbor 4.4.4.4 version 4 > </snip> > > RTB Config > <snip> > router bgp 36113 > neighbor 172.16.213.5 remote-as 36113 > neighbor 172.16.213.5 description IBGP Peer > neighbor 172.16.213.5 version 4 > neighbor 5.5.5.5 remote-as 5 > neighbor 5.5.5.5 description EBGP Peer > neighbor 5.5.5.5 version 4 > </snip> > > Option 1: My thought is, to either use the 'neighbor x.x.x.x local- > as' and > 'neighbor x.x.x.x remote-as' commands on the IBGP peers to use a > private AS, > i.e. 65213. > For example: > RTA > neighbor 172.16.213.6 remote-as 65213 > neighbor 172.16.213.6 local-as 65213 > RTB > neighbor 172.16.213.6 remote-as 65213 > neighbor 172.16.213.6 local-as 65213 > > This should cause IBGP updates in either direction to append the > private AS > 65213 to the public 36113, making the AS Path 65213 36113. > The EBGP neighbors on each router need 'remove-private-as' to > suppress the > 65213 in the EBGP updates: > RTA > neighbor 4.4.4.4 remove-private-as > RTB > neighbor 5.5.5.5 remove-private-as > > Once this is done, IBGP updates are now from the private AS 65213. > At this > point, as long as the EBGP peer is configured to accept updates > from either > the new public AS 25113 or the old public AS 36113, the routing > process on > RTA can be changed, and the IBGP routes exchanged will continue. > If RTA is > changed before RTB, then the updates in one direction would be > 65213 25113 > and in the other direction would be 65213 36113. > > Once the routing process ID has been changed from 'router bgp > 36113' to > 'router bgp 25113', the private AS config could either be left in > place or > removed. > > > Option 2: Would be to use the same 'neighbor x.x.x.x local-as' > command on > EBGP neighbors, to append the new public AS to the EBGP updates. > Then, the > EBGP AS path would be 25113 36113, whereas the IBGP path would be > 36113. > > This would allow time to coordinate the new AS updates with the EBGP > neighbors. Once the rest of the world is seeing the prefixes > coming from > the new ASN 25113, the routing process ID on each router could be > changed > from 'router bgp 36113' to 'router bgp 25113' and the IBGP > neighbors would > come up with the new ASNs. > > After the IBGP routes have been exchanged with AS path 25113, the > 'neighbor > x.x.x.x local-as 25113' can be removed, and everything will be back to > normal. > > Are there reasons why one of these might not work? Better ideas to > accomplish this? > > Thanks... > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
