Changing the Next-Hop Attribute
As discussed in the section “The Next-Hop Attribute,” earlier in this chapter, it is sometimes necessary (for example, in an NBMA environment) to override a router’s default behavior and force it to advertise itself as the next-hop address for routes sent to a neighbor.
An internal protocol, such as RIP, EIGRP, or OSPF, always uses the source IP address of a routing update as the next-hop address for each network from that update that is placed in the routing table. The neighbor {ip-address | peer-group-name} next-hop-self router configuration command is used to force BGP to use the source IP address of the update as the next hop for each network it advertises to the neighbor, rather than letting the protocol choose the next-hop address to use. This command is described in Table 6-5.
Table 6-5: neighbor next-hop-self Command Description
Open table as spreadsheet | Parameter | Description |
| ip-address | Identifies the peer router to which advertisements will be sent, with this router identified as the next hop |
| peer-group-name | Gives the name of a BGP peer group to which advertisements will be sent, with this router identified as the next hop |
For example, in Figure 6-38, Router B views all routes learned from autonomous system 65100 as having a next hop of 172.16.1.1, which is the entrance to autonomous system 65100 for Router B. When Router B announces those networks to its IBGP neighbors in autonomous system 65101, the BGP default setting is to announce that the next hop to reach each of those networks is the entrance to autonomous system 65100 (172.16.1.1), because BGP is an autonomous system-by-autonomous system routing protocol. With the default settings, a BGP router needs to reach the 172.16.1.1 next hop to reach networks in or behind autonomous system 65100. Therefore, the network that represents 172.16.1.1 will have to be advertised in the internal routing protocol.
In this example, however, the configuration for Router B is as shown in Example 6-9. Router B uses the neighbor next-hop-self command to change the default BGP next-hop settings. After this command is configured, Router B advertises a next hop of 192.168.2.2 (the IP address of its loopback interface) to its IBGP neighbor because that is the source IP address of the routing update to its IBGP neighbor (set with the neighbor update-source command).
Example 6-9: Configuration of Router B in Figure 6-38
router bgp 65101
neighbor 172.16.1.1 remote-as 65100
neighbor 192.168.3.3 remote-as 65101
neighbor 192.168.3.3 update-source loopback0
neighbor 192.168.3.3 next-hop-self
!
router eigrp 1
network 10.0.0.0
network 192.168.2.0
When Router C announces networks that are in or behind autonomous system 65101 to its EBGP neighbors, such as Router D in autonomous system 65102, Router C, by default, uses its outbound interface address 192.168.1.2 as the next-hop address. This address is the default next-hop address for Router D to use to reach any networks in or behind autonomous system 65101.
Defining the Networks That BGP Advertises
Two options are available to advertise networks into BGP: using the network command, and redistributing routes from an IGP into BGP. Redistribution is described in Chapter 4. The network command is described in the next section.
| Note | Redistributing from an IGP into BGP is not recommended because any change in the IGP routes—for example, if a link goes down—might cause a BGP update. This method could result in unstable BGP tables. If redistribution is used, care must be taken that only local routes are redistributed. For example, routes learned from other autonomous systems (that were learned by redistributing BGP into the IGP) must not be sent out again from the IGP; otherwise, routing loops could result. Configuring this filtering can be complex. Using a redistribute command into BGP results in an incomplete origin attribute for the route, as indicated by the ? in the show ip bgp command output. |
Use the network network-number [mask network-mask] [route-map map-tag] router configuration command to permit BGP to advertise a network if it is present in the IP routing table, as described in Table 6-6.
Table 6-6: network Command Description
Open table as spreadsheet | Parameter | Description |
| network-number | Identifies an IP network to be advertised by BGP. |
| mask network-mask | (Optional) Identifies the subnet mask to be advertised by BGP. If the network mask is not specified, the default mask is the classful mask. |
| route-map map-tag | (Optional) Identifies a configured route map. The route map is examined to filter the networks to be advertised. If not specified, all networks are advertised. |
It is important to note that the BGP network command determines which networks this router advertises. This is a different concept from what you are used to when configuring IGPs. Unlike for IGPs, the network command does not start BGP on specific interfaces. Rather, it indicates to BGP which networks it should originate from this router. The mask parameter indicates that BGP-4 can handle subnetting and supernetting. The list of network commands must include all networks in your autonomous system that you want to advertise, not just those locally connected to your router.
The network command allows classless prefixes; the router can advertise individual subnets, networks, or supernets. It is also important to note that the prefix must exactly match (address and mask) an entry in the IP routing table. A static route to null 0 might be used to create a supernet entry in the IP routing table.
| Note | Before Cisco IOS Software Release 12.0, there was a limit of 200 network commands per BGP router. This limit has now been removed. The router’s resources, such as the configured NVRAM or RAM, determine the maximum number of network commands that you can now use. |
Notice the difference between the neighbor command and the network command: The neighbor command tells BGP where to advertise. The network command tells BGP what to advertise.
The sole purpose of the network command is to notify BGP which networks to advertise. If the mask is not specified, this command announces only the classful network number; at least one subnet of the specified major network must be present in the IP routing table to allow BGP to start announcing the classful network as a BGP route. However, if you specify the network-mask, an exact match to the network (both address and mask) must exist in the routing table for the network to be advertised.
Before BGP announces a route, it checks to see whether it can reach it. For example, if you want to advertise the 192.168.0.0/24 that is in your network, and by mistake you configure network 192.168.0.0 mask 255.255.0.0, instead of network 192.168.0.0 mask 255.255.255.0, BGP looks for 192.168.0.0/16 in the routing table. In this case it would find 192.168.0.0/24 but will not find 192.168.0.0/16. Because the routing table does not contain a specific match to the network, BGP does not announce the 192.168.0.0/24 network to any neighbors.
If you want to advertise the CIDR block 192.168.0.0/16, you might try configuring network 192.168.0.0 mask 255.255.0.0. Again, BGP looks for 192.168.0.0/16 in the routing table and if it never finds 192.168.0.0/16, BGP does not announce the 192.168.0.0/16 network to any neighbors. In this case, you can configure a static route to the CIDR block toward the null interface, with the ip route 192.168.0.0 255.255.0.0 null0 command, so that BGP can find an exact match in the routing table. After finding an exact match in the routing table, BGP announces the 192.168.0.0/16 network to its neighbors.
To summarize the relationship between the BGP table, the IP routing table and the network command: The network command allows a BGP router to advertise a network that is in its IP routing table to its neighbors. The neighbor router that receives that network information puts the information in its BGP table and selects its best BGP route for that network. The best route is offered to its IP routing table. BGP neighbors exchange their best BGP routes. Routes learned by IBGP do not have to be in the IP routing table for BGP to use or advertise them (with the default of synchronization disabled).
| Note | The BGP auto-summary router configuration command determines how BGP handles redistributed routes. With BGP summarization enabled (with auto-summary), all redistributed subnets are summarized to their classful boundaries in the BGP table. When disabled (with no auto-summary), all redistributed subnets are present in their original form in the BGP table, so only those subnets would be advertised. In Cisco IOS Software Release 12.2(8)T, the default behavior of the auto-summary command was changed to disabled (no auto-summary); before that the default was enabled (auto-summary). BGP route summarization is covered in Appendix C. |
BGP Neighbor Authentication
As described for EIGRP and OSPF earlier in this book, you can configure BGP neighbor authentication on a router so that the router authenticates the source of each routing update packet that it receives. This is accomplished by the exchange of an authenticating key (sometimes referred to as a password) that is known to both the sending and the receiving router. BGP supports message digest 5 (MD5) neighbor authentication. MD5 sends a “message digest” (also called a “hash”), which is created using the key and a message. The message digest is then sent instead of the key. The key itself is not sent, preventing it from being read by someone eavesdropping on the line while it is being transmitted.
To enable MD5 authentication on a TCP connection between two BGP peers, use the neighbor {ip-address | peer-group-name} password string router configuration command. Table 6-7 describes the neighbor password command parameters.
Table 6-7: neighbor password Command Description
Open table as spreadsheet | Parameter | Description |
| ip-address | IP address of the BGP-speaking neighbor. |
| peer-group-name | Name of a BGP peer group. |
| string | Case-sensitive password of up to 25 characters. The first character cannot be a number. The string can contain any alphanumeric characters, including spaces. You cannot specify a password in the format number-space-anything. The space after the number can cause authentication to fail. |
| Note | If the service password-encryption command is not used when configuring BGP authentication, the password will be stored as plain text in the router configuration. If you configure the service password-encryption command, the password will be stored and displayed in an encrypted form. When it is displayed, there will be an encryption type of 7 specified before the encrypted password. |
When MD5 authentication is configured between two BGP peers, each segment sent on the TCP connection between the peers is verified. MD5 authentication must be configured with the same password on both BGP peers. Otherwise, the connection between them will not be made. Configuring MD5 authentication causes the Cisco IOS Software to generate and check the MD5 digest of every segment sent on the TCP connection.
| Caution | If the authentication string is configured incorrectly, the BGP peering session will not be established. You should enter the authentication string carefully and verify that the peering session is established after authentication has been configured. |
If a router has a password configured for a neighbor, but the neighbor router does not have a password configured, a message such as the following will appear on the console when the routers attempt to send BGP messages between themselves:
Similarly, if the two routers have different passwords configured, a message such as the following will appear on the screen:
If you configure or change the password or key used for MD5 authentication between two BGP peers, the local router will not tear down the existing session after you configure the password. The local router will attempt to maintain the peering session using the new password until the BGP hold-down timer (with a default of 180 seconds) expires. If the password is not entered or changed on the remote router before the hold-down timer expires, the session will time out.
| Note | Configuring a new timer value for the hold-down timer will take effect only after the session has been reset. So, it is not possible to change the configuration of the hold-down timer to avoid resetting the BGP session. |
Examples 6-10 and 6-11 show the configurations for the routers in Figure 6-39. MD5 authentication is configured for the BGP peering session between Routers A and B. The same password must be configured on the remote peer before the hold-down timer expires.
Example 6-10: Configuration of Router A in Figure 6-39
router bgp 65000
neighbor 10.64.0.2 remote-as 65500
neighbor 10.64.0.2 password v61ne0qke1336
Example 6-11: Configuration of Router B in Figure 6-39
router bgp 65500
neighbor 10.64.0.1 remote-as 65000
neighbor 10.64.0.1 password v61ne0qke1336
Configuring BGP Synchronization
Recall that the BGP synchronization rule states that that a BGP router should not use, or advertise to an external neighbor, a route learned by IBGP, unless that route is local or is learned from the IGP.
BGP synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later; it was on by default in earlier Cisco IOS Software releases. With the default of synchronization disabled, BGP can use and advertise to an external BGP neighbor routes learned from an IBGP neighbor that are not present in the local routing table.
Use the synchronization router configuration command to enable BGP synchronization so that a router will not advertise routes in BGP until it learns them in an IGP. The no synchronization router configuration command disables synchronization if it was enabled.
Resetting BGP Sessions
BGP can potentially handle huge volumes of routing information. When a BGP policy configuration change occurs (such as when access lists, timers, or attributes are changed), the router cannot go through the huge table of BGP information and recalculate which entry is no longer valid in the local table. Nor can the router determine which route or routes, already advertised, should be withdrawn from a neighbor. There is an obvious risk that the first configuration change will immediately be followed by a second, which would cause the whole process to start all over again. To avoid such a problem, the Cisco IOS Software applies changes on only those updates received or sent after the BGP policy configuration change has been performed. The new policy, enforced by the new filters, is applied only on routes received or sent after the change.
If the network administrator wants the policy change to be applied on all routes, he or she must trigger an update to force the router to let all routes pass through the new filter. If the filter is applied to outgoing information, the router has to resend the BGP table through the new filter. If the filter is applied to incoming information, the router needs its neighbor to resend its BGP table so that it passes through the new filter.
There are three ways to trigger an update:
-
Hard reset
-
Soft reset
-
Route refresh
The sections that follow detail all three methods of triggering an update.
Hard Reset of BGP Sessions
Resetting a session is a method of informing the neighbor or neighbors of a policy change. If BGP sessions are reset, all information received on those sessions is invalidated and removed from the BGP table. The remote neighbor detects a BGP session down state and, likewise, invalidates the received routes. After a period of 30 to 60 seconds, the BGP sessions are reestablished automatically, and the BGP table is exchanged again, but through the new filters. However, resetting the BGP session disrupts packet forwarding.
Use the clear ip bgp * or clear ip bgp {neighbor-address} privileged EXEC command to cause a hard reset of the BGP neighbors involved, where * indicates all sessions and the neighbor-address identifies the address of a specific neighbor for which the BGP sessions will be reset. A “hard reset” means that the router issuing either of these commands will close the appropriate TCP connections, reestablish those TCP sessions as appropriate, and resend all information to each of the neighbors affected by the particular command that is used.
| Caution | Clearing the BGP table and resetting BGP sessions will disrupt routing, so do not use these commands unless you have to. |
The clear ip bgp * command causes the BGP forwarding table on the router on which this command is issued to be completely deleted; all networks must be relearned from every neighbor. If a router has multiple neighbors, this action is a very dramatic event. This command forces all neighbors to resend their entire tables simultaneously.
For example, assume that Router A has eight neighbors and that each neighbor sends Router A the full Internet table (assume that is about 32 MB in size). If the clear ip bgp * command is issued on Router A, all eight routers resend their 32 MB table at the same time. To hold all of these updates, Router A will need a lot of RAM (possibly 256 MB) and will also need to be able to process all of this information. Processing this many updates will take a considerable number of CPU cycles for Router A, further delaying the routing of user data.
If, instead, the clear ip bgp neighbor-address command is used, one neighbor is reset at a time. The impact is less severe on the router issuing this command. However, it takes longer to change policy to all the neighbors, because each must be done individually rather than all at once as it is with the clear ip bgp * command. The clear ip bgp neighbor-address command still performs a hard reset and must reestablish the TCP session with the specified address used in the command, but this command affects only a single neighbor at a time, not all neighbors simultaneously.
Soft Reset of BGP Sessions Outbound
Use the clear ip bgp {* | neighbor-address} [soft out] privileged EXEC command to cause BGP to do a soft reset for outbound updates. The router on which this command is issued does not reset the BGP session. Instead, the router creates a new update and sends the whole table to the specified neighbors. This update includes withdrawal commands for networks that the neighbor will not see anymore based on the new outbound policy.
| Note | The soft keyword of this command is optional; clear ip bgp out does a soft reset for outbound updates. |
Outbound BGP soft configuration does not have any memory overhead. This command is highly recommended when you are changing an outbound policy, but does not help if you are changing an inbound policy.
Soft Reset of BGP Sessions Inbound
There are two ways to perform an inbound soft reconfiguration: using stored routing update information and dynamically.
Inbound Soft Reset Using Stored Information
To use stored information, first enter the neighbor {ip-address} soft-reconfiguration inbound router configuration command to cause BGP to save all updates that were learned from the neighbor specified. The BGP router retains an unfiltered table of what that neighbor has sent. When the inbound policy is changed, use the clear ip bgp {* | neighbor-address} soft in privileged EXEC command to cause the router to use the stored unfiltered table to generate new inbound updates (in other words, updates from neighbors). The new results are placed in the BGP forwarding database. Therefore, if you make changes, you do not have to force the other side to resend everything.
Route Refresh: Dynamic Inbound Soft Reset
Cisco IOS Software Releases 12.0(2)S and 12.0(6)T introduced a BGP soft reset enhancement feature, also known as route refresh, that provides automatic support for dynamic soft reset of inbound BGP routing table updates that is not dependent on stored routing table update information. This new method requires no preconfiguration (the neighbor soft-reconfiguration inbound command is not required) and requires significantly less memory than the previous soft reset method for inbound routing table updates. The clear ip bgp {* | neighbor-address} [soft in | in] privileged EXEC command is the only command required for this dynamic soft reconfiguration.
The soft in option generates new inbound updates without resetting the BGP session, but it can be memory intensive. BGP does not allow a router to force another BGP speaker to resend its entire table. If you change the inbound BGP policy and you do not want to complete a hard reset, use this command to cause the router to perform a soft reconfiguration.
| Note | To determine whether a BGP router supports this route refresh capability, use the show ip bgp neighbors command. The following message is displayed in the output when the router supports the route refresh capability: Received route refresh capability from peer. |
If all BGP routers support the route refresh capability, use the clear ip bgp {* | address | peer-group-name} in command. You need not use the soft keyword, because soft reset is automatically assumed when the route refresh capability is supported.
| Note | The clear ip bgp soft command performs a soft reconfiguration of both inbound and outbound updates. |
When a BGP session is reset using soft reconfiguration, the following commands can be useful for monitoring the BGP routes received, sent, or filtered, as illustrated in Figure 6-40:
-
show ip bgp neighbors {address} received-routes— Displays all received routes (both accepted and rejected) from the specified neighbor.
-
show ip bgp neighbors {address} routes— Displays all routes that are received and accepted from the specified neighbor. This output is a subset of the output displayed by the received-routes keyword.
-
show ip bgp— Displays entries in the BGP table.
-
show ip bgp neighbors {address} advertised-routes— Displays all BGP routes that have been advertised to neighbors
BGP Configuration Examples
This section provides some configuration examples using the commands discussed.
Basic BGP Examples
Figure 6-41 shows a sample BGP network. Example 6-12 provides the configuration of Router A, and Example 6-13 provides the configuration of Router B.
Example 6-12: Configuration of Router A in Figure 6-41
router bgp 64520
neighbor 10.1.1.1 remote-as 65000
network 172.16.0.0
Example 6-13: Configuration of Router B in Figure 6-41
router bgp 65000
neighbor 10.1.1.2 remote-as 64520
network 172.17.0.0
In this example, Routers A and B define each other as BGP neighbors and start an EBGP session. Router A advertises the network 172.16.0.0/16, and Router B advertises the network 172.17.0.0/16.
Figure 6-42 illustrates another network. The configuration of router R2 is provided in Example 6-14. Router R2 is in autonomous system 65010. The autonomous system used in the neighbor remote-as command is different from the local autonomous system, so the neighbor is an EBGP neighbor and router R2 establishes a TCP session and starts exchanging BGP updates with router R3. Router R2 is configured to advertise two networks to its neighbor. The exact network entries 10.2.2.0/24 and 10.4.4.0/24 must exist in the routing table to be advertised by BGP.
Example 6-14: Configuration of Router R2 in Figure 6-42
router bgp 65010
neighbor 10.1.1.2 remote-as 65020
network 10.2.2.0 mask 255.255.255.0
network 10.4.4.0 mask 255.255.255.0
Peer Group Example
In Figure 6-43, autonomous system 65100 has four routers running IBGP. All of these IBGP neighbors are peering with each others’ loopback 0 interface (the addresses of which are shown in the figure) and are using the IP address of their loopback 0 interface as the source IP address for all BGP packets. Each router is using one of its own IP addresses as the next-hop address for each network advertised through BGP. These are outbound policies.
Example 6-15 shows the BGP configuration of Router C when it is not using a peer group.
Example 6-15: Configuration of Router C in Figure 6-43 Without Using a Peer Group
router bgp 65100
neighbor 192.168.24.1 remote-as 65100
neighbor 192.168.24.1 update-source loopback 0
neighbor 192.168.24.1 next-hop-self
neighbor 192.168.24.1 distribute-list 20 out
neighbor 192.168.25.1 remote-as 65100
neighbor 192.168.25.1 update-source loopback 0
neighbor 192.168.25.1 next-hop-self
neighbor 192.168.25.1 distribute-list 20 out
neighbor 192.168.26.1 remote-as 65100
neighbor 192.168.26.1 update-source loopback 0
neighbor 192.168.26.1 next-hop-self
neighbor 192.168.26.1 distribute-list 20 out
Router C has an outbound distribution list associated with each IBGP neighbor. This outbound filter performs the same function as the distribute-list command you use for internal routing protocols; however, when used for BGP, it is linked to a specific neighbor. For example, the ISP behind Router C might be announcing private address space to Router C, and Router C does not want to pass these networks to other routers running BGP in autonomous system 65100.
To accomplish this, access-list 20, referenced in the distribute-list command, might look like the following:
-
access-list 20 deny 10.0.0.0 0.255.255.255
-
access-list 20 deny 172.16.0.0 0.31.255.255
-
access-list 20 deny 192.168.0.0 0.0.255.255
-
access-list 20 permit any
As shown in Example 6-15, all IBGP neighbors have the outbound distribution list linked to them individually. If Router C receives a change from autonomous system 65101, it must generate an individual update for each IBGP neighbor and run each update against distribute list 20. If Router C has a large number of IBGP neighbors, the processing power needed to inform the IBGP neighbors of the changes in autonomous system 65101 could be extensive.
Example 6-16 shows the configuration of Router C when it is using a peer group called internal. The neighbor remote-as, neighbor update-source, neighbor next-hop-self, and neighbor distribute-list 20 out commands are all linked to peer group internal, which in turn is linked to each of the IBGP neighbors. If Router C receives a change from autonomous system 65101, it creates a single update and processes it through distribute list 20 once. The update is replicated for each neighbor that is part of the internal peer group. This action saves processing time in generating the updates for all IBGP neighbors. Therefore, the use of peer groups can improve efficiency when processing updates for BGP neighbors that have a common outbound BGP policy.
Example 6-16: Configuration of Router C in Figure 6-43 Using a Peer Group
router bgp 65100
neighbor internal peer-group
neighbor internal remote-as 65100
neighbor internal update-source loopback 0
neighbor internal next-hop-self
neighbor internal distribute-list 20 out
neighbor 192.168.24.1 peer-group internal
neighbor 192.168.25.1 peer-group internal
neighbor 192.168.26.1 peer-group internal
Adding a new neighbor with the same policies as the other IBGP neighbors to Router C when it is using a peer group requires adding only a single neighbor statement to link the new neighbor to the peer group. Adding that same neighbor to Router C if it does not use a peer group requires four neighbor statements.
Using a peer group also makes the configuration easier to read and change. If you need to add a new policy, such as a route map, to all IBGP neighbors on Router C, and you are using a peer group, you need only to link the route map to the peer group. If Router C does not use a peer group, you need to add the new policy to each neighbor.
IBGP and EBGP Examples
Figure 6-44 shows another BGP example.
Example 6-17 shows the configuration for Router B in Figure 6-44; note that line numbers have been added to this example to simplify the discussion. The first two commands under the router bgp 65000 command establish that Router B has the following two BGP neighbors:
Example 6-17: Configuration of Router B in Figure 6-44
1. router bgp 65000
2. neighbor 10.1.1.2 remote-as 64520
3. neighbor 192.168.2.2 remote-as 65000
4. neighbor 192.168.2.2 update-source loopback 0
5. neighbor 192.168.2.2 next-hop-self
6. network 172.16.10.0 mask 255.255.255.0
7. network 192.168.1.0
8. network 192.168.3.0
9. no synchronization
From the perspective of Router B, Router A is an EBGP neighbor, and Router C is an IBGP neighbor.
The neighbor statement on Router B for Router A is pointing to the directly connected IP address to reach Router A. However, the neighbor statement on Router B for Router C points to Router C’s loopback interface. Router B has multiple paths to reach Router C. If Router B pointed to the 192.168.3.2 IP address of Router C and that interface went down, Router B would be unable to reestablish the BGP session until the link came back up. By pointing to the loopback interface of Router C, the link stays established as long as any path to Router C is available. (Router C should also point to Router B’s loopback address in its configuration, and both Routers B and C will need a static or IGP route to each other’s loopback interface.)
Line 4 in the configuration forces Router B to use its loopback 0 address, 192.168.2.1, as the source IP address when sending an update to Router C, 192.168.2.2.
In line 5, the next-hop address for networks that can be reached through Router B is changed from its default of 10.1.1.1 with the neighbor next-hop-self command. This command sets the next-hop address to the source IP address of the routing update, which is Router B’s loopback 0 address, as set by the neighbor update-source command.
Lines 6, 7, and 8 tell BGP which networks to advertise. Line 6 contains a subnet of a Class B address using the mask option. Lines 7 and 8 contain two network statements for the two Class C networks that connect Routers B and C. The default mask for these networks is 255.255.255.0, so it is not needed in the commands.
In line 9, synchronization is disabled (this command is not needed if the router is running Cisco IOS Software Release 12.2(8)T or later, because then synchronization is off by default). If Router A is advertising 172.20.0.0 in BGP, Router B receives that route and advertises it to Router C. In this network, synchronization can be off because all the routers within the transit path in autonomous system are running IBGP.
Figure 6-45 illustrates another example BGP network in which two CPE routers are connected to ISP PE routers, in two different ISPs. EBGP is configured between both sets of CPE and PE. To provide reliable connectivity to both ISPs, the CPE routers must exchange BGP routes. Therefore, an IBGP session must be configured between the two CPE routers.
Example 6-18 provides the partial configuration of one of the CPE routers, R3. The EBGP neighbor relationship to router R5 and IBGP neighborship to router R6 is configured. Two network commands are used to advertise two networks. Because network 172.16.0.0 is not directly connected, a static route to null0 interface is configured so that network 172.16.0.0 can be advertised into BGP.
Example 6-18: Configuration of Router R3 in Figure 6-45
router bgp 65010
neighbor 10.7.7.2 remote-as 65010
neighbor 10.1.1.2 remote-as 65020
network 10.2.2.0 mask 255.255.255.0
network 172.16.0.0 mask 255.255.0.0
0 comments
Post a Comment