Information Technology Reference
In-Depth Information
Example 8-24 shows the final BGP configurations on R3.
Example 8-24
Final BGP Configurations on R3
router bgp 100
no synchronization
bgp router-id 192.168.100.3
bgp log-neighbor-changes
network 192.168.200.0
neighbor Internal peer-group
neighbor Internal remote-as 100
neighbor Internal update-source Loopback0
neighbor 192.168.100.1 peer-group Internal
neighbor 192.168.100.2 peer-group Internal
no auto-summary
Case Study 2: iBGP Full Mesh to Confederation
Migration
This case study presents detailed procedures on how to migrate an iBGP fully meshed net-
work into a confederation-based architecture. The starting topology before the migration is
shown in Figure 8-1, and the final topology is shown in Figure 8-3. The same IGP (IS-IS)
is used across the entire confederation. If different IGPs or IGP instances are used in differ-
ent member autonomous systems, the IGP needs to be migrated as well. The IGP migration
is outside the scope of this chapter.
Starting Configurations and RIBs
Because this case study uses the same starting topology that is used in Case Study 1, there
are no changes to the basic configurations and RIBs that were presented in Case Study 1.
Migration Procedures
Because of significant architectural differences between the BGP confederation and fully
meshed iBGP, expect disruption to the existing network. The goal of these procedures is to
minimize the disruption while migrating to the new architecture.
The procedures described in this section take advantage of the feature that the BGP confed-
eration ID can be the same as its member AS number. When the first router is migrated into
a new member AS, the entire AS 100 should be changed to a confederation. This in effect
changes the original AS 100 into a confederation 100 with two member autonomous sys-
tems—one of which is 100. The remaining procedures migrate routers from member AS
100 to the appropriate member autonomous systems.
