BGP route

 Hi Sprout,

This is a rule for BGP route selection. If the prefix and next hop of the received BGP route are the same, the route is not preferentially selected as the optimal route.

In Huawei documents, such a route is called a supernet route.

 The description is as follows:

A BGP supernet route has the same destination address and next hop address or has a more detailed destination address than the next hop address. Any route that meets one of the following conditions is a BGP supernet route.

·         If you perform bitwise AND operations on the destination address mask with the destination address and next hop address, respectively, the calculated network addresses are the same, and the destination address mask is greater than or equal to the next hop address mask.

·         If you perform bitwise AND operations on the destination address mask with the destination address and next hop address, respectively, the calculated network addresses are different. However, if you perform bitwise AND operations on the next hop address mask with the destination address and next hop address, respectively, the calculated network addresses are the same.

By default, when a BGP device receives a BGP supernet unicast route, the BGP device sets the route invalid and does not advertise it to other BGP peers. If a Huawei device is connected to a non-Huawei device and you want the Huawei device to advertise BGP supernet unicast routes that it receives from the non-Huawei device to other BGP peers, configure the Huawei device to advertise BGP supernet unicast routes to BGP peers.

You can use the supernet unicast advertise enable command to configure a BGP device to advertise BGP supernet unicast routes to its peers.

Refer to https://support.huawei.com/hedex/hdx.do?docid=EDOC1100069307&id=supernet_unicast_advertise&text=null&lang=en 

In the eNSP, the ARs don’t support this command,you can replace the routers with NE series

Posted by ViktorG at 2019-10-30 12:33Hello @Sprout !In your situation the all the routes should be present as OSPF routes as it is announ ...

Thank you for your reply. I think this is not a route preference issue. However, as you suggested, changing the next hop is indeed an effective method. When the next-hop of 1.1.1.1 is changed on R2, R3 can correctly receive this route.