ARP requests not responded to by ISP

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.
lineonecorpAsked:
Who is Participating?
 
lineonecorpAuthor Commented:
0
 
Rick_O_ShayCommented:
Can you do a packet capture with Wireshark or Sniffer showing the ARPs going out to their router but no replies coming back?
0
 
harbor235Commented:

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
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
lineonecorpAuthor Commented:
Rick O Shay:

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

harbor235:


" hairpining gratuitous arps" - what exactly is this?
0
 
harbor235Commented:


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
 
lineonecorpAuthor Commented:
Just using a SonicWall NSA 2400 on this side of the Docsis.

What is the 'hairpin'?
0
 
harbor235Commented:


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
 
lineonecorpAuthor Commented:
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
 
lineonecorpAuthor Commented:
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
 
lineonecorpAuthor Commented:
Answer was found independently and worked.
0
 
efx-wpgCommented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.