3448 ARP issue with Cox

[Anonymous]

Hello AdTran team,

I am supporting an AdTran 3448 as customer premise equipment for client using Cox business service as their ISP. Connectivity is intermittently lost and can only be re-established by calling Cox support to request that they clear their ARP cache. I have confirmed this cache is at their head-end, not in the modem itself; power cycling the modem and/or the router does not help.

This originally occurred with a CISCO DPC3010, and persists with a Motorola SB6180. I have disabled LLDP on eth 0/1 and toggled link negotiation settings as described in https://supportforums.adtran.com/thread/2021, to no avail.  The current router configuration is attached, what other information can I provide?

[Anonymous]

:

Thank you for asking this question in the support community, referencing other posts, and supplying the configuration! 

You have taken the correct steps by disabling LLDP on the port connected to the cable modem, and verifying that the speed/duplex between the ADTRAN and the cable modem match exactly.  However, there might be some additional configuration settings that might need to be modified.  It is extremely rare to have a bridging configuration to an ISP.  Do you know if the ISP specifically requested the ADTRAN unit be configured for bridging? There are three ports that are being bridged together.  Most likely, this application would be better suited if these three ports were all in the same VLAN (instead of being bridged together), or have only the Ethernet 0/1 port be the public port and create a DMZ (Configuring a DMZ in AOS) or port forwards (Configuring a Port Forward in AOS) for additional hosts that need access via a public address.  My recommendation would be to configure the unit in a routing design, which will be much more efficient for this application.  Please note, among other things, if you remain in the bridging configuration the unit is currently in, the QoS settings will never take affect and voice traffic most likely will suffer.

Also, it appears this is being used in a voice application.  Are their IP phones or an IP PBX behind the ADTRAN unit?  If so, the unit most likely will also need to be configured as a SIP Proxy.

Please, do not hesitate to reply to this post with any additional questions or information.  I will be happy to help in any way I can.

Levi

[Anonymous]

Levi,

Thank you for the reply. It appears that LLDP was still enabled the last time this connection dropped, so disabling it may have resolved the problem.

Is there a known issue regarding LLDP and Cox, or cable modems in general? We've not experienced this problem with other customers using cable modems, and I'd like to document this issue for our support staff. Any details you can provide will be appreciated.

The bridging configuration is not required by the ISP, it is part of our standard deployment to enable WAN failover on eth 0/1 & 0/2 and passthrough on switchports 7 & 8. This particular customer does not have a failover connection or passthrough devices, therefore some additional configuration is not present.

Would this bridging configuration result in more than one MAC being visible to the cable modem through eth 0/1?

Please explain how QoS is not in effect in this configuration. We deploy these routers specifically for voice quality management, so this is of critical concern to us.

There are SIP devices behind this router, and they are registering directly to our service. We intentionally do not use a SIP proxy; I believe our registration servers compensate for the NAT but don't know specifically how this is done. It does work though.

[voiptek]

"Since the ethernet interface is in a bridge-group, the QoS map will not work."

Can you elaborate Noor?

[Anonymous]

- Layer 3 QoS maps are assigned to the layer 3 interface of an AOS device (an interface that contains an IP address). Once you enable bridging and add the ethernet interface to the bridge-group, this interface no longer has layer 3 functionality. All interfaces that are included in the bridge-group are unable to do QoS.

Let us know if you have any further questions.

Thanks,

Noor

[voiptek]

Many thanks Noor.