Problems with Internet Connectivity to an AOS Unit Behind a Third Party Modem

[#1]

Commonly when using broadband internet connections like Cable or Fiber, a third party modem will be deployed in front of an ADTRAN unit that converts the signal into Ethernet. This modem will primarily work at layer 2, meaning it will not interact past providing a connection between the AOS unit and the upstream gateway router of the ISP. The unit will also not be visible in any way in the mac table or ARP table of the ADTRAN unit.

In some cases, internet connectivity may be lost (or never have been established properly). In this case, a common troubleshooting step is to directly hook a PC into the modem and see if network connectivity restored. If this succeeds, generally this would mean that there must be a problem inside the ADTRAN unit. The following should be checked to make sure that the AOS unit is configured properly:

• Interface configuration
  • Interface up and active
  • IP address configuration correct
• Routing Configuration
  • Is the default route correct?
  • Does it show up properly in the route table?
• Firewall Configuration
  • Is the firewall properly configured for NAT and to allow any applicable public traffic?

If after verifying the above, it seems that the ADTRAN unit is configured and functioning properly, a common situation must be considered. Many times, third party layer 2 modems have security measures in them that lock down mac addresses to public IP addresses given out by the ISP to keep users from using more IP addresses than they are supposed to be allowed - especially in large public subnets that do not fully belong to the company. If a unit was plugged in before the AOS unit on the circuit, or if the AOS unit was plugged in for a while and then somehow lost connectivity from the modem for a period of time, the modem can lock down the mac address table in such a way that new mac addresses can not be associated with the public IP address. When this happens, the PC may continue to work if the modem has allowed its MAC address to transmit using that IP, but the AOS unit would not at all.

The easiest way to tell if this is happening is to log into the AOS unit's Command Line Interface (CLI). If you need help doing this, please see .

Once inside the CLI, enable the debug command debug arp so that you can see the ARP transmissions between the AOS unit and the modem. Once this is enabled, use the clear arp-cache command to clear out all ARP entries and cause the AOS unit to ARP for its gateway. This will look like the following:

#debug arp

2013.10.31 00:51:21 ARP.REQUEST Received request on eth 0/1: tell 10.10.100.4 who has 10.10.100.1

2013.10.31 00:51:35 ARP.RESPONSE Sent response on eth 0/1: telling 10.10.100.4 that 10.10.100.1 is at 00:A0:C8:00:E1:77

2013.10.31 00:51:47 ARP.REQUEST Sent request on eth 0/1: tell 10.10.100.1 who has 10.10.100.4

2013.10.31 00:51:58 ARP.REQUEST Received request on eth 0/1: tell 10.10.100.4 who has 10.10.100.1

2013.10.31 00:52:07 ARP.RESPONSE Sent response on eth 0/1: telling 10.10.100.4 that 10.10.100.1 is at 00:A0:C8:00:E1:77

2013.10.31 00:52:24 ARP.REQUEST Sent request on eth 0/1: tell 10.10.100.1 who has 10.10.100.4

2013.10.31 00:52:37 ARP.REQUEST Received request on eth 0/1: tell 10.10.100.4 who has 10.10.100.1

2013.10.31 00:52:52 ARP.RESPONSE Sent response on eth 0/1: telling 10.10.100.4 that 10.10.100.1 is at 00:A0:C8:00:E1:77

2013.10.31 00:53:09 ARP.REQUEST Sent request on eth 0/1: tell 10.10.100.1 who has 10.10.100.4

013.10.31 00:53:22 ARP.REQUEST Packet not enqueued on eth 0/1: Overall ARP Pkt Count Exceeded

013.10.31 00:53:44 ARP.REQUEST Packet not enqueued on eth 0/1: Overall ARP Pkt Count Exceeded

013.10.31 00:54:10 ARP.REQUEST Packet not enqueued on eth 0/1: Overall ARP Pkt Count Exceeded

013.10.31 00:54:22 ARP.REQUEST Packet not enqueued on eth 0/1: Overall ARP Pkt Count Exceeded

In the above example, 10.10.100.1 is the AOS unit's IP address on Ethernet 0/1. 10.10.100.4 is the gateway for the ISP's gateway router. The first message above represents the gateway router sending an ARP to find the MAC address of the unit that owns 10.10.100.1. The AOS unit immediately responds giving its MAC address. However, the same ARP is received again from the gateway and the ADTRAN unit continues to respond in the same manner. This indicates that the ARP response sent by the ADTRAN is being rejected.

Also, if you observe the 3rd message, you will see the ADTRAN sending an ARP to find the mac address for the gateway unit. If you scan the rest of the debug, there is no response, meaning the gateway unit is not responding. The final messages,"Packet not enqueued on eth 0/1" means that we have sent out enough responses that we are now dropping packets destined for the gateway because it cannot be resolved.

If either of these two symptoms above are seen, and especially if both are, the modem should be rebooted. If it does not resolve the issue, contact the ISP or company that manages the modem and show them the debug and ask for assistance to reset the MAC address table.