Foreword BGP ring defense is implemented through AS_PATH, and AS_PATH is only changed when the route leaves the AS. Therefore, within the AS, IBGP does not have EBGP ring defense capabilities. In order to prevent the occurrence of loops, BGP routers will not be from IBGP neighbor The learned routes are advertised to other IBGP neighbors. BGP stipulates that the routes learned through one IBGP will not be propagated to all other IBGP neighbors. This is the BGP split horizon rule. Due to the principle of split horizon, BGP requires that within the AS, IBGP must be fully interconnected (here it is specified by the neighbor command). (The root cause is that within the AS, the AS-PATH will not change and the AS_PATH anti-ring cannot be used, so loops are prone to occur)   Split horizon: R3 does not send to other IBGP neighbor R2 after receiving the update from IBGP neighbor R4. As a result, R2 and R1 cannot get the route of R4 It is also split horizontally, both in BGP and IGP; then: IGP split horizon: The routing information learned from an interface will no longer be advertised from that interface. It is from that mouth that no longer comes out from this mouth. Horizontal split of BGP: The routing information learned from any IBGP neighbors is no longer forwarded to any IBGP router. To put it bluntly is a dead end, no longer in control. So, someone asked, since the same is horizontal split, why are the standards different? IGP can also send updates to other routers, is BGP too worried? If BGP is right, does IGP cause a loop? Answer: Yes! IGP still has a loop to do so! However, this loop is a loop of a large network, so IGP uses other methods to solve this problem, such as the 16-hop RIP (otherwise, if a horizontal split is all done, RIP does not need the 16-hop setting); the reason is The horizontal split of IGP is just to prevent problems in a small area such as regional networks (such as adjacent routers). If the network is large and the interconnection is complicated, loops may still occur. This situation is intolerable for BGP, a protocol that carries such core and large-scale routing. There is no need to explain this point. Therefore, BGP adopts such a brutal version of horizontal splitting. How to solve the problem that split horizon causes R4 and R2 to fail to get the route. So how to solve this kind of problem?   Option One Let the routers in the AS domain be physically fully connected, add a physical link between RTB and RTC, and establish an IBGP neighbor relationship between RTC and RTB, so that RTC can directly pass its own route to the RTB router. The RTB router directly passes the route to RTA through the EBGP neighbor relationship. This fully connected network deployment solution, on the one hand, has a high networking cost, and on the other hand, the increase in the number of BGP connections correspondingly increases the resource consumption of the system, and the fully connected network deployment has poor scalability. Is there a simpler way? Option II Make the routers in the AS domain fully logically connected, make the IGP routes of RTB and RTC reachable to each other, establish an IBGP neighbor relationship between RTB and RTC, so that RTC can directly pass its own route to RTB router, which is directly Routes to RTA through EBGP neighbor relationship. The ultimate solution-RR No need to add physical link or new IBGP neighbor relationship-configure BGP route reflector. The RTD is configured with a route reflector, and both RTB and RTC configure a reflector RTD client. In this way, according to the reflector's route reflection principle, RTC can easily reflect its own route to RTB, and RTB passes the EBGP neighbor relationship. Modified application network diagram:   Route Reflector (RR): Allows the routes learned from IBGP peers to be reflected to BGP devices of other IBGP peers. Client: IBGP device that forms a reflection neighbor relationship with RR. Within the AS, the client only needs to be directly connected to the RR. Non-Client: IBGP device that is neither an RR nor a client. Between the non-client and RR within the AS, The purpose of the route reflector (RR) is to simplify the configuration of IBGP neighbors. After using the reflector, it allows the reflector to send routing information from the IBGP neighbor to another IBGP neighbor or a group of neighbors. The router allows the router configured as a route reflector to transmit the routes learned by IBGP to other IBGP peers to modify the horizontal isolation rules of BGP, so that fully interconnected IBGP peers are no longer needed. Reflection function The route reflector will reflect the information between the clients in turn. The route reflector and all its clients form a group. Multiple route reflectors are allowed in a group. A route reflector can configure other route reflectors as its clients or non-clients; a route reflector transmits route updates between its clients and non-clients Rules: If the route update is received from a non-client, it is only reflected to the client; if the route update is received from a client, it is reflected to all non-clients and clients, except for the originator of this route update ; If the routing update is received from the EBGP neighbor, it will be reflected to all clients and non-clients. Reflection process Public network route BGP route delivery process Pass a route from RTC to the RTA router through the route reflector, RTA Router ID is 1.1.1.1, RTB Router ID is 2.2.2.2, RTD Router ID is 3.3.3.3, RTC Router ID is 4.4.4.4. RTC publishes a route 4.4.4.4/32 to the IBGP reflector. The reflector RTD learns the route and reflects the route 4.4.4.4/32 to the client RTB.   RTD: Sh ip bgp route 4.4.4.4 BGP local router ID：3.3.3.3 Local AS number： Path：1 available，1 best BGP routing table entry information of 4.4.4.4/32 RR-client route From：30.0.0.2 （4.4.4.4） Relay Nexthop：0.0.0.0 Original nexthop：30.0.0.2 AS-path：（null） Origin：incomplete Attribute value：MED 0， localpref 100，pref-val 0，pre 255 State：valid，internal，best， Advertised to such 1 peers：20.0.0.1 The client RTB learns the 4.4.4.4/32 route reflected by the reflector. The Originator of the route is 4.4.4.4 (that is, RTC router), and the Cluster list is 3.3.3.3 (that is, the route is reflected by the reflector RTD router) , Original nexthop is 30.0.0.2 (the route initiates the next hop), Relay Nexthop is 20.0.0.2 (the route relays the next hop).   RTB: Sh ip bgp route 4.4.4.4 BGP local router ID：2.2.2.2 Local AS number：100 Path：1 available，1 best BGP routing table entry information of 4.4.4.4/32 RR-client route From：20.0.0.2（3.3.3.3） Relay Nexthop：20.0.0.2 Original nexthop：30.0.0.2 AS-path：（null） Origin：incomplete Attribute value：MED 0，localpref 100，pref-val 0，pre 255 State：valid，internal，best， Originator：4.4.4.4 Cluster list：3.3.3.3 Advertised to such 1 peers：10.0.0.1 The RTA router learned the route 4.4.4.4/32 through the EBGP neighbor relationship.   RTA: Sh ip bgp route 4.4.4.4 BGP local router ID：1.1.1.1 Local AS number ：200 Path：1 available，1 best BGP routing table entry information of 4.4.4.4/32 From：10.0.0.2 （2.2.2.2） Original nexthop：10.0.0.2 AS-path：100 Origin：incomplete Attribute value：pref-val 0，pre 255 State：valid，external，best， Not advertised to any peers yet In this way, the route reflector successfully shields the BGP horizontal isolation rules and passes the route to the RTA router.   Route reflector (RR) configuration: ①: Enable BGP ②: Establish neighbors under the same BGP-AS. ③: Specify the router and the AS where it is located. ④: Specify the source. ⑤: (neighbor) RR client-configure the client. ⑥：neighbor router-id route-reflector-client   RTD: Router bgp 100 bgp router-id 3.3.3.3 neighbor 2.2.2.2 remote-as 100 neighbor 4.4.4.4 remote-as 100 neighbor 2.2.2.2  route-reflector-client neighbor 4.4.4.4  route-reflector-client Note: if you  are interested in the article, and you can follow SPOTO. And, you want to take any certifed exam, and you can contact us now!