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 remains in Exstart phase on USG firewall

Publication Date:  2015-12-01 Views:  120 Downloads:  0
Issue Description

 OSPF cannot be established between the USG NGFW and a AR router when the devices are connected by an Ethernet link and the ospf configuration is correct on both devices. After brief troubleshooting we can notice that the OSPF adjacency is not going to FULL state between the devices and it stucks into Exstart stage. Another interesting aspect is the fact that FULL adjacency is established between the devices if the network type of the Ethernet interface is changed from the default broadcast type to point-to-point.

 


 
Firewall configuration:
#
interface GigabitEthernet3/0/1
ip address 10.90.41.1 255.255.255.252
ospf cost 20
#
ospf 90 router-id 1.1.1.1
area 0.0.0.10
  network 10.90.41.0 0.0.0.3

Router configuration:
interface GigabitEthernet0/0/9
ip address 10.90.41.2 255.255.255.252
#
ospf 90 router-id 2.2.2.2
area 0.0.0.10
  network 10.90.41.0 0.0.0.3


Result:
<Router>display ospf peer brief

         OSPF Process 90 with Router ID 2.2.2.2
                  Peer Statistic Information
----------------------------------------------------------------------------
Area Id          Interface                        Neighbor id      State   
0.0.0.10         GigabitEthernet0/0/9             1.1.1.1     ExStart    
After changing the network type of the interface to point-to-point on both devices we can see OSPF going into FULL state:
Firewall configuration change:
#
interface GigabitEthernet3/0/1
  ospf network-type p2p
Router configuration changes:
interface GigabitEthernet0/0/9
  ospf network-type p2p

[Router]display ospf peer brief

         OSPF Process 90 with Router ID 2.2.2.2
                  Peer Statistic Information
----------------------------------------------------------------------------
Area Id          Interface                        Neighbor id      State   
0.0.0.10         GigabitEthernet0/0/9             1.1.1.1     FULL    

Handling Process
Collected debugging information from the devices/firewall in both scenarios  by running the following commands:
Terminal monitor
Terminal debugging
Debugging ospf packet
Root Cause
According to the debugging information we can state:
• In the first case where the network type of the interface is broadcast, the DB description packets are sent as unicast to the firewall and the firewall will filter the DB description packet according to the security policies. In this situation , the OSPF process does not go further than the Exstart stage because the security policies of the firewall were not  allowing traffic exchange between the local zone of the firewall and the zone to which the ospf enabled interface belonged.


OSPF 90: SEND Packet. Interface: GigabitEthernet0/0/9
<UK-BIZ-S5720HI-02>
Aug 25 2015 17:22:29.420.2 UK-BIZ-S5720HI-02 RM/6/RMDEBUG:  Source Address: 10.90.41.2
<UK-BIZ-S5720HI-02>
Aug 25 2015 17:22:29.420.3 UK-BIZ-S5720HI-02 RM/6/RMDEBUG:  Destination Address: 10.90.41.1
<UK-BIZ-S5720HI-02>
Aug 25 2015 17:22:29.420.4 UK-BIZ-S5720HI-02 RM/6/RMDEBUG:  Ver# 2, Type: 2 (DB Description)
<UK-BIZ-S5720HI-02>

The OSPF process went to the Exstart stage in the first place because OSPF has been enabled on the interface and in this case the firewall will be listening to the OSPF multicast group 224.0.0.5 and  won’t drop the hello packets sent to this group even though no security policy has been configured in this way. Given the fact that the destination of the hello packets is the multicast group, the firewall will make 2-WAY adjacency with the switch and would try to go to Exstart .

• In the second case, where the network type is set to point to point, the DB description packets will be sent as multicast to the 224.0.0.5 destination . According to the same principle as above, the firewall will accept the DB description packet because it is not sent as unicast to the IP address of the interface and won’t drop the packet, being able to continue to FULL  state.

OSPF 90: SEND Packet. Interface: GigabitEthernet0/0/9
<UK-BIZ-S5720HI-02>
Aug 25 2015 17:18:08.890.2 UK-BIZ-S5720HI-02 RM/6/RMDEBUG:  Source Address: 10.90.41.2
<UK-BIZ-S5720HI-02>
Aug 25 2015 17:18:08.890.3 UK-BIZ-S5720HI-02 RM/6/RMDEBUG:  Destination Address: 224.0.0.5
<UK-BIZ-S5720HI-02>
Aug 25 2015 17:18:08.890.4 UK-BIZ-S5720HI-02 RM/6/RMDEBUG:  Ver# 2, Type: 2 (DB Description)
Solution
-Change the network type of the interface to point-to-point
-Adjust the security policies between the local zone and the zone to which the interface belongs to allow the traffic between the IP address of the firewall and the IP address of the router.

END