BGP routing black hole and full IBGP connection

Networking requirements:
1. AS65000 boundary network segment release: RT1 and RT2 re-release direct connection route to OSPF (metric 1000 type 1)
2. BGP Configuration Requirements:
No synchronization
No auto-summary IBGP uses LOOPBACK to establish a neighbor, and the next hop points to itself
3. RT1 and RT2 publish a summary route of AS65000 to BGP: 10.0.0.0/16 and 10.3.0.0/16.
4. RT5 publishes a summary route for AS65001 to BGP: 10.5.0.0/16
5. RT6 publishes a summary route for AS65001 to BGP: 10.6.0.0/16
6. Analyze the formation and solution of the routing Black Hole
IGP route Configuration:
R1:
Router ospf 1
Router-id 10.0.0.1
Redistribute connected metric 1000 metric-type 1 subnets // re-release the direct connection network to OSPF
Passive-interface Serial0/1 // The interface connected to EBGP must be configured as a passive interface to avoid neighbor Formation
Network 10.0.0.1 0.0.0.0 area 0
Network 10.0.1.4 0.0.0.3 area 0
R3:
Router ospf 1
Router-id 10.0.0.3
Passive-interface default
No passive-interface Serial0/0
No passive-interface FastEthernet1/0
Network 10.0.0.3 0.0.0.0 area 0
Network 10.0.1.0 0.0.0.3 area 0
Network 10.0.1.4 0.0.0.3 area 0
Network 10.3.3.0 0.0.0.255 area 0
Interface FastEthernet1/0
Ip address 10.0.1.1 255.255.255.252
Ip ospf network point-to-point // configure the network type to point-to-point (DR or BDR is not required)
R4:
Router ospf 1
Router-id 10.0.0.4
Passive-interface default
No passive-interface Serial0/0
No passive-interface FastEthernet1/0
Network 10.0.0.4 0.0.0.0 area 0
Network 10.0.1.0 0.0.0.3 area 0
Network 10.0.1.8 0.0.0.3 area 0
Network 10.3.4.0 0.0.0.255 area 0
Interface FastEthernet1/0
Ip address 10.0.1.1 255.255.255.252
Ip ospf network point-to-point // configure the network type to point-to-point (DR or BDR is not required)
R2:
Router ospf 1
Router-id 10.0.0.2
Redistribute connected metric 1000 metric-type 1 subnets // re-release the direct connection network to OSPF
Passive-interface default // The interface connected to EBGP must be configured as a passive interface to avoid neighbor Formation
No passive-interface Serial0/0
Network 10.0.1.8 0.0.0.3 area 0
IBGP Configuration:
R1:
Router bgp 65000
No synchronization // disable synchronization
Neighbor 10.0.0.2 remote-as 65000 // specify the IBGP neighbor and
Neighbor 10.0.0.2 update-source Loopback0 // specify the update source as LOOPBACK 0
Neighbor 10.0.0.2 next-hop-self // change the next hop to your own (EBGP default)
Neighbor 10.0.15.2 remote-as 65001 // specify the EBGP neighbor and
Network 10.0.0.0 mask route 255.0.0/static publish route to BGP
No auto-summary // disable auto summary
Ip route 10.0.0.0 255.255.0.0 null 0 // Add a static summary route for publishing
R2:
Router bgp 65000
No synchronization // disable synchronization
Neighbor 10.0.0.1 remote-as 65000 // specify the neighbor and
Neighbor 10.0.0.1 update-source Loopback0 // specify the update source as LOOPBACK 0
Neighbor 10.0.0.1 next-hop-self // change the next hop to your own (EBGP default)
Neighbor 10.0.26.2 remote-as 65002 // specify the EBGP neighbor and
Network 10.3.0.0 mask route 255.0.0/static publish route to BGP
No auto-summary // disable auto summary
Ip route 10.3.0.0 255.255.0.0 null 0 // Add a static summary route for publishing
R5:
Router bgp 65001
Network 10.5.0.0 mask route 255.0.0 // statically publish the route to BGP
Neighbor 10.0.15.1 remote-as 65000 // specify the EBGP neighbor and
No auto-summary // disable auto summary
Ip route 10.5.0.0 255.255.0.0 Null0 // Add a static summary route for publishing to BGP
R6:
Router bgp 65002
No synchronization // disable synchronization
Network 10.6.0.0 mask route 255.0.0 // route to BGP
Neighbor 10.0.26.1 remote-as 65000 // specify the EBGP neighbor and
No auto-summary // disable auto summary
Ip route 10.6.0.0 255.255.0.0 Null0 // Add a static summary route for publishing to BGP
Note: When IBGP is used, the default hop count is 255, and the default hop count is 1 for EBGP. If you use the LOOBACK address of EBGP to create a neighbor, you must manually specify the hop count.
Neighbor 10.10.10.10 ebgp-multihop 2 // The number of hops is 1-255.
Thinking: Can I PING 10.6.6.1 at 10.5.5.1?
The answer is that ping is not allowed because no route to R6 is available on R3 (analyzed later)
Now let's analyze the propagation of the 10.6.0.0/16 route on R6!
On R6:
Network Next Hop Metric LocPrf Weight Path
*> 10.5.0.0/16 10.0.26.1 0 65000 65001 I
*> 10.6.0.0/16 0.0.0.0 0 32768 I
* Valid> indicates that the next hop is 0.0.0.0 because 10.6.0.0 is originated from the current vrobgp. If it is re-published to BGP, it is the next hop in IGP, the weight of the local originating route is 32768, And the Originn attribute is IGP
R2 receives the route from EBGP and forwards it to all its neighbors.
*> 10.6.0.0/16 10.0.26.2 0 0 65002 I
Because it is advertised by EBGP, the next hop is the neighbor address of EBGP.
R1:
*> I10.6.0.0/16 10.0.0.2 0 100 0 65002 I
Whether the route learned from IBGP is advertised to EBGP depends on synchronization. Because synchronization is disabled, it can be advertised to R5 (if synchronization is enabled, you must configure next-hop-self on R2 to change the next hop to yourself, therefore, the next hop of the route received by R1 points to its IBGP neighbor.
R5:
* & Gt; 10.6.0.0/16 10.0.15.1 0 65000 65002 I
When you advertise a route to EBGP, change the next hop to your own. Similarly, R6 can also learn R5 routes.
When 10.5.5.1ping10.6.6.1, R5 finds the route table and matches the route of 10.6.0.0/16. The next hop is 10.0.15.1, which is a direct connection interface. It sends the number to R1 and R1 searches for the route and finds the route matching 10.6.0.0/16, the next hop is 10.0.0.2, not a direct connection interface. The next hop is the destination IP address for recursive search routing, matching 10. 0 .. 02/32 route. The next hop is 10.0.1.5, which is a direct connection interface. data is sent to R3. R3 searches for the route based on the target IP10.6.6.1. If no matching item is found, data is discarded, because R3 does not run BGP and cannot learn BGP routes, a routing black hole is formed.
Solution: 1. re-distribute BGP routes to OSPF
2. Create a full IBGP connection for the routers in the.
3. Route reflectors
4. Configure MPLS
Method 1.
The configuration is as follows:
R1:
Router ospf 1
Redistribute bgp 65000 subnets // redistributes BGP routes to OSPF
R2:
Router ospf 1
Redistribute bgp 65000 subnets // redistributes BGP routes to OSPF
Now we can see that all the routers in the AS have routes outside of the AS, so we can PING them!
The route table of R3, with routes outside of the:

Test on R5:

Note: As there are tens of thousands of BGP routes on the INTERNET, it is not feasible to re-distribute BGP routes to OSPF without a policy, OSPF supports a maximum of 10 thousand route tables and consumes a lot of router memory. Therefore, this method is generally not used!
There is a public router on the INTERNET, you can view the above route table, just telnet on the route-server.ip.att.net address on the line, the user name is rviews

More than 0.14 million BGP Route tables
Method 2: Full connection of IBGP (because the route learned from one IBGP is not transmitted to another IBGP, full connection is required to prevent routing loops)
The configuration is as follows:
R1:
Neighbor 10.0.0.3 remote-as 65000
Neighbor 10.0.0.3 update-source Loopback0
Neighbor 10.0.0.3 next-hop-self
Neighbor 10.0.0.4 remote-as 65000
Neighbor 10.0.0.4 update-source Loopback0
Neighbor 10.0.0.4 next-hop-self
R3:
Router bgp 65000
No synchronization
Neighbor 10.0.0.1 remote-as 65000
Neighbor 10.0.0.1 update-source Loopback0
Neighbor 10.0.0.1 next-hop-self
Neighbor 10.0.0.4 remote-as 65000
Neighbor 10.0.0.4 update-source Loopback0
Neighbor 10.0.0.4 next-hop-self
Neighbor 10.0.0.2 remote-as 65000
Neighbor 10.0.0.2 update-source Loopback0
Neighbor 10.0.0.2 next-hop-self
No auto-summary
R4:
Router bgp 65000
No synchronization
Neighbor 10.0.0.1 remote-as 65000
Neighbor 10.0.0.1 update-source Loopback0
Neighbor 10.0.0.1 next-hop-self
Neighbor 10.0.0.3 remote-as 65000
Neighbor 10.0.0.3 update-source Loopback0
Neighbor 10.0.0.3 next-hop-self
Neighbor 10.0.0.2 remote-as 65000
Neighbor 10.0.0.2 update-source Loopback0
Neighbor 10.0.0.2 next-hop-self
No auto-summary
R2:
Neighbor 10.0.0.4 remote-as 65000
Neighbor 10.0.0.4 update-source Loopback0
Neighbor 10.0.0.4 next-hop-self
Neighbor 10.0.0.3 remote-as 65000
Neighbor 10.0.0.3 update-source Loopback0
Neighbor 10.0.0.3 next-hop-self
Check the neighbor relationship on R3. A full connection has been formed!

There are also AS external routes

Now test on R5:

Now let's analyze a route. R1 advertises 10.5.0.0/16 to R3. Will R3 advertise this route to R4?
R3 receives a route from its own R1:
*> I10.5.0.0/16 10.0.0.1 0 100 0 65001 I
Route on R4:
*> I10.5.0.0/16 10.0.0.1 0 100 0 65001 I
Why is there only one route here, because the IGBP full connection is advertised by R1, and The Routes learned by R3 from IBGP are no longer transmitted to IBGP, so there is only one route on R4, this is why full connections are formed.
Restricted by words, method 3 route reflectors will be detailed in the next article!
This article is from the "Mortal World" blog