BGP routing experiment

Test environment topology

insert image description here
Remember to restore the initial state after each rule is tested! !
The BGP Router_ID of each device is the address of loopback 0.

AR1 configuration

[V200R003C00]
#
 sysname AR1
#
interface GigabitEthernet0/0/0
 ip address 10.1.12.1 255.255.255.0 
#
interface LoopBack0
 ip address 1.1.1.1 255.255.255.255 
#
interface LoopBack66
 ip address 66.66.66.66 255.255.255.255 
#
bgp 100
 router-id 1.1.1.1
 peer 10.1.12.2 as-number 200 
 #
 ipv4-family unicast
  undo synchronization
  peer 10.1.12.2 enable
#

AR2 configuration

[V200R003C00]
#
 sysname AR2
#
interface GigabitEthernet0/0/0
 ip address 10.1.12.2 255.255.255.0 
#
interface GigabitEthernet0/0/1
 ip address 10.1.23.2 255.255.255.0 
#
interface LoopBack0
 ip address 2.2.2.2 255.255.255.255 
#
bgp 200
 router-id 2.2.2.2
 peer 3.3.3.3 as-number 200 
 peer 3.3.3.3 connect-interface LoopBack0
 peer 10.1.12.1 as-number 100 
 #
 ipv4-family unicast
  undo synchronization
  peer 3.3.3.3 enable
  peer 3.3.3.3 next-hop-local 
  peer 10.1.12.1 enable
#
ospf 1 router-id 2.2.2.2 
 area 0.0.0.0 
  network 2.2.2.2 0.0.0.0 
  network 10.1.23.2 0.0.0.0 
#
return

AR3 configuration

[V200R003C00]
#
 sysname AR3
#
interface GigabitEthernet0/0/0
 ip address 10.1.23.3 255.255.255.0 
#
interface GigabitEthernet0/0/1
 ip address 10.1.34.3 255.255.255.0 
#
interface LoopBack0
 ip address 3.3.3.3 255.255.255.255 
#
bgp 200
 router-id 3.3.3.3
 peer 2.2.2.2 as-number 200 
 peer 2.2.2.2 connect-interface LoopBack0
 peer 4.4.4.4 as-number 200 
 peer 4.4.4.4 connect-interface LoopBack0
 #
 ipv4-family unicast
  undo synchronization
  peer 2.2.2.2 enable
  peer 4.4.4.4 enable
#
ospf 1 router-id 3.3.3.3 
 area 0.0.0.0 
  network 3.3.3.3 0.0.0.0 
  network 10.1.23.3 0.0.0.0 
  network 10.1.34.3 0.0.0.0 
#

AR4 configuration

[V200R003C00]
#
 sysname AR4
#
interface GigabitEthernet0/0/0
 ip address 10.1.45.4 255.255.255.0 
#
interface GigabitEthernet0/0/1
 ip address 10.1.34.4 255.255.255.0 
#
interface LoopBack0
 ip address 4.4.4.4 255.255.255.255 
#
bgp 200
 router-id 4.4.4.4
 peer 3.3.3.3 as-number 200 
 peer 3.3.3.3 connect-interface LoopBack0
 peer 10.1.45.5 as-number 300 
 #
 ipv4-family unicast
  undo synchronization
  peer 3.3.3.3 enable
  peer 3.3.3.3 next-hop-local 
  peer 10.1.45.5 enable
#
ospf 1 router-id 4.4.4.4 
 area 0.0.0.0 
  network 4.4.4.4 0.0.0.0 
  network 10.1.34.4 0.0.0.0 
#

AR5 configuration

[V200R003C00]
#
 sysname AR5
#
interface GigabitEthernet0/0/0
 ip address 10.1.45.5 255.255.255.0 
#
interface LoopBack0
 ip address 5.5.5.5 255.255.255.255 
#
interface LoopBack66
 ip address 66.66.66.66 255.255.255.255 
#
bgp 300
 router-id 5.5.5.5
 peer 10.1.45.4 as-number 200 
 #
 ipv4-family unicast
  undo synchronization
  peer 10.1.45.4 enable
#

Discard routes with unreachable next hops

Test Methods:

1. Advertise the loopback66 interface addresses on AR1 and AR5 to BGP.

2. The peer 3.3.3.3 next-hop-local has been configured on AR2 and AR4 to AR3 in advance, so there will be two routes to 66.66.66.66/32 on AR3.

insert image description here

It can be seen that by default, the first 10 of all BGP route selection rules cannot be compared until the route with a smaller Router_ID is matched, so the route of peer 2.2.2.2 is selected, and the route of
4.4.4.4 Marked as valid, but not optimal.
You can check the specific reason through display bgp routing-table 66.66.66.66 32: ( not the preferred Router_ID )
insert image description here

3. Configure undo for next-hop-local on AR2, and observe the routing table of AR3 again.

[AR2-bgp]undo peer 3.3.3.3 next-hop-local

After configuring the above command, you may need to wait for the update cycle to see the change of the path. You can use the following command to refresh:
refresh bgp internal export|import or refresh bgp external export|import.
insert image description here
You can see that the peer 2.2.2.2 is preferred The next hop address of the route is now 10.1.12.1, because the router will send the routing information learned from EBGP to other peers intact, and the peer 3.3.3.3 next-hop-local command is to tell other peers Peers, the route I sent to you, the next hop comes to me. Therefore, 10.1.12.1 is unreachable for AR3, so marking this route as invalid is not an optimal route. Thus, the one sent by peer 4.4.4.4 is selected.

1 Select the route with the largest Preferred-Value

Restore the initial state of the topology and check the BGP routing table information of AR3:
insert image description here

Test Methods:

1. Increase the value of the PrefVal attribute of the routing information from peer 4.4.4.4 on AR3.

[AR3-bgp]peer 4.4.4.4 route-policy PrefVal import 
Route-policy : PrefVal
  permit : 10 (matched counts: 2)
    Apply clauses : 
      apply preferred-value 100   #该路由策略的意思是直接将来自4.4.4.4对等体的所有路由的preferred-value属性值都标记为100

Check the BGP routing table information of AR3.
insert image description here
It can be seen that the PrefVal attribute value of the route from peer 4.4.4.4 is marked as 100 and is selected as the optimal route.
Check the specific reason:
insert image description here
For the route from peer 2.2.2.2, it shows: PreVal is not optimal.

2 Prefer the route with the largest value of the Local-Preference attribute

Restore the original configuration first.
Initial BGP routing information of AR3:
insert image description here
You can see that the initial LocPrf attribute value is 100 by default.

Test Methods:

1. For the route from peer 4.4.4.4 on AR3, adjust its LocPrf to 101.

[AR3-bgp]peer 4.4.4.4 route-policy LocPrf import
#
route-policy LocPrf permit node 10 
 apply local-preference 101 
#

Observe the BGP routing table information of AR3:
insert image description here
You can see that the LocPrf attribute value of the route of peer 4.4.4.4 is marked as 101, and it becomes the optimal route.
Check the specific cause:
insert image description here
the route for peer 2.2.2.2 shows that the Local_Pref is not optimal.

3 Locally originated routes are better than routes learned from peers

The specific rules for local origination are:
Manual Aggregation > Auto Gathering > Network > Import > Routes Learned from Peers
In order to verify the above routing rules, this experiment will verify the matching conditions from the back to the front.
In the initial situation, the BGP routing table information on AR3 is as follows:
insert image description here
You can see from the NextHop information that the routes to 66.66.66.66/32 are from different peers

1. Configure this address on the lo66 interface of AR3, import it into BGP, and check the BGP routing table information of AR3. (test import > learned from peers)

The relevant commands are as follows:

	import-route direct route-policy 66
	
	Route-policy : 66
	  permit : 10 (matched counts: 10)
	    Match clauses : 
	      if-match ip-prefix 66
	    Apply clauses : 
	      apply as-path 200 additive  #确保AR3本地引入的相关属性与其他路与相同
	      apply local-preference 100  #同上
	
	Prefix-list 66
	Permitted 8
	Denied 0
	        index: 10               permit  66.66.66.66/32

Make sure the previous property values ​​(PreVal, LocPrf) are the sameIn the case of: At insert image description here
this point, it can be seen that for the 66.66.66.66/32 entry in the BGP routing table, the route imported by itself is selected as the optimal route.
View specific routing information:
insert image description here

2. Test Network>import> routes learned from peers

Advertise the loopback66 interface address 66.66.66.66/32 configured on AR3 to BGP through Network.
insert image description hereYou can see two routes from the local 66.66.66.66/32, and check the specific routing information:
insert image description here
you can see that the route published by the Network method is optimally selected.

3. Test automatic aggregation is better than Network

In order to make the test more intuitive, the routing entry of 88.0.0.0/8 is now used as the test. Configure a static route ip route-static 88.0.0.0 8 NULL 0 on AR2 and AR4, and import it into BGP.
Advertise a route of 88.0.0.0 8 in AR3BGP, and configure two static routes at the same time:

ip route-static 88.0.0.0 255.0.0.0 NULL0
ip route-static 88.128.0.0 255.128.0.0 NULL0

Observe the AR3BGP routing table information:
insert image description here

To enable automatic aggregation:

[AR3-bgp]summary automatic

insert image description here
At this time, the static route 88.128.0.0/9 will be suppressed after being aggregated and become an invalid route. Check the specific routing information:
insert image description here
you can see that the route that is automatically aggregated is finally selected, and Network is not the optimal route type.

4. Test that manual aggregation is better than automatic aggregation

Keep the previous configuration unchanged, and execute the following command in the BGP view of AR3:

[AR3-bgp]aggregate 88.0.0.0 8 detail-suppressed

Observe the BGP routing table information of AR3:
insert image description here
You can see that there is an additional route of 88.0.0.0 with the next hop of 127.0.0.1.
Check the specific route selection information:
insert image description here
You can see that the manual summary route is preferred.

4 Optimizing the route with the shortest AS_Path

Restore the initial configuration and view the AR3 BGP routing table:
insert image description here

Test Methods:

Add a Path attribute value of 100 to the route from peer 2.2.2.2, making it a suboptimal route:

	[AR3-bgp]peer 2.2.2.2 route-policy 66 import 
	Route-policy : 66
	  permit : 10 (matched counts: 16)
	    Match clauses : 
	      if-match ip-prefix 66
	    Apply clauses : 
	      apply as-path 100 additive

Check the AR3 routing table information:
insert image description here
insert image description here

5 Optimizing the route with the best Origin attribute

Restore the topology initialization configuration, and check the current BGP routing table information of AR3:
insert image description here
As shown in the above figure, the origin attribute corresponding to the route 66.66.66.66/32 declared in Network mode on AR1 and AR5 is i.

  • The Origin property is associated accordingly:
    i - IGP —> Network
    e - EGP —> Can the test be modified through route-policy
    ? - incomplete—> import

Test Methods:

1 Change the origin attribute of the route from peer 2.2.2.2 to EGP using the routing policy.

[AR3-bgp]peer 2.2.2.2 route-policy 66 import
#
route-policy 66 permit node 10 
 apply origin egp 100
#

insert image description here
It can be seen that at this time, the origin attribute of the route of peer 2.2.2.2 is changed to e, and becomes suboptimal

2 Keep the previous configuration, and change the original network mode to import mode to import BGP on AR5.

insert image description here
As shown in the preceding figure, the origin attribute of the route from peer 4.4.4.4 is marked as ? , and becomes a suboptimal path.
insert image description here

6 Prefer the route with the smallest MED attribute value

Restore the initial configuration of the topology and check the BGP routing table information of AR3.
insert image description here

Test Methods:

Change the MED attribute value of the route from peer 2.2.2.2 to 1:

[AR3-bgp]peer 2.2.2.2 route-policy 66 import
#
route-policy 66 permit node 10 
 apply cost 1 
#
[AR3-bgp]compare-different-as-med  #允许比较来自不同AS的路由的MED属性(默认情况下BGP只会对来自同一AS的路由进行MED属性值的比较)

insert image description here
insert image description here

7 Optimizing routes learned from EBGP

Restore the initial configuration and check the routing table information of AR2:
insert image description here

Test Methods:

AR3 also advertises a route 66.66.66.66/32 to BGP, so that AR2 can learn the route from 3.3.3.3 through IBGP.

And make sure that other attributes are the same.

[AR3-bgp]network 66.66.66.66 32 route-policy 66
Route-policy : 66
  permit : 10 (matched counts: 5)
    Apply clauses : 
      apply as-path 200 additive

insert image description here
insert image description here

8 Prefer the route with the smallest IGP metric value to Next-hop

Restore the initial configuration and view the initial BGP routing information of AR3:
insert image description here
You can see that the current IGP cost to the two peers is 1.

Test Methods:

Because AR2, AR3, and AR4 use OSPF as the IGP

Change the OSPF cost of the interface connecting AR3 to AR2 to 10.

	[AR3-GigabitEthernet0/0/0]ospf cost 10

insert image description here

As shown in the preceding figure, after the IGP cost of AR3 reaching peer 2.2.2.2 is changed to 10, it becomes a suboptimal route, prompting: Not the optimal IGP cost.

Extended-BGP route load balancing

Extension:
When none of the previous 8 BGP route matching rules can compare the optimal route, you can set load balancing for this BGP route, and BGP only performs load balancing for routes with the same AS_Path by default .
can use:load-balancing as-path-ignoreInconsistencies in AS_Path are ignored.

In addition, before load balancing is configured, although BGP itself has multiple suboptimal routes, the device will only select the optimal route and put it in the RIB and FIB, as shown in the following figure
insert image description here
: When routing forms load balancing, the system will first determine the type of the optimal route.

If the optimal route is an IBGP route, only the IBGP route participates in load sharing. If the optimal route is an EBGP route, only the EBGP route participates in load sharing. That is, IBGP and EBGP routes to the same destination on the public network cannot form load sharing.

[AR3-bgp]maximum load-balancing ibgp ?  #针对路由的IBGP或EBGP配置负载分担的数量
  INTEGER<1-8>  Specify maximum equal cost routes
[AR3-bgp]load-balancing as-path-ignore  #忽略AS_Path的不一致的路由的负载分担

insert image description here

9 Optimizing the route with the shortest Cluster_List

Restore the initial configuration of the topology.

In the test method, the topology is modified as follows:

1. Cancel the route announcement on AR1 and only announce it on AR5.
2. Configure AR3 as the RR and AR4 as the client of AR3.
3. Configure the IBGP relationship based on the loopback interface between AR2 and AR4.

After the above modification, AR2 will receive the BGP route of AR4 and the BGP route 66.66.66.66/32 reflected from AR3.
By default, the first 8 rules cannot be compared to find the optimal route. In this case, the comparison needs to be made according to the Cluster_List.
insert image description here
insert image description here
As shown in the above figure, the device finally selects the IBGP route from peer 4.4.4.4 as the best route, and for the route from peer 3.3.3.3, it thinks that the Cluster_List from peer 3.3.3.3 is not empty.

In BGP (Border Gateway Protocol), Cluster_List (cluster list) is a routing attribute used to avoid loops. It is used to solve the following situation: when a route reflector (Route Reflector) reflects a route to other reflectors, it may cause a route loop.

In a BGP network, a route reflector is used to simplify the BGP peer relationship between routers. They receive routing information from client routers and reflect it to other client routers. Problems can be encountered when a route reflector sends a route to other reflectors, because routing information may be circulated between different reflectors.

To solve this problem, BGP introduces the Cluster_List attribute. When a route reflector receives a route, it checks the route's Cluster_List property. Cluster_List is an ordered list of cluster identifiers used to track the propagation path of routing information.
In BGP, routers use the Cluster_List attribute to compare and process routing information. The specific comparison method is as follows:

  1. When a route reflector receives a routing message, it first checks whether the Cluster_List attribute is empty. If it is empty, it means that the route is being reflected for the first time, and processing can continue.

  2. If the Cluster_List attribute is not empty, the route reflector checks whether the cluster identifiers in the list contain its own cluster identifier. If the cluster identifier list contains its own identifier, it means that the route has been processed by the current route reflector and will not be forwarded to other reflectors, thus avoiding loops.

  3. If the cluster identifier list does not contain its own identifier, the route reflector will add its own cluster identifier to the end of the Cluster_List attribute, and send the updated routing information to other client routers and reflectors.

  4. When forwarding routing information, the route reflector also needs to update the AS_Path attribute so that other routers can correctly learn the path of the routing information . Normally, the reflector will add its own AS number to the AS_Path property.

10 Prefer the route with the smallest Router_ID

Restore the initial configuration and observe the initial BGP routing information of AR3.
insert image description here
insert image description here
If none of the previous nine rules match, the size of the Router_ID will be compared by default, so the route 2.2.2.2 with the smaller Router_ID is selected.
However, below that rule, there is an underlying rule:If the Originator_ID is carried in the route, the Originator_ID is compared first, and then the Router_ID is compared. Similarly, the route with the smallest Originator_ID value is the best.

Test the Originator_ID property:

In the test diagram of rule 9, you can see an Originator_ID record in the line above Cluster_ID:
insert image description here

Test Methods:

1. Keep the configuration in AS200 unchanged, change AR1 and AR5 to AS200, use OSPF for IGP, and declare their respective loopback0 addresses and interface address segments.
2. AR1 and AR2 are set to IBGP; AR4 and AR5 are set to IBGP.
2. Set AR2 as RR, and AR1 as the client of AR2;
3. Set AR4 as RR, and AR5 as the client of AR2;

After the above changes, AR3 will learn the routes from reflectors AR2 and AR4, but prefer the route from peer 2.2.2.2 because its Originator_ID attribute value is smaller, but it seems difficult to distinguish at this time Is not the Originator_ID election rule in effect.
insert image description here
In the figure above:
From: XXXX (YYYY) are not all Router_ID values, X is the address used when establishing the peer, and Y is the Router_ID of the peer.
Original nexthop: It is the next address of the route. Because peer XXXX next-hop-local is configured on AR1 and AR5, the address of the loopback interface of the next hop of the route is displayed (IBGP established based on the loopback interface).
The Originator_ID is actually the Router_ID of the corresponding peer. After passing through the RR, it will carry the Originator_ID attribute, which is mapped to the Router_ID.

Unconfigure the Router_ID of BGP in the BGP view of AR1, and check the BGP routing table information of AR3 again:
insert image description here
it can be seen that the route from the reflector AR4 becomes optimal at this time, because the value of the Originator_ID attribute is smaller than the value from the reflector AR2 , the prompt information still shows that the Router_ID value is not optimal.

Cancel the BGP Router_ID of AR5, and check the BGP routing table information of AR3 again:
insert image description here
As shown in the figure above, because the Originator attribute is small, the route from reflector 2.2.2.2 is selected as the optimal route, and the prompt message is still: not optimal Router_ID.
It can be seen that Originator_ID is actually equivalent to Router_ID. When carrying this attribute, it is better than Router_ID to compare first.

11 Prefer the route advertised by the peer with the smallest IP address

Change topology information:

insert image description here
Announce on AR5 that 66.66.66.66/32 is in the same AS200, AR5 and AR2 are set to IBGP, and AR5 and AR4 are set to IBGP.
Set AR2 and AR4 as RRs, and AR5 as their clients respectively.
After the above changes, there will be two routes on AR3, and the previous 10 routing rules cannot compare the optimal route. In this case, the route of the peer (2.2.2.2) with a smaller IP address will be selected:
10.1.23.2 < 10.1.34.4
insert image description here

Guess you like

Origin blog.csdn.net/Sakura0156/article/details/130767381