Information Technology Reference
In-Depth Information
Example 8-29 shows the modified BGP configurations on R1. This case study chooses to
make R8's address reachable via the IGP, so the BGP next hop is not reset for the session
between R1 and R4, and
next-hop-self
is removed from the Internal peer group. The danger
of resetting the next hop to R1 for this session is demonstrated later in this case study.
Similar configuration changes are made to R2 (not shown). Note that the iBGP sessions
with R6 and R7 are still up and will be removed in a later step. After the sessions are up,
R4 learns all the prefixes from R1 and R2.
Example 8-29
BGP Configuration Changes on R1
router bgp 100
no synchronization
bgp router-id 192.168.100.1
bgp log-neighbor-changes
bgp confederation identifier 100
bgp confederation peers 65001
neighbor Internal peer-group
neighbor Internal remote-as 100
neighbor Internal update-source Loopback0
neighbor 192.168.14.4 remote-as 65001
neighbor 192.168.18.8 remote-as 200
neighbor 192.168.100.2 peer-group Internal
neighbor 192.168.100.3 peer-group Internal
neighbor 192.168.100.5 peer-group Internal
neighbor 192.168.100.6 peer-group Internal
neighbor 192.168.100.7 peer-group Internal
no auto-summary
In the configurations, a shaded line indicates that the line has been modified or added.
NOTE
Figure 8-4 shows the current network topology. Although R4's configuration is complete,
it is not yet in the forwarding paths (shown isolated in Figure 8-4). Within sub-AS 100, all
routers are still fully meshed. Before proceeding to Step 5, verify that all the prefixes are
still being received correctly on all the other routers.
