BGP experiment II
1. There are two loopbacks in AS1, one address is 192.168.1.0/24, which cannot declare that there are two loopbacks in AS3 in any protocol, and the other address is 192.168.2.0/24, which cannot declare that the two loopbacks can communicate with each other in any protocol;
The other loopback of AS1 is 10.1.1.0/24, and the other loopback of AS3 is 10.1.2.0/24
2. The ip address of the whole AS2 is 172.16.0.0 Please divide reasonably
3. The ip address of the backbone link between AS can be customized at will
4. Use BGP protocol to make the loopback of all devices in the whole network accessible to each other. 5. Reduce the number of entries and avoid loopback
Logically:
Physically:
According to the requirements of the topic:
Assigned address:
AS2 Address assignment: Backbone: 172.16.0.0/30 If the number is large: 172.16.0.0/29 172.16.0.1/30 172.16.0.2/30 23 172.16.0.5/30 172.16.0.6/30 34 172.16.0.9/30 172.16.0.10/30 25 172.16.0.13/30 172.16.0.14/30 56 172.16.0.17/30 172.16.0.18/30 67 172.16.0.21/30 172.16.0.22/30 47 Loopback: 172.16.2.0 24 172.16.3.0 24 172.16.4.0 24 172.16.5.0 24 172.16.6.0 24 172.16.7.0 24 R1R2 12.1.1.1/24 12.1.1.2/24 R7R8 78.1.1.1/24 78.1.1.2/24 R1 Loopback: 192.168.1.0/24 10.1.1.0/24 R8 Loopback: 192.168.2.0/24 10.1.2.0/24
Running IGP protocol:
R2:
ospf 1 router-id 2.2.2.2 area 0.0.0.0 network 172.16.0.0 0.0.255.255
R3:
ospf 1 router-id 3.3.3.3 area 0.0.0.0 network 172.16.0.0 0.0.255.255
R4:
ospf 1 router-id 4.4.4.4 area 0.0.0.0 network 172.16.0.0 0.0.255.255
R5:
ospf 1 router-id 5.5.5.5 area 0.0.0.0 network 172.16.0.0 0.0.255.255
R6:
ospf 1 router-id 6.6.6.6 area 0.0.0.0 network 172.16.0.0 0.0.255.255
R7:
ospf 1 router-id 7.7.7.7 area 0.0.0.0 network 172.16.0.0 0.0.255.255
Run BGP protocol:
R1:
bgp 1 router-id 1.1.1.1 peer 12.1.1.2 as-number 2
R2:
bgp 64512 router-id 2.2.2.2 confederation id 2 Declare your size first peer 172.16.3.1 as-number 64512 My neighbor and I are in a small room S confederation peer-as 64513 If there are other small connections S peer 172.16.3.1 connect-interface LoopBack 0 2 Build neighbors with 3, change and update the source peer 172.16.5.1 as-number 64513 peer 172.16.5.1 connect-interface LoopBack 0 peer 172.16.5.1 ebgp-max-hop 2 change TTL Value because 2 and 5 use loopback to build neighbors peer 12.1.1.1 as-number 1
R3:
bgp 64512 router-id 3.3.3.3 confederation id 2 peer 172.16.2.1 as-number 64512 peer 172.16.2.1 connect-interface LoopBack0 peer 172.16.4.1 as-number 64512 peer 172.16.4.1 connect-interface LoopBack0
R4:
bgp 64512 router-id 4.4.4.4 confederation id 2 Declare your big size confederation peer-as 64513 I have a small in the Federation S of peer 172.16.3.1 as-number 64512 Jianlin peer 172.16.3.1 connect-interface LoopBack0 He and I use the ring back to build a neighbor peer 172.16.7.1 as-number 64513 peer 172.16.7.1 ebgp-max-hop 2 EBGP Neighbor creation to be modified TTL value peer 172.16.7.1 connect-interface LoopBack0
R5:
bgp 64513 router-id 5.5.5.5 confederation id 2 confederation peer-as 64512 peer 172.16.2.1 as-number 64512 peer 172.16.2.1 ebgp-max-hop 2 peer 172.16.2.1 connect-interface LoopBack0 peer 172.16.6.1 as-number 64513 peer 172.16.6.1 connect-interface LoopBack0
R6:
bgp 64513 router-id 6.6.6.6 confederation id 2 peer 172.16.5.1 as-number 64513 peer 172.16.5.1 connect-interface LoopBack0 peer 172.16.7.1 as-number 64513 peer 172.16.7.1 connect-interface LoopBack0
R7:
bgp 64513 router-id 7.7.7.7 confederation id 2 confederation peer-as 64512 peer 172.16.4.1 as-number 64512 peer 172.16.4.1 ebgp-max-hop 2 peer 172.16.4.1 connect-interface LoopBack0 peer 172.16.6.1 as-number 64513 peer 172.16.6.1 connect-interface LoopBack0
R8:
bgp 3 router-id 8.8.8.8 peer 78.1.1.1 as-number 2
declare
Declare loopback of R1:
[r1]bgp 1 [r1-bgp]net [r1-bgp]network 10.1.1.0 24
View BGP routing table of R1
R2 normally learns that it should be passed to R3R5, but R3R5 is not good. Let's go to R2 and modify the next hop for our neighbors
R2:
[r2]bgp 64512 [r2-bgp]peer 172.16.3.1 next-hop-local [r2-bgp]peer 172.16.5.1 next-hop-local
If R3 is excellent, will it be passed to R4? No. Because IBGP is divided horizontally, a reflector should be raised at 3
R3:
[r3]bgp 64512 [r3-bgp]peer 172.16.2.1 reflect-client Use 2 as his client
R6:
[r6]bgp 64513 [r6-bgp]peer 172.16.5.1 reflect-client
Declare the loopback of R8:
R8:
[r8]bgp 3 [r8-bgp]ne [r8-bgp]network 10.1.2.0 24
R7 normally learns that it should be passed to R4R6, but R4R6 is not good. Then we come to R7 to modify the next hop for our neighbors
[r7]bgp 64513 [r7-bgp]peer 172.16.4.1 next-hop-local [r7-bgp]peer 172.16.6.1 next-hop-local
Test:
But if you go directly to ping10 1.2.1 there is a past route, but it can't come back.
Announce 2 and 7 empty interface routes:
Both sides should announce. If one side and the other side want to access the route in the black hole, because the ospf table does not have this route, it will find the BGP table. If it finds that there is, the traffic will be lost on that side. If you think so, it can't be done. You must set it on both sides.
[r2]ip route-static 172.16.0.0 21 NULL 0 [r2]bgp 64512 [r2-bgp]network 172.16.0.0 21 [r7]ip route-static 172.16.0.0 21 NULL 0 [r7]bgp 64513 [r7-bgp]network 172.16.0.0 21
192.168.1.0 and 192.168.2.0 are required to pass, so we can just call GRE
The premise of playing GRE is that there should be a link on both sides
ping -a 10.1.1.1 10.1.2.1 power on
R1:
interface Tunnel0/0/0 ip address 10.1.3.1 255.255.255.0 tunnel-protocol gre source 10.1.1.1 destination 10.1.2.1
R8:
interface Tunnel0/0/0 ip address 10.1.3.2 255.255.255.0 tunnel-protocol gre source 10.1.2.1 destination 10.1.1.1
R8 ping 10.1.3.1 indicates that tunnelkou has been connected
Now go to R1R8 and write a static message
[r1]ip route-static 192.168.2.0 24 10.1.3.2 [r8]ip route-static 192.168.1.0 24 Tunnel 0/0/0
Test:
The experiment is complete!