Solve BGP routing Black Hole

Solve BGP routing Black Hole

 

650) this. width = 650; "onclick = 'window. open (" http://blog.51cto.com/viewpic.php? Refimg = "+ this. src) 'border =" 0 "alt =" "src =" http://www.bkjia.com/uploads/allimg/131227/0U032E13-0.jpg "/>

 

The ospf protocol is run between R2, R3, and R4, and an IBGP neighbor is established between R2, R3, and R4 using a loopback port. Router bgp 100 no synchronization bgp router-id 1.1.1.1 bgp log-neighbor-changes network 1.1.1.0 mask 255.255.255.0 neighbor 192.1.12.2 remote-as 234 no auto-summary R2 configuration router bgp 234 no bgp router-id 2.2.2.2 bgp log-neighbor-changes neighbor 3.3.3.3 remote-as 234 neighbor 3.3.3.3 update-source Loopback0 neighbor 3.3.3.3 next-hop-self neighbor 192.1.12.1 remote-as 100 no auto -Summary R3 configuration router bgp 234 no bgp router-id 3.3.3.3 bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 234 neighbor 2.2.2.2 update-source Loopback0 neighbor 4.4.4.4 remote-as 234 neighbor 4.4.4.4 update-source Loopback0 no auto-summary R4 configuration router bgp 234 bgp router-id 4.4.4.4 bgp cluster-id 3288400129 bgp log-neighbor-changes neighbor 3.3.3.3.3 remote-as 234 neighbor 3.3.3.3 upda Te-source Loopback0 neighbor 3.3.3.3 next-hop-self neighbor 192.1.45.5 remote-as 500 R5 configuration router bgp 500 no synchronization bgp router-id 5.5.5 bgp cluster-id 3221302533 bgp log-neighbor- changes network 5.5.5.0 mask 255.255.255.0 neighbor 192.1.45.4 remote-as 234 no the 1.1.1.0 route of the auto-summaryR1 can be passed to R2 and R3, but can't R4 receive it? R3 # sh ip bgpBGP table version is 2, local router ID is 3.3.3status codes: s suppressed, d damped, h history, * valid,> best, I-internalOrigin codes: i-IGP, e-EGP ,? -Incomplete Network Next Hop Metric LocPrf Weight Path *> i1.1.1.0/24 2.2.2.2 0 100 0 100 I r3 # r4 # sh ip bgp think about why? The main reason is that ibgp follows the principle of horizontal segmentation, that is, Routes learned from one ibgp neighbor will not be transmitted to another ibgp neighbor. This forms a routing black hole. How can this problem be solved? There are three methods: 1) establish full mesh full interconnection between r1, r2 and r3) ibgp neighbor relationship, so that a large number of IGBP neighbor relationships will be established, it will consume a lot of resources of the device, and the configuration is complicated and not recommended. 2) using federated AS is also known as bgp confederation. To solve the problem of establishing a large number of IBGP neighbors, federated AS can be used. It can be understood that Federated as is composed of a group of sub-Autonomous Systems that share a federated as number, the federated AS number is regarded AS the name of the entire federated AS number by non-federated peers. External peers cannot see the internal structure of the federated. In this example, we can divide two small AS values in AS 234, and make r2 and R3 into AS 65012 and R4 into AS 65014. When establishing a federated AS, we usually use a private

650) this. width = 650; "onclick = 'window. open (" http://blog.51cto.com/viewpic.php? Refimg = "+ this. src) 'border =" 0 "alt =" "src =" http://www.bkjia.com/uploads/allimg/131227/0U03234X-1.jpg "/>

The specific configuration is as follows:

R1 Configuration

Router bgp 100

No synchronization

Bgp router-id 1.1.1.1

Bgp cluster id 167838721

Bgp log-neighbor-changes

Network 1.1.1.0 mask 255.255.255.0

Neighbor 192.1.12.2 remote-as 234

No auto-summary

R2 Configuration

Router bgp 65012

No synchronization

Bgp router-id 2.2.2.2

Bgp cluster id 2886730753

Bgp log-neighbor-changes

 Bgp confederation identifier 234

Neighbor 3.3.3.3 remote-as 65012

Neighbor 3.3.3.3 update-source Loopback0

Neighbor 3.3.3.3 next-hop-self

Neighbor 192.1.12.1 remote-as 100

No auto-summary

R3 Configuration

Router bgp 65012

No synchronization

Bgp router-id 3.3.3.3

Bgp cluster id 3232236289

Bgp log-neighbor-changes

 Bgp confederation identifier 234

Bgp confederation peers 65014

Neighbor 2.2.2.2 remote-as 65012

Neighbor 2.2.2.2 update-source Loopback0

Neighbor 4.4.4 remote-as 65014

Neighbor 4.4.4.4 ebgp-multihop 255

No auto-summary

R4 Configuration

Router bgp 65014

No synchronization

Bgp router-id 4.4.4

Bgp cluster id 3288400129

Bgp log-neighbor-changes

 Bgp confederation identifier 234

Bgp confederation peers 65012

Neighbor 3.3.3.3 remote-as 65012

Neighbor 3.3.3.3 ebgp-multihop 255

Neighbor 3.3.3.3 update-source Loopback0

Neighbor 3.3.3.3 next-hop-self

Neighbor 192.1.45.5 remote-as 500

No auto-summary

R5 Configuration

Router bgp 500

No synchronization

Bgp router-id 5.5.5

Bgp cluster id 3221302533

Bgp log-neighbor-changes

Network 5.5.5.0 mask 255.255.255.255.0

Neighbor 192.1.45.4 remote-as 234

No auto-summary

During the configuration process, the following information is received:

R2 (config-router )#

00: 28: 45: % BGP-3-NOTIFICATION: pinned ed from neighbor 192.1.12.1 2/2 (peer in wrong AS) 2 bytes FDF4

R4 (config-router )#

00: 30: 27: % BGP-3-NOTIFICATION: pinned ed from neighbor 192.1.45.5 2/2 (peer in wrong AS) 2 bytes FDF6

The reason is that the vro in the consortium does not recognize the consortium. You need to run the following command:

Bgp confederation identifier 234

3) method 3: Use route reflectors Router Reflector)

Route reflectors are useful for solving the problem of creating a large number of IBGP neighbors in.

Route reflectors and clients form a Route Reflection cluster. You can regard the Route Reflection cluster as a separate router. for a client, you only need to establish a neighbor with the route reflector, and do not need to establish a neighbor with each ibgp router.

Multiple Route Reflection clusters can be created in an autonomous system.

Rules for Route reflectors: For route reflectors

1. Route entries transmitted from one client will be reflected to another client, reflected to non-clients, and reflected to EBGP neighbors.

2. Route entries transmitted from a non-client will be reflected to another client, and will be reflected to the EBGP neighbor, but will not be passed to another non-Client

3. Route entries transmitted from EBGP will be reflected to another client, reflected to the EBGP neighbor, and reflected to non-Client

 

650) this. width = 650; "onclick = 'window. open (" http://blog.51cto.com/viewpic.php? Refimg = "+ this. src) 'border =" 0 "alt =" "src =" http://www.bkjia.com/uploads/allimg/131227/0U0321915-2.jpg "/>

The configuration command for this case is as follows:

Neighbor 2.2.2.2 route-reflector-client

After configuration, the neighbor will reset

Summary:

1) The implementation of Route reflectors in Topology Design and command configuration is relatively simple.

2) for the Alliance, it is required that all routers must support and recognize the route reflection mechanism, while the route reflector only needs to understand the on-road reflection mechanism, the client regards the connection with RR as a normal IBGP connection.

 

This article from the "dancing" blog, please be sure to keep this source http://xiaofeixia.blog.51cto.com/521300/505705