Solved

ARP requests not responded to by ISP

Posted on 2011-09-28
11
725 Views
Last Modified: 2012-12-20
I have a situation with a Docsis modem and a SonicWall router. There are 5 IP's connected to the SonicWall.  Every once in a while the IP's get knocked off the air.  The only way I can get them working is to reprogram everything from scratch.  I have tried various things including a brand new SonicWall router which did not work. I have had SonicWall tech support do some testing as well. What we notice is that when we reprogram everything from scratch we send out an ARP request and the ISP responds appropriately. However once an IP goes down we notice that if we send an ARP request out we get no response.  Is there any definitive way to prove that the problem is either at the ISP end (which is what we suspect as this is a new service offering they have) or at our end?  The ISP is recommending that we go to transparent bridging but we have reasons not to  and they have also confirmed that it should work without transparent bridging - they are just 'trying to make it work' but again we don't want transparent bridging - not until we have at least determined which end the problem lies.
0
Comment
Question by:lineonecorp
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
11 Comments
 
LVL 21

Expert Comment

by:Rick_O_Shay
ID: 36814278
Can you do a packet capture with Wireshark or Sniffer showing the ARPs going out to their router but no replies coming back?
0
 
LVL 32

Assisted Solution

by:harbor235
harbor235 earned 300 total points
ID: 36814337

All traffic on a PON gets forwarded to the headend, including ARP requests. Wondering if you are on a oversubscribed PON and they are limiting brodcasts? Also, depending on which device they are using to termnate layer3 for your net, some devices have issue with hairpining gratuitous arps.

All your upstream traffic must be forwarded to the upstream layer3 device, the only way to prove what is going on is to see what that device is or is not doing.


harbor235 ;}  
0
 

Author Comment

by:lineonecorp
ID: 36818082
Rick O Shay:

We've done that - we send out, they don't reply.

harbor235:


" hairpining gratuitous arps" - what exactly is this?
0
Ready to trade in that old firewall?

Whether you need to trade-up to a shiny new Firebox or just ready to upgrade from whatever appliance you're using now, WatchGuard has the right appliance for you! Find your perfect Firebox today with appliance sizing tool!

 
LVL 32

Assisted Solution

by:harbor235
harbor235 earned 300 total points
ID: 36818145


The key point is that not all devices perform the hairpin correctly. The only real way to get to the bottom of it is to do a packet capture on the layer 3 upstream to see what the problems is.

Also, if your PON is oversubscribed your traffic can be dropped at the OLT. I would engage your ISP again and ask what device is at the headend and is your PON oversubscribed.

Can you test out transparent bridging to see if the problem is still there?

Also, if you have 5 systems on your side of the docsis are you using a layer2 device to aggregate those ports? or are you sing the ISP device as well?

harbor235 ;}
0
 

Author Comment

by:lineonecorp
ID: 36818162
Just using a SonicWall NSA 2400 on this side of the Docsis.

What is the 'hairpin'?
0
 
LVL 32

Assisted Solution

by:harbor235
harbor235 earned 300 total points
ID: 36818233


In a PON network all upstream traffic has to go to the headend which in this case is a layer3 device that does routing. Any traffic that wants to go to any other PON or any other layer 2 connected device, it cannot go there directly. It must first goto the headend. But, typical behavior for a layer3 device is to drop traffic it receives from a segment that is destined out the same interface it was received on. So hairpining is changing the behavior of layer3 devices and allow it to receive traffic from an interface and then route it right back out the same interfaces. Make sense? This is how PON networks work.

So you are saying that you see the arp request go out the sonicwall? Is there a packet capture utility on the DOCSIS modem or something that can log ARP ?

harbor235 ;}
0
 

Author Comment

by:lineonecorp
ID: 36834980
Thanks for the detail.  ARP goes out of Sonicwall - we can see that.  We don't control the DOCSIS modem but I'm assuming that the ISP does and could and has been logging ARP.  I will bring it up with them though just in case. One additional note - it can be that out of 5 IP's associated with a Sonicwall 2 go off the air and can't be re-programmed without starting the whole firewall programming from scratch - however the other 3 IP's will still be responding. This is very typical on all the SonicWalls - all can be pinged after reprogramming, then 1 or 2 drop off - can't be reached but others stay up. Very irritating.  We have recommended that the ISP just delete our account and start again - it sounds like a bug in their programming for our site.
0
 

Author Comment

by:lineonecorp
ID: 36974039
Some additional info. The ISP is now saying that the Sonicwall doesn't fully complete ARP negotiation, yet per Sonicwall's specs it complies with the relevant RFC. Is it likely that SonicWall wouldn't do ARP negotiation properly - it seems it's a pretty essential part of being a router and I find it hard to believe Sonicwall would have problems in this area.
0
 

Accepted Solution

by:
lineonecorp earned 0 total points
ID: 37092947
0
 

Author Closing Comment

by:lineonecorp
ID: 37205927
Answer was found independently and worked.
0
 

Expert Comment

by:efx-wpg
ID: 38710374
Hello lineonecorp.

I'm having the same issue but with a checkpoint firewall (runs a hardended version of linux).

I was able to do a tcpdump on the interface from checkpoint and I can see the ARP requests going out but never getting replied to.

Was was the final solution to this?

Thanks,
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I found an issue or “bug” in the SonicOS platform (the firmware controlling SonicWALL security appliances) that has to do with renaming Default Service Objects, which then causes a portion of the system to become uncontrollable and unstable. BACK…
Getting hacked is no longer a matter or "if you get hacked" — the 2016 cyber threat landscape is now titled "when you get hacked." When it happens — will you be proactive, or reactive?
There's a multitude of different network monitoring solutions out there, and you're probably wondering what makes NetCrunch so special. It's completely agentless, but does let you create an agent, if you desire. It offers powerful scalability …
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
Suggested Courses

630 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question