| area0 |
| | area2
| area2 |
In the above networking:
The interfaces connecting wgzx_ne80 and lt_ne80 are enabled with OSPF in area0.
The interfaces connecting wgzx_ne80 and fz_ne40 are enabled with OSPF in area0.
The interfaces connecting lt_ne80 and lt_ne16e are enabled with OSPF in area0.
The interfaces connecting fz_ne40 and lt_ne16e are enabled with OSPF in area0.
All other interfaces are enabled with OSPF in area2.
According to the feedback from the customer, the link between lt_ne16e and jx_ne05 was congested. The tracert result shows that the traffic from yh_ne05 to wgzx_ne80 flows along the following path:
However, the traffic from yh_ne05 to wgzx_ne80 flows along another path: wgzx_ne80--->fz_ne40--->jx_ne20--->jx_ne05--->lt_ne16e-->yh_ne05
Define two sub-interfaces at each end of the link between lt_ne16e and fz_ne40. One sub-interface works in area0, and the other sub-interface works in area2.
As for the routing from yh_ne05 to wgzx_ne8:
When packets arrive at lt_ne16e, they take the path in area 0, as the intra-area route is preferred based on the routes generated by the LSDB. This path is correct.
As for the routing from wgzx_ne80 to yh_ne05:
Packets arrive at wgzx_ne80. The interfaces connecting lt_ne16e and fz_ne40 work in area 0. The LSDB on the ABR now generates two routes. One is in the backbone area, and the other is in the non-backbone area. Based on the definition in the corresponding RFC, if there are routes in both the backbone area and the non-backbone area, the route in the non-backbone area is preferred to lighten the workload of the backbone area. As a result, the packets enter area2. The devices in area2, jx_ne05 and lt_ne16e, adopt the 4 x 2 Mbit/s link, whose bandwidth is lower than the FE and GE bandwidth in area0. Thus, the link is congested.
The principle of OSPF routing should be taken into full consideration during the planning of the networking so that the traffic distribution can be controlled.