S6520-24ST-SI-GL needs long routing time after ospf is established

H3C LS6520-24ST-SI-GL=====Cisco Switch  

H3C Comware Software, Version 7.1.070, Release 6312

This equipment is connected to Cisco equipment, using vlan-int 800 for interconnection.
interface Vlan-interface800
ip address 10.37.131.2 255.255.255.252
ospf mtu-enable//Delete and prompt that mtu does not match

Message from other side:
05-Mar-2020 22:21:28 %OSPF-W-RXBAD: Packet RX on interface 10.37.131.1 from 10.37.131.2 type DB DSC-MTU mismatch
05-Mar-2020 22:22:58 %OSPF-W-RXBAD: Packet RX on interface 10.37.131.1 from 10.37.131.2 type DB DSC-MTU mismatch    

It took more than an hour to establish an ospf neighbor,
The first debugg, you can see that it only takes 17 seconds for the device to establish a neighbor:
<h3c-bog53k3>%Jun 23 05:12:38:329 2020 h3c-bog53k3 OSPF/5/OSPF_NBR_CHG: OSPF 1 Neighbor 10.37.131.1(Vlan-interface800) changed from FULL to DOWN.
%Jun 23 05:12:55:626 2020 h3c-bog53k3 OSPF/5/OSPF_NBR_CHG: OSPF 1 Neighbor 10.37.131.1(Vlan-interface800) changed from LOADING to FULL.

Second debugg
It is still 17 seconds to see the neighbor establishment, but it takes a long time to learn the routing table in the domain. The complete process:
<h3c-bog53k3>reset ospf process
Before pressing ENTER you must choose'YES' or'NO'[Y/N]:y
<h3c-bog53k3>%Jun 24 23:04:56:446 2020 h3c-bog53k3 OSPF/5/OSPF_NBR_CHG: OSPF 1 Neighbor 10.37.131.1(Vlan-interface800) changed from FULL to DOWN.
%Jun 24 23:05:13:586 2020 h3c-bog53k3 OSPF/5/OSPF_NBR_CHG: OSPF 1 Neighbor 10.37.131.1(Vlan-interface800) changed from LOADING to FULL.
Since then, the following has been prompted, and the routing table has been 21:
*Jun 24 23:05:14:522 2020 h3c-bog53k3 OSPF/7/DEBUG: LSA age: 4 Options: External routing:OFF.

Destinations: 21 Routes: 21

Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0
10.35.11.64/26 Direct 0 0 10.35.11.65 Vlan2020
10.35.11.64/32 Direct 0 0 10.35.11.65 Vlan2020
10.35.11.65/32 Direct 0 0 127.0.0.1 InLoop0

The intra-domain routing does not appear until around 23:35:
<h3c-bog53k3>show ip routing-table

Destinations: 505 Routes: 505

Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 O_INTER 10 17 10.37.131.1 Vlan800
0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0
10.32.0.40/29 O_INTRA 10 15 10.37.131.1 Vlan800
10.32.9.0/24 O_INTRA 10 44 10.37.131.1 Vlan800
10.32.13.128/25 O_INTRA 10 44 10.37.131.1 Vlan800
10.32.26.0/25 O_INTRA 10 29 10.37.131.1 Vlan800

LSA age: age Options: External routing: ON/OFF LSA header information:
• age: LSA age field
• ON/OFF: indicates that external routing is supported or not  

Positioning progress:
The router-id of our company's equipment is larger than that of Cisco. When the dd message is exchanged during the neighbor establishment process, our company is the master and the Cisco equipment is the slave.

After collecting debug information many times, the following phenomena are found:
In the early stage, the main and standby elections of our equipment and Cisco equipment are normal. Our company is the master and Cisco is the slave. Our company leads the dd exchange. When our company sends the last dd message, the more flag is set to 0, indicating that the current is the last A packet was subsequently received from a Cisco device's dd packet, and the more flag was also 0. Therefore, our device ended the dd interaction phase, and the neighbor status moved out from exchange and eventually rose to full.
After the Cisco device sends the packet with more marked as 0, it still sends dd packets uninterruptedly, and prints the log Retransmit DB DSC xxxxxx, indicating that dd is retransmitted. This behavior does not comply with the rfc regulations. According to the RFC, only the master can Actively initiate a dd message, and the slave can only respond.
After the Cisco device continuously retransmitted the dd message for more than 20 minutes, it switched to the full state and sent the remaining part of the lsa to our device.

After analysis, our equipment could not learn the route within a period of just resetting. This is because Cisco equipment did not send network lsa to our equipment. As a result, the topology of our equipment was incomplete and could not be calculated during spf-tree calculation. Unable to figure out the route.
After more than 20 minutes, the Cisco equipment synchronized the remaining lsa with our equipment, the topology tree of our equipment became complete, and the routing calculation was normal.

In terms of the environment, the router-id of our company’s equipment has been modified and changed to a router-id smaller than that of Cisco. At this time, the Cisco device is the master during dd interaction. At this time, the dd message interaction is normal, and Cisco sends to our equipment normally. lsa, the problem has been circumvented. After repeatedly resetting the ospf process of our equipment, we can learn the route quickly. After the router-id is changed back, the problem will surely appear.

Therefore, the problem is because Cisco did not negotiate the neighbor state machine according to the agreement, and the Cisco equipment failed to synchronize all the lsa with our equipment, which caused our equipment to be unable to calculate the spf tree and routing, and the subsequent Cisco equipment recovered and synchronized by itself lsa, our equipment is back to normal.  

1. Modify the router-id of our equipment to be smaller than Cisco 

2. Upgrade the Cisco switch version to resolve