Steps And Precautions For Migrating Hong Kong Cn2 Shatin BGB To Shatin Node

1. Preparation and information collection before migration

- Confirm the existing topology: record the current peer IP, subnet, autonomous system number (ASN), routing prefix, physical link interface and MPLS/VPN information. - Confirm with the upstream/new node (Shatin) operator: peer IP, AS, MTU, whether CN2 is supported, whether BFD/MD5 is required, VLAN ID, link type (L2/L3). - Prepare credentials and change window: obtain the peer contact person, maintenance window, fault rollback time point and emergency contact information.

2. Backup and environment verification

- Back up current router/firewall configuration and save to version control (eg: TFTP/SFTP). - Verify whether the configuration template (BGP, ACL, Prefix-list, route-map) can pass syntax verification in the simulation environment in the test environment or non-production period. - Check link health: ping/mtu-check, interface error count, link utilization.

3. Coordinate with Shatin node and apply for resources

- Submit a work order to the Shatin operator, apply for BGP peering, inform your ASN and the prefix to be published; confirm whether any special filtering is required. - Ask for the peer test IP and available VLAN/sub-interface number; confirm whether specific route-map or prefix-limit is required on the peer.

4. Local router configuration template (example: Cisco IOS)

- Basic BGP configuration example: router bgp 65001 neighbor 203.0.113.1 remote-as 65000 neighbor 203.0.113.1 description ShaTin-CN2 neighbor 203.0.113.1 password 7 (if MD5 is required) neighbor 203.0.113.1 ebgp-multihop 2 (if spanning multiple hops) neighbor 203.0.113.1 route-map OUT-TO-SHATIN out neighbor 203.0.113.1 route-map IN-FROM-SHATIN in - Configure prefix filtering: prefix-list MY-PREFIX seq 5 permit 203.0.113.0/24, and use route-map to reject unauthorized prefixes.

5. Dry Run and verification commands before switching

- Do a rehearsal before the maintenance window: simulate the peer in the local lab or on the non-production interface, perform neighbor establishment, and observe the BGP state. - Commonly used verification commands: show ip bgp summary, show ip bgp neighbors 203.0.113.1, show route-map, show ip prefix-list, traceroute -m, confirm AS PATH/next-hop. - Use online/third-party monitoring (BGPlay, BGPView, RIPE/Routeviews) to view route visibility.

6. Actual switching steps (recommended order)

- 1) Notify the peer again and confirm before the maintenance window starts. - 2) Temporarily reduce the BGP egress route priority on the local end or use preference/weight adjustment to gradually guide the traffic to the new link (you can do traffic diversion first). - 3) Add a new peer on the router and activate the peer configuration (add neighbor according to template). - 4) Observe that the BGP state changes to ESTABLISHED and confirm the received route (show ip bgp neighbor). - 5) Deliver your prefix (soft-reconfig outbound or clear ip bgp soft out) and confirm whether the peer has learned it and released it to the outside world. - 6) Gradually switch traffic: Update local LSR/policy routing or BGP weight and switch main traffic to Shatin.

7. Verification and monitoring after switching

- Execute immediately: ping/traceroute to key destinations, mtr to check packet loss and delay. - Check global visibility: Use BGP Looking Glass or routeviews to confirm that your prefix is ​​reachable from multiple locations. - Monitor 24-72 hours: traffic curve, packet loss rate, delay, BGP session stability (up/down events), BFD status (if enabled).

8. Rollback plan and common problem handling

- Rollback preparation: retain the old link configuration and record rollback commands (for example: revoke the new neighbor and restore the old weight/route-policy). - Common problem handling: If BGP cannot be established, check MD5/AS/peer IP/ACL and MTU; if the prefix is ​​not broadcast, check whether prefix-list/route-map is intercepted by mistake; if traffic is abnormal, check next-hop and NAT policies.

9. Follow-up work and optimization after completion of migration

- After confirming that it is stable, confirm with the peer and formally close the old link (if necessary). - Optimization: Enable BFD to shorten fault detection, adjust route-map for traffic engineering, and set community tags for better upstream dissemination. - Documentation: Update network documentation, IP/ASN records, maintenance manuals and change orders.

Q: How long will the migration require?

Answer: Usually, under the conditions of good rehearsal and BGP pre-configuration, the actual switchover time can be controlled within a few minutes to half an hour (mainly depends on route convergence and upstream propagation). It is recommended to reserve 1-2 hours as a maintenance window to deal with unexpected events and perform rollbacks.

Q: If the peer requires MD5 verification or BFD, how to configure it?

Answer: MD5 uses neighbor password on Cisco and peer password cipher on Huawei. BFD needs to be enabled on both sides at the same time and bound under the interface or BGP neighbor. Confirm that the timers of both parties are consistent (such as 50ms/3 times). Before implementation, negotiate parameters with the peer and verify them in the test environment.

Q: How can I confirm that my prefix is reachable on the Internet?

Answer: Use multi-point verification: local traceroute/mtr to confirm the path; visit RIPE/Routeviews/BGP Looking Glass to check whether your prefix is learned by major routers; use third-party monitoring (such as bgp.he.net, bgpview.io) to view global visibility and record AS PATH.