The networking is as follows:
Two NE80Es, which serve as the core equipment of the MAN, connect to the equipment on J-A and J-B provincial networks respectively. Both the NE80Es and the equipment on the provincial networks run BGP. The NE80Es and the NE40 run BGP+OSPF. The NE80Es on the MAN export the default route 0.0.0.0 to the OSPF domain. The four equal-cost paths of the NE40 share the load.
The loopback IP address of QJ-NE80E is 10.10.0.2, the loopback IP address of SN-NE80E is 10.10.0.1, and the loopback IP address of the NE40 is 10.10.0.15.
Symptom of the fault:
When the link connecting the NE40 to SN-NE80E is Up, all the outgoing traffic flows to this link.
Log in to the NE40 to view the routes. It turns out that four default routes of the NE40 point to four ports respectively. View the FIB information of the default routes on the board. The information is believed to be normal.
Shut down one link to SN-NE80E. The fault, however, persists. Shut down another link to SN-NE80E. Then the traffic is normally shared among the other three links.
Contact the customer to learn which websites are hard to access. The execution of the tracert command finds that the route to the destination address covers the link connecting the NE40 to SN-NE80E. Run the display ip rout x.x.x.x command. It is found that this route is learned through BGP, the destination IP address does not match the default route, and the next hop is SN-NE80E at 10.10.0.1.
Run the display bgp peer command to view BGP neighbors. The information displayed shows that the IP address of one BGP neighbor is 10.10.0.1 and that of the other is 10.10.0.2. According to the BGP routing principle, when other attributes of the neighbors are the same, BGP selects the neighbor with a smaller IP address. Therefore, the next hops of the routes learned by the NE40 through BGP all point to 10.10.0.1. This explains why all the traffic flows to the link to SN-NE80E.
From the customer, we learn that the NE40 runs only MBGP rather than ordinary BGP. Shut down BGPv4 neighbors so that only MBGP neighbors exist. After that, the outgoing traffic of the four links of the NE40 resume to normal. The fault is thus rectified.
1. Incorrect route calculation
2. Problem related to the hash algorithm of the NE40 for load sharing
3. Routing problem of the NE40
For route problems, do not neglect the cooperation between multiple protocols.