Federal Comprehensive Experiment

Experimental topology

Experimental requirements:

1. There are two loopbacks in AS1, one address is This address cannot be declared in any protocol.

There are two loopbacks in AS3, one with an address of This address cannot be declared in any protocol. Ultimately, the two loopbacks are required to communicate with each other.

Another loopback for AS1 is, another loopback for AS3 is

2. The IP address of the entire AS2 is, 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 24
[r2-GigabitEthernet0/0/0]int g0/0/1
[r2-GigabitEthernet0/0/1]ip address 29
[r2-GigabitEthernet0/0/1]int g0/0/2	
[r2-GigabitEthernet0/0/2]ip address 29
[r2-GigabitEthernet0/0/2]int l0
[r2-LoopBack0]ip address 24

Enable OSPF to establish neighbor relationship

[r2]ospf 1 router-id
[r3]ospf 1 router-id

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]confederation id 2
[r2-bgp]confederation peer-as 64513
[r2-bgp]peer as-number 1
[r2-bgp]peer as-number 64512
[r2-bgp]peer connect-interface LoopBack 0
[r2-bgp]peer as-number 64513
[r2-bgp]peer connect-interface LoopBack 0	
[r2-bgp]peer ebgp-max-hop

Check whether the neighbor relationship is established successfully


publish route

[r1]bgp 1        

[r1-bgp]network 24

But it is not available on R3, so it needs to be modified on R2

[r2]bgp 64512
[r2-bgp]peer next-hop-local    Revise NextHop
[r2-bgp]peer 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 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 next-hop-local
[r7-bgp]peer next-hop-local

R1 receives the release of R8

Verify that it is compatible

Short interface -- declare

[r2]ip route-static 21 NULL 0
[r2]bgp 64512
[r2-bgp]network 21

(Both ends need to short the interface)

[r7]ip route-static 21 NULL 0
[r7]bgp 64513	
[r7-bgp]network 21

Establish a GRE tunnel

[r1]int Tunnel 0/0/0
[r1-Tunnel0/0/0]ip address 24	
[r1-Tunnel0/0/0]tunnel-protocol gre 
[r1]ip route-static 24 

[r8]int Tunnel 0/0/0
[r8-Tunnel0/0/0]ip address 24
[r8-Tunnel0/0/0]tunnel-protocol gre 
[r8]ip route-static 24

Tags: Operation & Maintenance server eNSP

Posted by ident on Mon, 24 Oct 2022 09:27:53 +0530