Problem and solution when routes with the same network address but different masks cannot be imported in OSPF on the USG

4

The reason that routes with the same network address but different masks cannot be imported in OSPF on the USG is as follows;
VRP3.0-based products do not support the features defined in RFC2328 Appendix E. Because VRP3.0 uses a network address as an LS identifier, only the first route among the routes with the same network address can be imported to OSPF.

Other related questions:
Why does the USG OSPF not be able to import multiple routes with the same mask for the same network address?
In the USG, you can not import multiple routes with the same mask as the same mask. Because products based on the VRP3.0 platform do not support the features defined in RFC2328 Appendix E. VRP3.0 uses the network address as the LS. When multiple routes with the same network address need to be imported, only the first route can be imported, and the rest is duplicated.

Why cannot OSPF import BGP routes
As defined in RFC 1364, OSPF cannot import IBGP routes. Routes learned via IBGP must not be imported into OSPF OSPF, however, can import IBGP routes on a PE. BGP routes exist in a VPNv4 routing table on a device functioning as a PE but cannot be imported to OSPF. This is because the role of the device changes from a PE to an MCE after the vpn-instance-capability simple command in run in the OSPF process. Solution: If the device needs to function as a PE, you need to run the undo vpn-instance-capability command on the device.

Problem and solution when an OSPF route filtering policy does not take effect
The reason that an OSPF route filtering policy does not take effect is as follows: For example: User ---------- MA5200F ---------- Firewall---------- NE80 ---------- Internet Open Shortest Path First (OSPF) is run on three devices, and the firewall acts as the NAT device. The NE80E cannot learn routes to private network segments. Firewall configurations are as follows: acl number 2999 rule 5 deny source 10.0.0.0 0.255.255.255 /*Filtered private network segments*/ rule 10 deny source 192.168.0.0 0.0.255.255 /*Filtered private network segments*/ rule 15 permit ospf 1 filter-policy export 2999 area 0.0.0.0 network 218.206.107.220 0.0.0.3 The routing table of the NE80 still has routes to private network segments. [JSNJ-MB-CMNET-RT01-HJL_NE80]display ip routing-table 10.33.16.192 Destination/Mask Protocol Pre Cost Nexthop Interface 10.33.16.192/26 O_ASE 50 1 218.206.97.234 Ethernet5/0/13 0.0.0.0/0 STATIC 40 0 218.206.97.109 GigabitEthernet1/0/ The route policy in the OSPF view of the firewall that uses the VRP3.30 platform takes effect only for local routes, not the LSA transmitted by the firewall to the NE80. In conclusion, because OSPF is a dynamic routing protocol based on link status and routing information is expressed through link status, OSPF cannot filter advertised or received LSAs. The filter-policy import command filters the routes calculated by OSPF. Only routes that match the filtering conditions are added to the routing table. The filter-policy export command enables a device to filter routes advertised by the device. Only routes that match the filtering conditions can be advertised.

Problem and solution when the OSPF status is abnormal
To solve the problem that the OSPF status between the firewall and the peer device cannot reach the Full state, perform the following steps: 1. Check the OSPF status. Check whether the OSPF neighboring relationship can be established between the firewall and the peer device. 2. If no, check the security policy configuration. Check whether the security policy control function for unicast packets is enabled. That is, check whether the firewall packet-filter basic-protocol enable command is configured. If yes, run the undo firewall packet-filter basic-protocol enable command to disable the function. To establish an OSPF neighboring relationship, devices need to exchange DD packets. DD packets are OSPF unicast packets. By default, the forwarding of OSPF unicast packets is not controlled by security policies. However, if you run the firewall packet-filter basic-protocol enable command to enable the security policy control function for OSPF unicast packets, you need also to configure the corresponding security policy to allow the packets to be forwarded. For details, see OSPF can not step into full state caused by security policy deny.

What are route selection rules if OSPF imports external routes with the same prefix
OSPF can import Type 1 and Type 2 external routes. By default, OSPF imports Type 2 external routes. If a Type 1 external route is imported, the cost contained in the corresponding LSA and the cost of the Type 1 external route are used for route calculation. If a Type 2 external route is imported, the cost of the Type 2 external route is much larger than the cost of an OSPF internal route. Therefore, only the cost of the corresponding LSA is used for route calculation. Route selection rules are described below if OSPF imports Type 1 external routes with the same prefix: Costs (cost of a route to the ASBR+cost contained in the corresponding LSA) of the imported routes are compared. The route with a smaller cost is preferred. If the route costs are the same, the corresponding LSA types are compared. The route that is imported using a Type 5 LSA is preferred. Route selection rules are described below if OSPF imports Type 2 external routes with the same prefix: The costs contained in the LSAs that are used to import the routes are compared. The route that is imported using the LSA with a smaller cost is preferred. If the costs in LSAs are the same, the costs of the routes to the ASBR are compared. The route with a smaller cost is preferred. If the costs of the routes to the ASBR are the same, the corresponding LSA types are compared. The route that is imported using a Type 5 LSA is preferred.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top