Category: ARP

The new catalyst 3850s are great! They have a ton of features that come in handy. I recently ran into a bit of a conundrum though. The 3850 was bouncing back my ARP requests from the nexus management interface with the 3850’s MAC address. The nexus management interfaces were on the same subnet in the same vlan, that didn’t even span multiple switches.

I’ve changed the IP addresses to protect the innocent. The packets are out of order, just because it was near impossible to collect amount of packets necessary to make it look nice. This is plenty though. The originator is the owner of the eb:81 MAC. So why is the ARP packet coming back to me with the MAC of the 3850(52:99). Turns out it’s a little feature that Cisco has implemented and is very poorly documented as of 09/2013. Here is the response from TAC –

“Please add the following configuration on the interfaces connected to the Nexus switches: ‘nmsp attach suppress’.

IP Device Tracking (IPDT) is globally enabled by default on the 3850. It can only be disabled on a per-interface level. The 3850 uses a feature called Network Mobility Service Protocol (NMSP) which in turn uses IPDT. The cause of the ARP errors is caused by IP Device Tracking.  We’ll want to disable NMSP to prevent the 3850 from sending these packets.

Once the configuration is added, please let me know if the Nexus switch still sees these ARP packets.”

Documentation –

Source 1

Source 2

Problem: Unable to connect to a host connected to the wireless network on the same subnet but different segments (e.g. switchport or access point.)

 

If the host on the wireless segment originates the ping, the ping will be successful.

But if another host on the different segment originates the ping, the ping will most likely fail. In my environment, sometimes it worked and sometimes it didn’t.

 

#########

Windows Ping results –

C:\Users\network-haven>ping 10.0.0.1

Pinging wireless-user [10.0.0.1] with 32 bytes of data:

Reply from 10.0.0.2: Destination host unreachable.
Reply from 10.0.0.2: Destination host unreachable.
Reply from 10.0.0.2: Destination host unreachable.
Reply from 10.0.0.2: Destination host unreachable.

Ping statistics for 10.0.0.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

#########

Depending on the order of operations, you will not see the ARP entry for the respective IP addresses on the respective hosts. If you try to ping from the wireless host first, the entries will most likely show up.

This is partly due to bridging being enabled. Essentially, bridge groups will restrict broadcasts and multicasts. ARP works off of broadcasts. It appears that the access point shouldn’t allow broadcasts through at all.
Sources: Bridge Group Configuration

How ARP Works

 

Yet, everything points to the contrary on the network. It looks like you should be able to reach the host on the wireless segment. The switches show the proper layer 2 addresses. The access point doesn’t show the hosts dropping off. You can ping and connect to the host from a different subnet (e.g. 10.0.1.1 /24).

Solution: Enable ARP caching. The access point will reply to ARP requests on behalf of the host.

#########

Command: AP(config)#dot11 arp-cache optional

#########
Source: Configure ARP Caching

NOTE: I am running Version 12.4(25d)JA

CAUTION: DO NOT ENABLE THIS ON BRIDGED ACCESS POINTS; ARP REQUESTS WILL FAIL.