No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OSPF Neighbor Relationship Failed to Be Established After a Security Policy Is Configured on an NE40E

Publication Date:  2012-07-27 Views:  50 Downloads:  0
Issue Description
 Network topology:
OSPF peer
NE40E (GE 1/0/0)---optical fiber―C device (router ID: 125.88.103.1)
The OSPF neighbor relationship fails to be established between two OSPF neighbors connected by an optical fiber.
Directly-connected interfaces ping each other successfully. 
 
Alarm Information
 Null 
Handling Process
 1. Check the direct link.
The link is checked and there is no fault.
2. Check the interface hardware.
Another interface on the NE40E is used but the neighbor relationship still fails to be established between the NE40E and the C device.
3. Check the configurations such as OSPF parameters.
After a check, OSPF configurations including OSPF parameters are correct.
The debug ospf packet command is run on the NE40E. The NE40E fails to receive OSPF packets sent by the C device. The debug ip ospf packet command is run to check whether the C device can send OSPF packets or not. The command output shows that the C device sends OSPF packets properly.
Capture and analyze packets on the NE40E. The result shows that GE 1/0/0 on the NE40E has received OSPF packets from the C device.
Although the NE40E has received OSPF packets from the C device, the NE40E directly discards the packets but does not send them to the CPU.
In either of the following situations, the NE40E discards packets:
1. OSPF packets fail to match the rule defined in a filtering policy.
2. The hardware becomes defective.
In the configurations on the NE40E, an anti-attack policy has been configured, in which the router ID of the C device is not listed in ACL 3000. After the router ID of the C device is added to ACL 3000, the OSPF neighbor relationship can be successfully established between the NE40E and the C device.
acl number 3000 //OSPF and BGP packets are distinguished based on the source address and port number defined in ACL rules. All matched packets are added to the whitelist. (Note: For detailed configurations of policies, see the attachment.)
rule 5 permit ospf source 125.88.103.1 0 //The router ID of the C device is added to the ACL rule. Before this, as the C device is not permitted on the NE40E, the NE40E discards the OSPF packets sent by the C device.
rule 10 permit ospf source 125.88.103.3 0
rule 15 permit ospf source 61.140.7.226 0
rule 20 permit ospf source 61.140.7.227 0
rule 25 permit ospf source 61.140.7.228 0
rule 30 permit ospf source 202.97.25.9 0
rule 35 permit tcp source 59.37.70.105 0 source-port eq bgp
rule 40 permit tcp source 59.37.70.105 0 destination-port eq bgp
rule 45 permit tcp source 61.152.80.133 0 source-port eq bgp
rule 50 permit tcp source 61.152.80.133 0 destination-port eq bgp
rule 55 permit tcp source 202.97.28.1 0 source-port eq bgp
rule 60 permit tcp source 202.97.28.1 0 destination-port eq bgp
rule 65 permit tcp source 202.97.28.3 0 source-port eq bgp
rule 70 permit tcp source 202.97.28.3 0 destination-port eq bgp 
 
Root Cause
 1. The direct link becomes defective.
2. The interface hardware becomes defective.
3. The configurations such as OSPF parameters are incorrect. 
 
Suggestions
 As the anti-attack policy is not applied to an interface of an NE40E, the ACL rules in the whitelist and blacklist must be correct; otherwise, services on the LPU where the interface with the policy resides are affected.
An example for typically configuring a security policy on the NE40E/80E is provided in the attachment. 
 

END