Problem in Propagating BGP Route to IBGP Neighbor but Not to EBGP Neighbor-Cause: BGP Route Was from Another IBGP Speaker

‚  < ‚  Free Open Study ‚  > ‚  

Problem in Propagating BGP Route to IBGP Neighbor but Not to EBGP Neighbor ‚ Cause: BGP Route Was from Another IBGP Speaker

In some cases, certain routes are not propagated to IBGP neighbors but are propagated only to EBGP neighbors.

When IBGP speakers in an AS are not fully meshed and have no route reflector or confederation configuration, any route that is learned from an IBGP neighbor will not be given to any other IBGP neighbor. Such routes are advertised only to EBGP neighbors, as illustrated in Figure 15-13. Chapter 14 explains using route reflectors and confederations. You also can find information on this topic in the "Troubleshooting BGP When Route Reflectors Are Used" section, later in this chapter.

Figure 15-13. IBGP Network in Which IBGP Routes Are Not Propagated to Other IBGP Speakers

graphics/15fig13.gif

Figure 15-14 shows the flowchart to follow to fix this problem.

Figure 15-14. Problem-Resolution Flowchart

graphics/15fig14.gif

Debugs and Verification

Example 15-33 shows the necessary configuration to have an IBGP relationship between R8 to R1 and R1 to R2. This example also shows a sample configuration of R8 advertising 100.100.100.0/24 to R1.

Example 15-33 Configuring an IBGP Relationship Between R8/R1 and R1/R2
 R8#  router bgp 109   no synchronization   network 100.100.100.0 mask 255.255.255.0   neighbor 206.56.89.2 remote-as 109   ip route 100.100.100.0 255.255.255.0 Null0  _____________________________________________________________________________________ R1#  router bgp 109   no synchronization   neighbor 131.108.1.2 remote-as 109   neighbor 206.56.89.1 remote-as 109  _____________________________________________________________________________________ R2#  router bgp 109   no synchronization  neighbor 131.108.1.1 remote-as 109 

Example 15-33 shows that the IBGP network is not fully meshed and that the IBGP-learned route will not be given to any other IBGP neighbor.

Example 15-34 shows BGP table output from R8, R1, and R2, respectively. R8 is adver-tising 100.100.100.0/24, which shows up in its BGP table and in R1's table. In the output of R1, notice the highlighted output "Not advertised to any peer." Although R1 and R2 are IBGP neighbors, R1 does not advertise 100.100.100.0/24 to R2 and it is learned from another IBGP neighbor, R8.

Example 15-34 R8, R1, and R2 BGP Tables Show That an IBGP-Learned Route in R1 Will Not Be Given to IBGP Neighbor R2
 R8#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 3 Paths: (1 available, best #1, table Default-IP-Routing-Table)  Advertised to non peer-group peers:   206.56.89.2  Local     0.0.0.0 from 0.0.0.0 (8.8.8.8) Origin IGP,metric 0,localpref 100,weight 32768,valid,sourced,local,best _____________________________________________________________________________________ R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 9 Paths: (1 available, best #1, table Default-IP-Routing-Table)  Not advertised to any peer  Local     206.56.89.1 from 206.56.89.1 (8.8.8.8)       Origin IGP, metric 0, localpref 100, valid, internal, best _____________________________________________________________________________________ R1#  show ip bgp summary  BGP router identifier 1.1.1.1, local AS number 109 BGP table version is 11, main routing table version 11 1 network entries and 1 paths using 133 bytes of memory 1 BGP path attribute entries using 52 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP activity 24/237 prefixes, 35/34 paths, scan interval 15 secs Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd 131.108.1.2     4   109    4304    4319       11    0    0 1d20h           0 206.56.89.1     4   109     108     110       11    0    0 01:44:16        1 _____________________________________________________________________________________ R2#  show ip bgp 100.100.100.0  % Network not in table 

In the output of R1, "Not advertised to any peer" means that even though R2 is the neighbor, it is an IBGP neighbor and 100.100.100.0/24 will not be advertised. This rule comes from RFC 1771 section 9.2.1, titled "Internal Updates":

When a BGP speaker receives an UPDATE message from another BGP speaker located in its own autonomous system, the receiving BGP speaker shall not re-distribute the routing information contained in that UPDATE message to other BGP speakers located in its own autonomous system.

Solution

It is essential that IBGP-learned routes are propagated to other BGP speakers. BGP operators can use three methods to address this problem:

  • Use IBGP full mesh.

  • Design a route-reflector model.

  • Design a confederation model.

IBGP Full Mesh

Having an IBGP full mesh is unacceptable even in a small ISP network.

For larger ISPs that maintain several hundred BGP speakers, IBGP full mesh would harm them more than providing benefit. Therefore, savvy BGP operators typically do not choose this method. Chapter 14 explains this is greater detail.

Designing a Route-Reflector Model

RFC 1966 discusses a model to avoid IBGP full mesh by introducing the concept of route-reflector servers and route-reflector clients .

Servers peer BGP with all clients in the cluster. A cluster is a set of servers and clients. Clients peer BGP only with servers. Clients advertise BGP updates to servers, and servers then reflect them to other clients. In Figure 15-15, R1 act as the server and R8 and R2 act as clients. R1, R2, and R8 form a cluster. Refer to Chapter 14 to undersatnd Route-Reflection in detail.

Figure 15-15. Route-Reflector Model to Avoid Full-Mesh IBGP

graphics/15fig15.gif

Example 15-35 shows the relevant configuration to make R1 the route-reflector. Route-reflector clients need no additional configuration other than what is already shown in Example 15-33.

Example 15-35 Configuring R1 as the Route Reflector and R2 and R8 as Route-Reflector Clients
 R1#  router bgp 109   no synchronization   neighbor 131.108.1.2 remote-as 109    neighbor 131.108.1.2 route-reflector-client    neighbor 206.56.89.1 remote-as 109   neighbor 206.56.89.1 route-reflector-client  

The output in Example 15-36 shows that R1 receives 100.100.100.0/24 from R8 and advertises to R2 (131.108.1.2). Notice that this was not the case in the original problem in Figure 15-13. Example 15-36 also shows that R2 receives 100.100.100.0/24 from R1.

Example 15-36 BGP Table Output to Display How Route Reflectors Solved the IBGP Update Failure Problem
 R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 13 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208  Advertised to non peer-group peers:   131.108.1.2  Local, (Received from a RR-client)     206.56.89.1 from 206.56.89.1 (8.8.8.8)       Origin IGP, metric 0, localpref 100, valid, internal, best _____________________________________________________________________________________ R2#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 35 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208   Not advertised to any peer   Local     206.56.89.1 from 131.108.1.1 (8.8.8.8)       Origin IGP, metric 0, localpref 100, valid, internal, best       Originator: 8.8.8.8, Cluster list: 1.1.1.1 

The highlighted section in R1's output shows that it is advertising 100.100.100.0/24 to R2, its IBGP neighbor, which was not the case in Example 15-34.

Designing a Confederation Model

RFC 1965 explains how an AS confederation for BGP can avoid full IBGP mesh. With confederations, the BGP network is divided into small sub ‚ autonomous systems. These sub ‚ autonomous systems are connected to other sub ‚ autonomous systems. These sub ‚ autonomous systems need not be fully meshed. BGP speakers within a sub ‚ autonomous system must have a full mesh of IBGP. If the number of sub ‚ autonomous systems grows to a large number of IBGP speakers, sub ‚ autonomous system IBGP speakers use route reflectors. All routers take a configuration change when moved from an IBGP model to a confederation model. Refer to Chapter 14 to understand Confederation in detail.

Figure 15-16 shows that R1 and R2 are combined in a sub-AS and that R8 is in its own sub-AS.

Figure 15-16. Confederation Model

graphics/15fig16.gif

Example 15-37 highlights all the changes in the configuration of Routers R1, R2, and R8.

Example 15-37 Configuring the Network of R1, R2, and R8 as a Confederation Model
 R8#  router bgp 65201   bgp confederation identifier 109   bgp confederation peers 65200 65201   network 100.100.100.0 mask 255.255.255.0   neighbor 206.56.89.2 remote-as 65200   ip route 100.100.100.0 255.255.255.0 Null0  _____________________________________________________________________________________ R1#  router bgp 65200   bgp confederation identifier 109   bgp confederation peers 65201 65200   neighbor 131.108.1.2 remote-as 65200   neighbor 206.56.89.1 remote-as 65201  _____________________________________________________________________________________ R2#  router bgp 65200   no synchronization   bgp confederation identifier 109   bgp confederation peers 65200 65201  neighbor 131.108.1.1 remote-as 65200 

Example 15-37 shows a significant change in BGP configuration of Routers R1, R2, and R8. When a BGP network migrates to a confederation, all routers need configuration changes. In Example 15-37, confederation identifier represents that real AS of the net-work; the confederation peers command lists the peering confederation sub-AS in the BGP network. The confederation sub-AS is configured with the router bgp command. All BGP updates sent to other confederations are sent with a confederation sub-AS list similar to the AS_PATH list, but updates to EBGP neighbors are sent with the real AS number. A prefix received from the outside confederation sub-AS is advertised to all confederation neighbors, internal or external, resulting in prefix propagation ‚ this was not possible in partially meshed IBGP. To the outside world, a confederation has no value because it is a technique used locally in the BGP network to reduce an IBGP mesh.

Example 15-38 shows the output of the BGP table from each router.

Example 15-38 BGP Tables from the Routers in a BGP Confederation
 R8#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   206.56.89.2   Local     0.0.0.0 from 0.0.0.0 (8.8.8.8)   Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local,best _____________________________________________________________________________________ R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   131.108.1.2  (65201)  206.56.89.1 from 206.56.89.1 (8.8.8.8)       Origin IGP, metric 0, localpref 100, valid, confed-external, best _____________________________________________________________________________________ R2#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208   Not advertised to any peer   (65201)     206.56.89.1 from 131.108.1.1 (1.1.1.1)       Origin IGP, metric 0, localpref 100, valid, internal, best 

R8 is advertising 100.100.100.0/24 to R1. In R1's output, the highlighted line shows the confederation sub-AS, 65201, that 100.100.100.0/24 update has traversed. This is the sub-AS that has R8 in it. R1 advertises this update to R2 because this update came from another confederation sub-AS. This setup sidesteps the need for a full mesh of R1, R2, and R8, which otherwise was needed to propagate 100.100.100.0/24 from R8 to R2.

‚  < ‚  Free Open Study ‚  > ‚  


Troubleshooting IP Routing Protocols
Troubleshooting IP Routing Protocols (CCIE Professional Development Series)
ISBN: 1587050196
EAN: 2147483647
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net