Advice for NSa3700 drops/ignores OSFP IPv4 routing
GMP
Newbie ✭
I have a NSa3700 pair where the primary stops using OSPF IPv4 route data. Traffic stops because IP Spoofing check incoming traffic against known routes. When the routes are ignored, all traffic from inside the company is dropped. The firewall logs show "IP spoof dropped".
- Quick Fix: Reboot the SonicWall, which is enough to switch to the secondary. OSPF works again and traffic flows.
- Longer Fix: Install static routes
- ?? Is there a way to just restart the OSPF process?
The NSa3700 pairs replaced NSA3650 pairs. The conversion tool at mysonicwall.com was used to copy the configuration. In the 3650 OSPF worked flawlessly, so it took a while to understand the fault.
Details
- firmware-version "SonicOS 7.0.1-5145"
- rom-version 7.0.1.3
- CLI "show routing ospf" shows the expected content
- CLI "show routing ospf neighbor" shows the other routers in the network, which are Cisco ISR4331 routers
- CLI "show routing ospf routes" lists the expected routes
- CLI "show routing ospf database" shows the correct information, now after rebooting. I did not check during the failure.
Most Recent Occurrence: Multiple sites are connected via a Comcast ENS network. The SonicWalls and Cisco routers all have addresses on the same network 192.168.154.0/24. One router was offline for 2 hours due to fiber repairs in the city. When the fiber was repaired and the router rejoined the network one SonicWall pair stopped using the OSPF data. ??
- Has anyone had a similar OSPF instability?
- Does running IPv6 and IPv4 together make the issue worse?
- Do you have any suggestions?
Thanks
Best Answers
-
OptionsCORRECT ANSWERGMP
Newbie ✭
An OSPF issue appeared when updated another SonicWall pair to SonicOS 7.1.1-7047-R5557.
After the upgrade, the SonicOS would not form a relationship with the OSPF DR and BDR. The OSPF DR and BDR routers were constantly in a EXCHANGE/DROTHER state.
10.1.xxx.xx 1 EXCHANGE/DROTHER00:00:31 192.168.xxx.xx GigabitEthernet0/0/1
- The effect was that the SonicWall IP addresses and default route were never advertised to the rest of the company.
- The only work around was to ‘clear ip ospf process’ on the OSPF DR router. Usually just 1 execution of the command was needed.
- FIX – Drop mtu-ignore
- Drop mtu-ignore in the SonicWall configuration
- Drop mtu-ignore in every running Cisco ISR router.
- The line is in the configuration of interface Gi 0/0/1, which connects to the internal network.
1 -
OptionsCORRECT ANSWERGMP
Newbie ✭
OSPF to Dell S5224-ON switches.
OSPF to Cisco ISR Routers.
- I stabilized the OSPF IPv4 relationship between NSa3700 and Cisco ISR4431 and ISR4331 routers by dropping "ip ospf mtu-ignore" in the SonicWall and in the Cisco ISR router.
OSPF to Dell S5224F-ON Routers.
- I stabilized the OSPF IPv4 relationship between NSa3700 and a pair of Dell S5224F-ON switches (L3 switch) by
- * dropping "ip ospf mtu-ignore" in the SonicWall
- * keeping "ip ospf mtu-ignore" in the Dell S5224F-ON switches.
- When I dropped "ip ospf mtu-ignore" in the 3700 and the switches, the switches were stuck in an EXSTART/DR and EXSTART/BDR state. Adding "ip ospf mtu-ignore" to the Dell switches (not the NSa3700) resulted in an immediate change to FULL/DR and FULL/BDR.
1
Answers
Thank you for the URL. I had looked a few days ago and did not see the specific cables that worked for the 3650.
The cables are
I was delayed in responding since I was chasing unusual routing issues in the 3700 SonicWall. I have opened Case 44393312 about OSPF issues in the 3700.
I have other cables that worked with the 3650 and will check those out early next week.
https://www.sonicwall.com/support/knowledge-base/supported-sonicwall-and-3rd-party-sfp-and-sfp-modules-that-can-be-used-with-sonicwall-nsa-series/211109111458350/
Thanks
Greg
My suggestion would be to not use the config conversion tool, it has bitten me too many times and have run into weird random issues after using it.
That said my recommendations (since you have an HA setup):
1: Failover to the HA appliance, and let it run as the active unit. If OSPF issues continue you can rule out a hardware issue on the primary.
2: Failover to the HA appliance, remove the primary from production, factory default and manually set up the primary. Put primary into production without the HA unit during the next maintenance window. If a clean, rebuilt config is stable than you know the conversion tool messed something up, and can re-setup HA at your convenience.
3: Wait for support.
Disclosure: I do not have any Gen 7's doing OSPF yet, all of them are still Gen 6's.
Thank you, TKWITS, You wrote some good suggestions.
I found the conversion tool from V6 to V7 to be very good. The address objects, address groups, routing rules and access rules look right. The custom settings and route map for the BGP section of a VPN tunnel came over perfectly.
Thank you for your suggestions. I'll keep the community posted if we find a resolution.
Hi @gmp, not sure if you have done already as I didn't see it mentioned in the previous threads, you can turn off the IP Spoof checking in the Diag page if it is this that is causing the issue or is it just showing IP spoof when the routes are failing?
Thanks, Preston.
The IP Spoof appears only when the SonicWall stops routing correctly.
Your comment may lead to a diagnostic. If I can get to the SonicWall during an episode, I can turn of Spoof testing. If traffic resumes, the routing is good and the Spoof test is broken.
Next week, I will try some tests to see if I can make the issue appear on demand. (I'll probably try adding and removing an OSPF router on the network)
Thanks