Experimental topology
Experimental requirements:
1. There are two loopbacks in AS1, one address is 192.168.1.0/24. This address cannot be declared in any protocol.
There are two loopbacks in AS3, one with an address of 192.168.2.0/24. This address cannot be declared in any protocol. Ultimately, the two loopbacks are required to communicate with each other.
Another loopback for AS1 is 10.0.0.0/24, another loopback for AS3 is 11.0.0.0/24
2. The IP address of the entire AS2 is 172.16.0.0/16, please divide it reasonably
3. The IP address of the backbone link between AS can be customized at will
4. Use the BGP protocol to allow the loopbacks of all devices in the entire network to access each other
5. Reduce the number of routing entries to avoid loopback
Experimental ideas
Step 1: Configure the IP address and loopback address of each device
Step 2: Start IBGP (start AS 2S OSPF first)
Step 3: Start the EBGP peer relationship
Step 4: Publish routing information
Step 5: Solve the split horizon problem (route reflector to solve)
Step 6: Aggregation (empty interface, summary)
Step 7: Establish GRE Tunnel
Configure the IP address and loopback of each device
[Huawei]sysname r2 [r2]int g0/0/0 [r2-GigabitEthernet0/0/0]ip address 12.0.0.2 24 [r2-GigabitEthernet0/0/0]int g0/0/1 [r2-GigabitEthernet0/0/1]ip address 172.16.1.1 29 [r2-GigabitEthernet0/0/1]int g0/0/2 [r2-GigabitEthernet0/0/2]ip address 172.16.1.9 29 [r2-GigabitEthernet0/0/2]int l0 [r2-LoopBack0]ip address 172.16.2.1 24
Enable OSPF to establish neighbor relationship
[r2]ospf 1 router-id 2.2.2.2 [r2-ospf-1-area-0.0.0.0]network 172.16.0.0 0.0.255.255
[r3]ospf 1 router-id 3.3.3.3 [r3-ospf-1-area-0.0.0.0]network 172.16.0.0 0.0.255.255
Check if ospf is running
When a federated member device starts the BGP process, use the trumpet to start it
[r2-bgp]confederation id 2 tells that the large AS where this device is located is AS 2
Take R2 as an example to establish a BGP peer
[r2]bgp 64512 [r2-bgp]router-id 2.2.2.2 [r2-bgp]confederation id 2 [r2-bgp]confederation peer-as 64513 [r2-bgp]peer 12.0.0.1 as-number 1 [r2-bgp]peer 172.16.3.1 as-number 64512 [r2-bgp]peer 172.16.3.1 connect-interface LoopBack 0 [r2-bgp]peer 172.16.5.1 as-number 64513 [r2-bgp]peer 172.16.5.1 connect-interface LoopBack 0 [r2-bgp]peer 172.16.5.1 ebgp-max-hop
Check whether the neighbor relationship is established successfully
publish route
[r1]bgp 1
[r1-bgp]network 10.0.0.0 24
But it is not available on R3, so it needs to be modified on R2
[r2]bgp 64512 [r2-bgp]peer 172.16.3.1 next-hop-local Revise NextHop [r2-bgp]peer 172.16.5.1 next-hop-local
now shows as available
But R4 is not received, the same can be obtained, R7 is not received
Mainly because of IBGP split horizon, R4 cannot be received. (The same is true for R7), so R8 can't receive it either.
Breaking IBGP Split Horizon (Route Reflector)
[r3]bgp 64512 [r3-bgp]peer 172.16.2.1 reflect-client specify R2 as a reflection client
The release is bidirectional, and R8 also has to release its own to R1. On the way, it will also encounter the problem of horizontal division. The method to solve the problem is as follows;
(Route Reflector)
[r7]bgp 64513 [r7-bgp]peer 172.16.6.1 next-hop-local [r7-bgp]peer 172.16.4.1 next-hop-local
R1 receives the release of R8
Verify that it is compatible
Short interface -- declare
[r2]ip route-static 172.16.0.0 21 NULL 0 [r2]bgp 64512 [r2-bgp]network 172.16.0.0 21
(Both ends need to short the interface)
[r7]ip route-static 172.16.0.0 21 NULL 0 [r7]bgp 64513 [r7-bgp]network 172.16.0.0 21
Establish a GRE tunnel
[r1]int Tunnel 0/0/0 [r1-Tunnel0/0/0]ip address 89.0.0.1 24 [r1-Tunnel0/0/0]tunnel-protocol gre [r1-Tunnel0/0/0]source 10.0.0.1 [r1-Tunnel0/0/0]description 11.0.0.1 [r1-Tunnel0/0/0]q [r1]ip route-static 192.16.2.0 24 89.0.0.2 [r8]int Tunnel 0/0/0 [r8-Tunnel0/0/0]ip address 89.0.0.2 24 [r8-Tunnel0/0/0]tunnel-protocol gre [r8-Tunnel0/0/0]source 11.0.0.1 [r8-Tunnel0/0/0]description 10.0.0.1 [r8]ip route-static 192.168.1.0 24 89.0.0.1