50% packet loss after cable modem upgrade???
All Replies
-
Just disable ping check on interface and routing rules
0 -
Sorry - confused what a ping check from the WAN interface would do or cause in relation to this? I mean we have the connectivity check enabled since we have LTE backup on WAN2. But we've disconnected the LTE backup since they've throttled us now. Disabling the Connetivity Check on WAN1 doesn't do anything in terms of the cycling packet loss.
0 -
I just need you to disable all ping checks to see if what I think is the problem.
The problem I'm thinking is ping check sends a broadcast ARP to the gateway for each ping normally the WAN interface without a ping check sends one broadcast ARP then unicast ARP but what if the Zywall sending many broadcast ARP is causing the problem.
0 -
Gotcha. We switched to the TCP connectivity check instead of ICMP on WAN1, no change. Also had Proxy ARP disabled on the WAN side as well.
0 -
No for testing disable all of it.
0 -
We did. Didn't matter.
0 -
…hmm ok maybe do a packet capture on WAN to see if ARP is working correctly.
0 -
That's tonight's task. Been on phone with ISP for hours because, of course, since we can't reproduce with a single laptop connected to their modem - not their problem even though the packet loss clearly starts at their x.x.x.1 gateway. Trying to get them to understand that there's clearly some 'trigger' 5-30 minutes after we reset the WAN link and our business traffic clearly is the trigger. So a singel laptop may never trigger it, but our business clearly does. Will keep you all posted!
1 -
Hi @itxnc,
When the issue occurs, can you check the gateway's ARP by using the CLI command 'show arp-table'?
Assuming you can see the gateway's MAC address in the ATP ARP table, please open three terminal sessions in ATP. The first session is for pinging the WAN1 gateway, the second is for pinging 8.8.8.8, and the third is used to capture packets on the WAN1 interface in order to observe the ATP200 receiving an ICMP response from the uplink router1st terminal: Router> ping x.x.x.x forever interface wan1
2nd terminal: Router> ping 8.8.8.8 forever interface wan1
3rd terminal: Router> packet-trace interface wan1 ip-proto icmp0 -
We will definitely do this. It's possible this was a weird provisioning or headnode issue. After a 2 hour call with the ISP apparently they saw some issues with the headnode metrics/signals so they're sending a tech out to check things on the 'other end' So right now the connection is stable for the first time in days, but once VoIP traffic kicks up, we'll see how it goes and we'll post updates.
0
Guru Member
Ally Member
Zyxel Employee
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 144 Nebula Ideas
- 94 Nebula Status and Incidents
- 5.6K Security
- 237 USG FLEX H Series
- 267 Security Ideas
- 1.4K Switch
- 71 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.3K Consumer Product
- 247 Service & License
- 384 News and Release
- 83 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.2K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 83 About Community
- 71 Security Highlight
