Are the MTUs in the DD packets exchanged to establish an OSPF neighbor relationship checked

4

When the interfaces are configured with different MTUs, OSPF can normally set up the neighbor relationship. By default, OSPF does not check the MTUs in DD packets.

When the ospf mtu-enable command is run on an interface, the OSPF neighbor relationship cannot be set up when the MTUs in the DD packets are inconsistent with the one set on the interface. In this case, the MTUs in the DD packets need to be checked. If the MTU in a DD packet is greater than the MTU set on the interface, the interface discards the DD packet.

Other related questions:
MTU value of OSPF DD packets sent by S series switches
According to RFC 2328, the value of the Interface MTU field in a DD packet is the MTU value of the link (if the link is a virtual link, the value is 0). When a device receives a DD packet with an Interface MTU value larger than the MTU value in DD packets sent by the device, the device drops the DD packet and the neighbor status stays Exchange Start. On an S series switch supporting OSPF, you can run the ospf mtu-enable command in an interface view to check the MTU value in received DD packets. By default, OSPF does not check the MTU value in a DD packet. If the MTU match check is not performed, LSDBs of the two ends can be synchronized and the OSPF neighbor relationship can enter the Full state with the MTU values configured on the two ends varying slightly.

Can OSPF establish a neighbor relationship by using the secondary IP address
In OSPF, a neighbor relationship cannot be established by using the secondary IP address; instead, a neighbor relationship can be established only by using the primary address of an interface. If the network to which the secondary IP address belongs is added to the OSPF configuration, however, the corresponding route can be advertised.

Can an OSPF neighbor relationship be established between devices that are on different subnets
A neighbor relationship can be established between two routers that are not on the same subnet only when the devices are connected through point-to-point (P2P) links. On a Point-to-Multipoint (P2MP) network, you can determine whether adjacencies can be formed between neighbors that are not on the same subnet. In all other cases, the devices must be on the same subnet.

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.

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