You Are Here: Home » Router » -Router Cisco » BGP Network Migration scenario

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 i

ISP_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 i

Customer# 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 i

Network 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-ASfeature.

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 i

ISP_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 i

Customer# 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 i

It 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 usingneighbor 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.1

Type 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 ms

This is a temporary solution and proper changes should be made on the ISP_B and the Customer routers.

About The Author

harrychanputra.web.id

Number of Entries : 295

Leave a Comment

© 2011 Powered By Wordpress, Goodnews Theme By Geeks Docuementation

Scroll to top