BGP Network Migration scenario
BGP Network Migration scenario
Given below is a small scenario where ISP_B is acquired by ISP_A, and hence the BGP AS number will change for ISP_B to match with ISP_A. Care will be taken that there is least impact on the Customer connected to ISP_B in terms of outage and reachability.
Initial configuration on ISP_A router
interface Loopback 0 ip address 1.1.1.1 255.255.255.255!interface serial 0/0 ip address 10.1.1.1 255.255.255.252!router bgp 100 neighbor 10.1.1.2 remote-as 200 network 1.1.1.1 mask 255.255.255.255!Initial configuration on ISP_B router
interface Loopback 0 ip address 2.2.2.2 255.255.255.255!interface serial 0/0 ip address 10.1.1.2 255.255.255.252!interface serial 0/1 ip address 10.3.3.1 255.255.255.252!router bgp 200 neighbor 10.1.1.1 remote-as 100 neighbor 10.3.3.2 remote-as 300 network 2.2.2.2 mask 255.255.255.255!Initial configuration on Customer router
interface Loopback 0 ip address 3.3.3.3 255.255.255.255!interface Loopback 1 ip address 4.4.4.4 255.255.255.255!interface Loopback 2 ip address 5.5.5.5 255.255.255.255!interface serial 0/0 ip address 10.3.3.2 255.255.255.252!router bgp 300 neighbor 10.3.3.1 remote-as 200 network 3.3.3.3 mask 255.255.255.255 network 4.4.4.4 mask 255.255.255.255 network 5.5.5.5 mask 255.255.255.255!After initial configuration, the BGP sessions are UP and the routers exchange routing information with each other.
BGP tables on ISP_A, ISP_B and Customer routers
ISP_A# show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 1.1.1.1/32 0.0.0.0 0 32768 i*> 2.2.2.2/32 10.1.1.2 0 0 200 i*> 3.3.3.3/32 10.1.1.2 0 200 300 i*> 4.4.4.4/32 10.1.1.2 0 200 300 i*> 5.5.5.5/32 10.1.1.2 0 200 300 iISP_B# show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 1.1.1.1/32 10.1.1.1 0 0 100 i*> 2.2.2.2/32 0.0.0.0 0 32768 i*> 3.3.3.3/32 10.3.3.2 0 0 300 i*> 4.4.4.4/32 10.3.3.2 0 0 300 i*> 5.5.5.5/32 10.3.3.2 0 0 300 iCustomer# show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 1.1.1.1/32 10.3.3.1 0 200 100 i*> 2.2.2.2/32 10.3.3.1 0 0 200 i*> 3.3.3.3/32 0.0.0.0 0 32768 i*> 4.4.4.4/32 0.0.0.0 0 32768 i*> 5.5.5.5/32 0.0.0.0 0 32768 iNetwork migration of ISP_B:
ISP_B is now acquired by ISP_A and its BGP AS number needs to be changed from 200 to 100, making the BGP session between them an iBGP session. Also, no changes can be made on the Customer router.
Step 1: First step towards migration will be running an IGP (OSPF) between ISP_A and ISP_B so that an iBGP session between Loopback interfaces can be run between them. A configuration like below is implemented on ISP_A and ISP_B routers, making sure no Hello packets are sent on WAN link towards the Customer.
OSPF configuration on ISP_B router
router ospf 1 passive-interface serial 0/1 network 0.0.0.0 255.255.255.255 area 0!Step 2: Once OSPF is enabled between the routers, complete BGP configuration on ISP_B is removed and reconfigured again with new AS number 100. However, no configuration changes are made on the Customer router. This means that the BGP session between ISP_B and the Customer router will never come UP as the Customer router is configured to peer with BGP AS 200 with ISP_B. Hence, a mechanism is required on ISP_B router that disguises its new BGP AS number to the Customer router and continues to use the old BGP AS number that the Customer router is peering with. In comes, BGP Local-AS feature.
BGP Local-AS feature allows a BGP speaking router to impersonate an AS different from the one configured with the router bgp <ASN> command.
Further, the eBGP session between ISP_A and ISP_B is converted into an iBGP session.
Configuration changes on ISP_B
no router bgp 200!router bgp 100 neighbor 1.1.1.1 remote-as 100 neighbor 1.1.1.1 update-source Loopback 0 neighbor 10.3.3.2 remote-as 300 neighbor 10.3.3.2 local-as 200!Configuration changes on ISP_A
router bgp 100 no neighbor 10.1.1.2 remote-as 200 neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 update-source Loopback 0 no network 1.1.1.1 mask 255.255.255.255!Step 3: The Customer router loses all routing information about 1.1.1.1/32 and 2.2.2.2/32 since they are not advertised by BGP network command any more. One possible solution is to redistribute OSPF into BGP, but that will expose all ISP_A routes to the Customer. So a better option is that ISP_B advertise a default-route to the Customer.
Default-route configuration on ISP_B
router bgp 100 neighbor 10.3.3.2 remote-as 300 neighbor 10.3.3.2 local-as 200 neighbor 10.3.3.2 default-originate!BGP tables after migration
ISP_A# show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*>i3.3.3.3/32 10.3.3.2 0 100 0 200 300 i*>i4.4.4.4/32 10.3.3.2 0 100 0 200 300 i*>i5.5.5.5/32 10.3.3.2 0 100 0 200 300 iISP_B# show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 3.3.3.3/32 10.3.3.2 0 0 200 300 i*> 4.4.4.4/32 10.3.3.2 0 0 200 300 i*> 5.5.5.5/32 10.3.3.2 0 0 200 300 iCustomer# show ip bgp | begin Network Network Next Hop Metric LocPrf Weight Path*> 0.0.0.0 10.3.3.1 0 0 200 100 i*> 3.3.3.3/32 0.0.0.0 0 32768 i*> 4.4.4.4/32 0.0.0.0 0 32768 i*> 5.5.5.5/32 0.0.0.0 0 32768 iIt should be noted that ISP_B router prepends AS number 200 to all the updates that it advertises to its BGP neighbors. This can be avoided using neighbor 10.3.3.2 local-as 200 no-prepend command. The no-prepend keyword disables prepending AS 200 to all BGP routes advertised by ISP_B router.
A simple PING to 1.1.1.1/32 from the Customer router validates the reachability.
Customer# ping 1.1.1.1Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 88/103/144 msThis is a temporary solution and proper changes should be made on the ISP_B and the Customer routers.