Adding iBGP Routes to the IP Routing Table

Cisco IOS has the same two requirements for adding iBGP routes to the IP routing table as it does for eBGP routes:

■ The route must be the best BGP route.

■ The route must be the best route (according to the AD) in comparison with other routing sources.

Additionally, for iBGP-learned routes, IOS considers the concept of BGP synchronization.

With BGP synchronization (often called sync) disabled using the no synchronization command, BGP uses the same logic for iBGP routes as it does for eBGP routes regarding which routes to add to the IP routing table. However, enabling BGP sync (with the synchronization BGP subcommand) prevents a couple of problems related to IP routing. Figure 12-7 shows the details of just such a problem. In this case, sync was inappropriately disabled in ASN 678, creating a black hole.

Figure 12-7 Problem: Routing Black Hole Due to Not Using BGP Sync

ASN 123

Figure 12-7 Problem: Routing Black Hole Due to Not Using BGP Sync

ASN 123

A

Black Hole

B

Misleading Update

The following list takes a sequential view of what occurs within BGP in Figure 12-7:

1. R5 adds two prefixes (21.0.0.0/8 and 22.2.2.0/24) into its BGP table using two network commands.

2. R5 advertises the prefixes to R7, but does not redistribute the routes into its IGP.

3. R7 advertises the prefixes to R6.

4. R6, with synchronization disabled, considers the routes as "best," so R6 adds the routes to its routing table.

5. R6 also advertises the two prefixes to R1.

Two related problems (labeled A and B in the figure) actually occur in this case. The routing black hole occurs because R8 does not have a route to either of the prefixes advertised by BGP. R8 is not running BGP—a common occurrence for a router that does not directly connect to an eBGP peer. R7 did not redistribute those two prefixes into the IGP; as a result, R8 cannot route packets for those prefixes. R6, and possibly routers in AS 123, try to forward packets destined to the two prefixes through AS 678, but R8 discards the packets—hence the black hole.

The second related problem, labeled B, occurs at Step 5. R6 exacerbated the routing black-hole problem by advertising to another AS (AS 123) that it could reach the prefixes. R6 considers its routes to 21.0.0.0/8 and 22.2.2.0/24 as "best" routes in its BGP table, so R6 then advertises those routes to R1. Depending on the topology and PA settings, R1 could have considered these routes as its best routes—thereby sending packets destined for those prefixes into AS 678. (Assuming the configuration as shown in the previous examples, R1 would actually believe the 1 AS_PATH through R3 to AS 45 as the best path.)

The solutions to these problems are varied, but all the solutions result in the internal routers (for example, R8) learning the routes to these prefixes, thereby removing the black hole and removing the negative effect of advertising the route. The original solution to this problem involves the use of BGP synchronization, along with redistributing BGP routes into the IGP. However, two later solutions provide better options today:

■ BGP route reflectors

■ BGP confederations

The next several sections cover all of these options.

Using Sync and Redistributing Routes

BGP synchronization is best understood when considered in the context in which it was intended to be used—namely, in conjunction with the redistribution of BGP routes into the IGP. This method is seldom used by ISPs today, mainly because of the large number of routes that would be injected into the IGP. However, using BGP sync in conjunction with redistribution solves both problems related to the routing black hole.

KEY The key to understanding BGP sync is to know that redistribution solves the routing black-hole POINT problem, and sync solves the problem of advertising a black-hole route to another AS. For example, to solve the routing black-hole problem, R7 redistributes the two prefixes into RIP (from Figure 12-7). R8 then has routes to those prefixes, solving the black-hole problem.

Sync logic on R6 controls the second part of the overall problem, regulating the conditions under which R6 advertises the prefixes to other eBGP peers (like R1). Sync works by controlling whether a BGP table entry can be considered "best"; keep in mind that a route in the BGP table must be considered to be "best" before it can be advertised to another BGP peer. The BGP sync logic controls that decision as follows:

KEY Do not consider an iBGP route in the BGP table as "best" unless the exact po|NT prefix was learned via an IGP and is currently in the routing table.

Sync logic essentially gives a router a method to know whether the non-BGP routers inside the AS should have the ability to route packets to the prefix. Note that the route must be IGP-learned because a static route on R6 would not imply anything about what other routers (like R8) might or might not have learned. For example, using Figure 12-7 again, once R6 learns the prefixes via RIP, RIP will place the routes in its IP routing table. At that point, the sync logic on R6 can consider those same BGP-learned prefixes in the BGP table as candidates to be best routes. If chosen as best, R6 can then advertise the BGP routes to R1.

Example 12-13 shows the black hole occurring from R6's perspective, with sync disabled on R6 using the no synchronization BGP subcommand. Following that, the example shows R6's behavior once R7 has begun redistributing BGP routes into RIP, with sync enabled on R6.

Example 12-13 Comparing the Black Hole (No Sync) and Solution (Sync)

! R6 has a "best" BGP route to 21.0.0.0/8 through R7 (7.7.7.7), but a trace ! command shows that the packets are discarded by R8 (10.1.68.8). R6# show ip bgp | begin Network

Type escape sequence to abort. Tracing the route to 21.1.1.5

Next Hop

172.16.16.1

172.16.16.1

Metric LocPrf Weight Path

0 123 45 i

1 10.1.68.8 20 msec 20 msec 20 msec

! R7 is now configured to redistribute BGP into RIP. R7# conf t

Enter configuration commands, one per line. End with CNTL/Z. R7(config)# router rip

R7(config-router)# redist bgp 678 metric 3

! Next, R6 switches to use sync, and the BGP process is cleared.

R6# conf t

Enter configuration commands, one per line. End with CNTL/Z.

R6(config)# router bgp 678

R6(config-router)# synchronization

R6(config-router)#

Example 12-13 Comparing the Black Hole (No Sync) and Solution (Sync) (Continued)

! R6's BGP table entries now show "RIB-failure," a status code that can mean ! (as of some 12.2T IOS releases) that the prefix is known via an IGP. 21.0.0.0/8 ! is shown to be included as a RIP route in R6's routing table. Note also that R6 ! considers the BGP routes through R7 as the "best" routes; these are still ! advertised to R1. R6# show ip bgp

BGP table version is 5, local router ID is 6.6.6.6

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete

R6# show ip route

Next Hop

172.16.16.1

172.16.16.1

Metric LocPrf Weight Path

0 123 45

R 21.0.0.0/8 [120/4] via 10.1.68.8, 00:00:15, Serial0/0.8 ! R6 considers the routes through R7 as the "best" routes; these are still ! advertised to R1, even though they are in a "RIB-failure" state. R6# show ip bgp neighbor 172.16.16.1 advertised-routes | begin Network

Network Next Hop Metric LocPrf Weight Path r>i21.0.0.0 7.7.7.7 0 100 0 45 i r>i22.2.2.0/24 7.7.7.7 0 100 0 45 i

NOTE Sync includes an additional odd requirement when OSPF is used as the IGP. If the OSPF RID of the router advertising the prefix is a different number than the BGP router advertising that same prefix, then sync still does not allow BGP to consider the route to be the best route. OSPF and BGP use the same priorities and logic to choose their RIDs; however, when using sync, it makes sense to explicitly configure the RID for OSPF and BGP to be the same value on the router that redistributes from BGP into OSPF.

Disabling Sync and Using BGP on All Routers in an AS

A second method to overcome the black-hole issue is to simply use BGP to advertise all the BGP-learned prefixes to all routers in the AS. Because all routers know the prefixes, sync can be disabled safely. The downside is the introduction of BGP onto all routers, and the addition of iBGP neighbor connections between each pair of routers. (In an AS with N routers, N(N-1)/2 neighbor connections will be required.) With large autonomous systems, BGP performance and convergence time can degrade as a result of the large number of peers.

BGP needs the full mesh of iBGP peers inside an AS because BGP does not advertise iBGP routes (routes learned from one iBGP peer) to another iBGP peer. This additional restriction helps prevent routing loops, but it then requires a full mesh of iBGP peers—otherwise, only a subset of the iBGP peers would learn each prefix.

BGP offers two tools (confederations and route reflectors) that reduce the number of peer connections inside an AS, prevent loops, and allow all routers to learn about all prefixes. These two tools are covered next.

Confederations

An AS using BGP confederations, as defined in RFC 3065, separates each router in the AS into one of several confederation sub-autonomous systems (sub-autonomous systems). Peers inside the same sub-AS are considered to be confederation iBGP peers, and routers in different sub-autonomous systems are considered to be confederation eBGP peers.

Confederations propagate routes to all routers, without a full mesh of peers inside the entire AS. To do so, confederation eBGP peer connections act like true eBGP peers in some respects. In a single sub-AS, the confederation iBGP peers must be fully meshed, because they act exactly like normal iBGP peers—in other words, they do not advertise iBGP routes to each other. However, confederation eBGP peers act like eBGP peers in that they can advertise iBGP routes learned inside their confederation sub-AS into another confederation sub-AS.

Confederations prevent loops inside a confederation AS by using the AS_PATH PA. BGP routers in a confederation add the sub-autonomous systems into the AS_PATH as part of an AS_PATH segment called the AS_CONFED _SEQ. (The AS_PATH consists of up to four different components, called segments—AS_SEQ, AS_SET, AS_CONFED_ SEQ, and AS_CONFED_SET; see the earlier section titled "Manual Summaries and the AS_PATH Path Attribute" for more information on AS_SEQ and AS_SET.)

NOTE The terms AS and sub-AS refer to the concept of an autonomous system and sub-autonomous system. ASN and sub-ASN refer to the actual AS numbers used.

Just as the AS_SEQ and AS_SET components help prevent loops between autonomous systems, AS_CONFED_SEQ and AS_CONFED_SET help prevent loops within confederation autonomous systems. Before confederation eBGP peers can advertise an iBGP route into another sub-AS, the router must make sure the destination sub-AS is not already in the AS_PATH AS_CONFED_SEQ segment. For example, in Figure 12-8, the routers in sub-ASN 65001 learn some routes and then advertise those routes to sub-ASNs 65002 and 65003. Routers in these two sub-ASNs advertise the routes to each other. However, they never re-advertise the routes back to routers in sub-ASN 65001 due to AS_CONFED_SEQ, as shown in parentheses inside the figure.

Figure 12-8 AS PATH Changes in a Confederation

ASN 123

ASN 123

Figure 12-8 depicts a detailed example, with the steps in the following list matching the steps outlined in circled numbers in the figure:

Figure 12-8 depicts a detailed example, with the steps in the following list matching the steps outlined in circled numbers in the figure:

1. 21.0.0.0/8 is injected by R45 and advertised via eBGP to AS 123. This route has an AS_PATH of 45.

2. R3 advertises the prefix via its two iBGP connections; however, due to iBGP rules inside the sub-AS, R1 and R2 do not attempt to advertise this prefix to each other.

3. Routers in sub-AS 65001 use eBGP-like logic to advertise 21.0.0.0/8 to their confederation eBGP peers, but first they inject their own sub-AS into the AS_PATH AS_CONFED_SEQ segment. (This part of the AS_PATH is displayed inside parentheses in the output of the show ip bgp command, as shown in the figure.)

4. The same process as in Step 2 occurs in the other two sub-autonomous systems, respectively.

5. R6 and R9 advertise the route to each other after adding their respective ASNs to the AS_CONFED_SEQ.

6. R9 advertises the prefix via a true eBGP connection after removing the sub-AS portion of the AS PATH.

By the end of these steps, all the routers inside ASN 123 have learned of the 21.0.0.0/8 prefix. Also, ASN 678 (R77 in this case) learned of a route for that same prefix—a route that would work and would not have the black-hole effect. In fact, from ASN 678's perspective, it sees a route that appears to be through ASNs 123 and 45. Also note that routers in sub-AS 65002 and 65003 will not advertise the prefix back into sub-AS 65001 because AS 65001 is already in the confederation AS_PATH.

The choice of values for sub-ASNs 65001, 65002, and 65003 is not coincidental in this case. ASNs 64512 through 65535 are private ASNs, meant for use in cases where the ASN will not be advertised to the Internet or other autonomous systems. By using private ASNs, a confederation can hopefully avoid the following type of problem. Imagine that sub-AS 65003 instead used ASN 45. The AS_PATH loop check examines the entire AS_PATH. As a result, the prefixes shown in Figure 12-8 would never be advertised to sub-AS 45, and in turn would not be advertised to ASN 678. Using private ASNs would prevent this problem.

KEY POINT

The following list summarizes the key points regarding confederations:

■ Inside a sub-AS, full mesh is required, because full iBGP rules are in effect.

■ The confederation eBGP connections act like normal eBGP connections in that iBGP routes are advertised—as long as the AS_PATH implies that such an advertisement would not cause a loop.

■ Confederation eBGP connections also act like normal eBGP connections regarding Time to Live (TTL), because all packets use a TTL of 1 by default. (TTL can be changed with the neighbor ebgp-multihop command.)

■ Confederation eBGP connections act like iBGP connections in every other regard—for example, the NEXT_HOP is not changed by default.

■ Confederation ASNs are not considered part of the length of the AS_PATH when a router chooses the best routes based on the shortest AS_PATH. (See Chapter 13 for more details on the BGP decision process.)

■ Confederation routers remove the confederation ASNs from the AS_PATH in Updates sent outside the confederation; therefore, other routers do not know that a confederation was used.

Configuring Confederations

Configuring confederations requires only a few additional commands beyond those already covered in this chapter. However, migrating to use confederations can be quite painful. The problem is that the true ASN will no longer be configured on the router bgp command, but instead on the bgp confederation identifier BGP subcommand. So, BGP will simply be out of service on one or more routers while the migration occurs. Table 12-10 lists the key confederation commands, and their purpose.

Table 12-10 BGP Subcommands Used for Confederations

Purpose

Command

Define a router's sub-AS

router bgp sub-as

Define the true AS

bgp confederation identifier asn

To identify a neighboring AS as another sub-AS

bgp confederation peers sub-asn

Example 12-14 shows a simple configuration for the topology in Figure 12-9.

Figure 12-9 Internetwork Topology with Confederations in ASN123

Confederation:

Figure 12-9 Internetwork Topology with Confederations in ASN123

In this internetwork topology, R1 is in sub-AS 65001, with R2 and R3 in sub-AS 65023. In this case, R1 and R3 will not be neighbors. The following list outlines the sequence of events to propagate a prefix:

1. R3 will learn prefix 21.0.0.0/8 via eBGP from AS 45 (R4).

2. R3 will advertise the prefix via iBGP to R2.

3. R2 will advertise the prefix via confederation eBGP to R1.

Example 12-14 Confederation Inside AS 123

! R1 Configuration. Note the sub-AS in the router bgp command, and the true AS in ! the bgp confederation identifier command. Also note the neighbor ebgp-multihop

! command for confederation eBGP peer R2, as they are using loopbacks. Also, sync

Example 12-14 Confederation Inside AS 123 (Continued)

! is not needed now that the confederation has been created, router bgp 65001 no synchronization bgp router-id 111.111.111.111 bgp confederation identifier 123 bgp confederation peers 65023 neighbor 2.2.2.2 remote-as 65023 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback1 neighbor 2.2.2.2 next-hop-self neighbor 172.16.16.6 remote-as 678

! R2 Configuration. Note the bgp confederation peers 65023 command. Without it, ! R2 would think that neighbor 1.1.1.1 was a true eBGP connection, and remove ! the confederation AS_PATH entries before advertising to R1. router bgp 65023 no synchronization bgp confederation identifier 123 bgp confederation peers 65001 neighbor 1.1.1.1 remote-as 65001 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback1 neighbor 3.3.3.3 remote-as 65023 neighbor 3.3.3.3 update-source Loopback1

! R3 Configuration. Note that R3 does not need a bgp confederation peers command, ! as it does not have any confederation eBGP peers, router bgp 65023 no synchronization bgp log-neighbor-changes bgp confederation identifier 123 neighbor 2.2.2.2 remote-as 65023 neighbor 2.2.2.2 update-source Loopback1 neighbor 2.2.2.2 next-hop-self neighbor 4.4.4.4 remote-as 45 neighbor 4.4.4.4 ebgp-multihop 2 neighbor 4.4.4.4 update-source Loopback1

! R1 has received the 21.0.0.0/8 prefix, with sub-AS 65023 shown in parentheses, ! and true AS 45 shown outside the parentheses. R1 has also learned the same ! prefix via AS 678 and R6. The route through the sub-AS is best because it is the ! shortest AS_PATH; the shortest AS_PATH logic ignores the confederation sub-autonmous systems. R1# show ip bgp | begin Network

Network Next Hop Metric LocPrf Weight Path

172.16.16.6

172.16.16.6

0 100

Example 12-14 Confederation Inside AS 123 (Continued)

! R6 shows its received update from R1, showing the removed sub-AS, and the ! inclusion of the true AS, AS 123.

R6# show ip bgp neighbor 172.16.16.1 received-routes | begin Network

Network Next Hop Metric LocPrf Weight Path r 21.0.0.0 172.16.16.1 0 123 45 i r 22.2.2.0/24 172.16.16.1 0 123 45 i

Route Reflectors

Route reflectors (RRs) achieve the same result as confederations—they remove the need for a full mesh of iBGP peers, allow all iBGP routes to be learned by all iBGP routers in the AS, and prevent loops. In an iBGP design using RRs, a partial mesh of iBGP peers is defined. Some routers are configured as RR servers; these servers are allowed to learn iBGP routes from their clients and then advertise them to other iBGP peers. The example in Figure 12-10 shows the key terms and some of the core logic used by an RR; note that only the RR server itself uses different logic, with clients and nonclients acting as normal iBGP peers.

Figure 12-10 Basic Flow Using a Single RR, Four Clients, and Two Nonclients

ASN 123

Figure 12-10 Basic Flow Using a Single RR, Four Clients, and Two Nonclients

ASN 123

Figure 12-10 shows how prefix 11.0.0.0/8 is propagated through the AS, using the following steps:

2. R11 uses normal iBGP rules and sends an Update to R1.

3. R1 reflects the routes by sending Updates to all other clients.

4. R1 also reflects the routes to all non-clients.

5. Nonclients use non-RR rules, sending an Update over eBGP to R77.

KEY Only the router acting as the RR uses modified rules; the other routers (clients and non-clients) are POINT not even aware of the RR, nor do they change their operating rules. Table 12-11 summarizes the rules for RR operation, which vary based on from what type of BGP peer the RR receives the prefix. The table lists the sources from which a prefix can be learned, and the types of other routers to which the RR will reflect the prefix information.

Table 12-11 Types of Neighbors to Which Prefixes Are Reflected

Location from Which a Prefix Is Learned

Are Routes Advertised to Clients?

Are Routes Advertised to Non-clients?

Client

Yes

Yes

Non-client

Yes

No

eBGP

Yes

Yes

The one case in which the RR does not reflect routes is when the RR receives a route from a nonclient, with the RR not reflecting that route to other nonclients. The perspective behind that logic is that RRs act like normal iBGP peers with nonclients and with eBGP neighbors—in other words, the RR does not forward iBGP-learned routes to other nonclient iBGP peers. The difference in how the RR behaves relates to when a client sends the RR a prefix, or when the RR decides to reflect a prefix to the clients.

One (or more) RR servers, and their clients, create a single RR cluster. A BGP design using RRs can consist of:

■ Clusters with multiple RRs in a cluster

■ Multiple clusters, although using multiple clusters makes sense only when physical redundancy exists as well.

With multiple clusters, at least one RR from a cluster must be peered with at least one RR in each of the other clusters. Typically, all RRs are peered directly, creating a full mesh of RR iBGP peers among RRs. Also, if some routers are nonclients, they should be included in the full mesh of RRs.

Figure 12-11 shows the concept, with each RR fully meshed with the other RRs in other clusters, as well as with the nonclient.

Figure 12-11 Multiple RR Clusters with Full Mesh Among RRs and Nonclients

Figure 12-11 Multiple RR Clusters with Full Mesh Among RRs and Nonclients

Routing Loops

If you consider the logic summary in Table 12-11 compared to Figure 12-11, it appears that routing loops are not only possible but probable with this design. However, the RR feature uses several tools to prevent loops, as follows:

KEY ■ CLUSTER_LIST—RRs add their cluster ID into a BGP PA called the CLUSTER_LIST POINT before sending an Update. When receiving a BGP Update, RRs discard received prefixes for which their cluster ID already appears. As with AS_PATH for confederations, this prevents RRs from looping advertisements between clusters.

■ ORIGINATOR_ID—This PA lists the RID of the first iBGP peer to advertise the route into the AS. If a router sees its own BGP ID as the ORIGINATOR_ID in a received route, it does not use or propagate the route.

■ Only advertise the best routes—RRs reflect routes only if the RR considers the route to be a "best" route in its own BGP table. This further limits the routes reflected by the RR. (It also has a positive effect compared with confederations in that an average router sees fewer, typically useless, redundant routes.)

Example 12-15 shows a simple example of using RRs. Figure 12-12 shows the modified AS 123 from the network of Figure 12-4, now with four routers. The design uses two clusters, with two RRs (R9 and R2) and two clients (R1 and R3). The following list outlines the sequence of events to propagate a prefix, as shown in Figure 12-12:

1. R3 learns prefix 21.0.0.0/8 via eBGP from AS 45 (R4).

2. R3 advertises the prefix via iBGP to R2 using normal logic.

3. R2, an RR, receiving a prefix from an RR client, reflects the route via iBGP to R9—a nonclient as far as R2 is concerned.

4. R9, an RR, receiving an iBGP route from a nonclient, reflects the route to R1, its RR client.

Figure 12-12 Modified AS 123 Used in RR Example 12-15

ASN 123

Figure 12-12 Modified AS 123 Used in RR Example 12-15

ASN 123

Example 12-12 RR Configuration for AS 123, Two RRs, and Two Clients

Example 12-12 RR Configuration for AS 123, Two RRs, and Two Clients

! R3 Configuration. The RR client has no overt signs of being a client; the ! process is completely hidden from all routers except RRs. Also, do not forget ! that one of the main motivations for using RRs is to allow sync to be disabled, router bgp 123 no synchronization neighbor 2.2.2.2 remote-as 123

Example 12-12 RR Configuration for AS 123, Two RRs, and Two Clients (Continued)

neighbor 2.2.2.2 update-source Loopbackl neighbor 2.2.2.2 next-hop-self neighbor 4.4.4.4 remote-as 45 neighbor 4.4.4.4 ebgp-multihop 255 neighbor 4.4.4.4 update-source Loopbackl

! R2 Configuration. The cluster ID would default to R2's BGP RID, but it has been ! manually set to "1," which will be listed as "0.0.0.1" in command output. R2 ! designates 3.3.3.3 (R3) as a client. router bgp 123 no synchronization bgp cluster-id 1 neighbor 3.3.3.3 remote-as 123 neighbor 3.3.3.3 update-source Loopback1 neighbor 3.3.3.3 route-reflector-client neighbor 9.9.9.9 remote-as 123 neighbor 9.9.9.9 update-source Loopback1

! R9 Configuration. The configuration is similar to R2, but with a different ! cluster ID. router bgp 123 no synchronization bgp router-id 9.9.9.9 bgp cluster-id 2 neighbor 1.1.1.1 remote-as 123 neighbor 1.1.1.1 update-source Loopback2 neighbor 1.1.1.1 route-reflector-client neighbor 2.2.2.2 remote-as 123 neighbor 2.2.2.2 update-source Loopback2 no auto-summary

! The R1 configuration is omitted, as it contains no specific RR configuration, ! as is the case with all RR clients.

! The 21.0.0.0/8 prefix has been learned by R3, forwarded over iBGP as normal to ! R2. Then, R2 reflected the prefix to its only other peer, R9. The show ip bgp ! 21.0.0.0 command shows the current AS_PATH (45); the iBGP originator of the ! route (3.3.3.3), and the iBGP neighbor from which it was learned ("from ! 2.2.2.2"); and the cluster list, which currently has R2's cluster (0.0.0.1). ! The next output is from R9. R9# show ip bgp 21.0.0.0

BGP routing table entry for 21.0.0.0/8, version 3

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Flag: 0x820

Advertised to update-groups: 2

Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 3.3.3.3, Cluster list: 0.0.0.1 ! RR R9 reflected the prefix to its client (R1), as seen next. Note the changes

Example 12-12 RR Configuration for AS 123, Two RRs, and Two Clients (Continued)

! compared to R9's output, with iBGP route being learned from R9 ("from 9.9.9.9"), ! and the cluster list now including cluster 0.0.0.2, as added by R9. R1# sho ip bgp 21.0.0.0

BGP routing table entry for 21.0.0.0/8, version 20 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 45

Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 3.3.3.3, Cluster list: 0.0.0.2, 0.0.0.1

0 0

Responses

  • Dirk
    What routing protocol code does the routing table use for ebgp?
    4 months ago
  • Nile
    What is check in add routing table in ibgp?
    3 months ago

Post a comment