management card ap9617 can not web into using DNS

[BillP]

Because of some changes made within our network our IT department wants us  to switch all our static IP management cards to dhcp and have us web into them using the domain name.

On my end I switched one of the units we have to dhcp and it has an new Ip but when we type in the name we just get a google search window that pops up and not the web interface of the unit.

According to our IT department they have their stuff set up. 

Thoughts

Thanks

Kevin

[BillP]

Hi Kevin,

What did they set up? Can they clarify what they have in place when they claim it is fine on their end?

I think it'd also be helpful if you can provide the config.ini file (available via FTP download) or screenshots of the DNS server/naming sections in the web interface to make sure it is configured properly.

You could also try some DNS tests that the management cards support and see if they can return responses for DNS queries themselves using the DNS servers configured. And should I assume the management cards use the same DNS servers your computer does? And if you're computer is not on the same domain as the management card, you'll need to make sure you're typing the FQDN in your URL address bar so I was wondering specifically if you can give an example of what you type in your address bar.

Did this ever work previously on static IP? 

[Anonymous user]

We have DHCP setup.  We would like the devices to register using Dynamic DNS.  The mgmt card would use the same DNS server as his computer.  It did work previously on static IP's, but we were connecting to the actual IP address, not the DNS name.

Basically, we want the Management card to pull a DHCP address, which it does.  We want it to register its DNS name, which it doesn't do.  Typically this is done when it gets a DHCP IP address, but the devices aren't sending a name.

[BillP]

Hi Ben,

Thanks for clarifying. Is that DHCP option 11 you're referring to? Or 81? I don't think the older NMC AP9617 supports this but our newer NMC2 AP9630/31/35 cards do..

More detail here on what we support for DHCP options -> http://www.schneider-electric.us/support/index?page=content&country=US〈=en&locale=en_US&id=FA156110 

[Anonymous user]

It looks like it's option 12:

• Host Name - (option 12) - NMC2 only - AOS 5.1.5 and above - This option specifies the name of the client.

[BillP]

Oh, sorry. Typo on my part! Yes, I meant 12. Option 12 and 81 are only supported by the newer AP9630/31/35 cards (or anything embedded with a mini version) as I noted.

[Anonymous user]

So it looks like we have a large quantity of AP9630 cards which aren't working in our environment.  

We have Dynamic ARP Inspection (DAI) enabled on our switches.  Essentially what this does is maps the mac address to the ip address during DHCP registration.  It looks like (even after rebooting the card) the card attempts to use the same DHCP address instead of asking for a DHCP address.  This causes DAI to block the port, since it has no record of the device utilizing this address.  This should cause the AP9630 card to try and obtain a new address, which it hasn't yet (I've waited about 15 minutes).

I've set the card back to a static IP address.  Rebooted the card.  Put a DAI Exception into our switch. Connected to the static address.  Set the card back to DHCP. Remove the DAI exception. Rebooted the card. and the card tries to get the same IP address it first got a long time ago (weeks)

Any suggestions?

Thanks for your help!

[BillP]

Hi Ben,

Is this similar to what is discussed here -> http://forums.apc.com/spaces/7/ups-management-devices-powerchute-software/forums/general/10646/ap961... I do not have any experience with the DAI technology but my first thought was to do a packet capture - maybe you've already done that to do this investigation and share what you found? I can probably check into DHCP behavior to better understand but do you have a reference for us to better understand DAI for your specific switch model if need be?

I thought for the most part in DHCP, it is normal for any device to have an IP, the lease is up, and it'd ask for the previously used IP to see if it is available and if so, take it. If it is not available, then it requests a new address from the server. 

On 11/9/2015 11:15 AM, Ben said:

 It looks like (even after rebooting the card) the card attempts to use the same DHCP address instead of asking for a DHCP address.  This causes DAI to block the port, since it has no record of the device utilizing this address.

Based on the above comment, this sounds normal? It tries the same DHCP address it had, wouldn't the server say it is or is not available anymore, give the NMC an address, and then with that new registration, map the new IP to the port for DAI? Have I misunderstood or am I incorrect?

[Anonymous user]

It's somewhat similar to the link you provided.  The port doesn't see 2 mac addresses though.  It only sees the one mac address on the port.

The actual Error in the log is "Nov  9 12:27:05: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/2, vlan 153.([00c0.b798.e3b3/10.150.3.49/0000.0000.0000/10.150.3.254/12:27:05 CST Mon Nov 9 2015])"

I believe the device should communicate with the DHCP server, and if the DHCP server has a lease for them, and they just reuse the same lease.  This communication is picked up by DAI, and put into a DHCP Snoop bindings table if it works correctly (which it doesn't show in).  IF they don't have a lease for them, they obtain a new IP address for the specified lease duration, and this is put into the DHCP Snoop bindings table.  I believe the issue is that the UPS is attempting to communicate on the IP address it initially received without renewing through the DHCP server correctly (or at least in a manner that the Cisco Switch can recognize).

I'm sort of stuck.  These are the only devices running DHCP that this is happening to, and we have lots of devices on network.  I really appreciate your responses.

Even if I switch to static, reboot, and go back to dhcp, it will still try to communicate on the last known dhcp address.  It appears to try and communicate on this address without communicating with the DHCP server (I'm assuming here, as I have not taken packet captures, all I see is the above error file in the log of the switch).

[BillP]

Hi Ben,

I will see if I can look at it further tomorrow and talk to one of the developers. In the meantime, can you tell me the model of switch you're using? I'll have that in case we need to look it up and understand DAI better or see if there is detailed technical info available out there.

Also, can you confirm what AOS version is on your AP9630s you're using that see the issue? Do the AP9617's work with this feature OK? (That can give us some comparison info maybe.)

I hope we can figure it out or at least understand what the problem is and see if there is anything we can do about it. I have a feeling though we will somehow need to do a packet capture at some point if you're able to mirror the AP9630's switch port and see what is going on there when the error log message pops up.

[Anonymous user]

You bet.  The switch we're using is a  Cisco WS-C2960S-48LPS-L, but the issue occurs on any Cisco switch where we have DAI enabled.  Here's the configuration we're using to enable DAI:

ip dhcp snooping vlan 151
no ip dhcp snooping information option
ip dhcp snooping
ip arp inspection vlan 151
ip arp inspection log-buffer entries 1024
ip arp inspection log-buffer logs 1024 interval 10

int range g1/0/25-28
ip dhcp snooping trust
ip arp inspection trust

The Model number we're working on is an AP9630 Hardware Revision 05

AOS V5.1.7

I'm not sure if/where we may have any AP9617's, but I'll ask around.

Thanks!

[BillP]

Hi Ben,

v5.1.7 is several years old now. Would you be willing to upgrade one of your devices for testing to one of our newer v6.X firmwares? I would call it a "major" upgrade as the web UI and many other aspects are different (but better). I think this would be a good test to see if it reacts differently.

I can go over with you in more detail the differences if you're willing to try and then give you a "beta" of our latest firmware coming out within a month or two.

Let me know what you think and I'll get you the file privately for review and upgrade. You can go back to v5.1.7 later if you prefer. Thanks for that info you provided already on the configuration.

[Anonymous user]

Sounds great Angela!

Just let me know the install procedures, and I'll test it out.

[BillP]

Sent you a private message. 

[Anonymous user]

So, I've put on the new firmware. And took the following steps:

Turned off DAI on the switch

Installed the firmware

rebooted

set the device to a static IP address

rebooted the device

deleted the dhcp lease from the server, and excluded the IP address the device previously had from being handed out by dhcp

set the device to dhcp

rebooted the device, and at the same time enabled DAI again

I can now see that it received a new IP address from DHCP, but DAI is blocking the port again.

[BillP]

Hi Ben,

I am not sure what to do next if we can't find out on what basis DAI is blocking the port. I am reading here (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/d...) and trying to figure out what process it is using and what causes DAI to block the port again.

I saw:

DAI uses the DHCP snooping binding database for the list of valid IP-to-MAC address bindings.

ARP ACLs take precedence over entries in the DHCP snooping binding database. The switch uses ACLs only if you configure them by using the ip arp inspection filter global configuration command. The switch first compares ARP packets to user-configured ARP ACLs. If the ARP ACL denies the ARP packet, the switch also denies the packet even if a valid binding exists in the database populated by DHCP snooping.

Is it possible there is an ARP ACL in place? Other than that, I'd be interested to see the packets going by on this port to understand what packet is triggering DAI to block the port. On the NMC side, I don't know what else to say or look at because it is getting a DHCP address and that is what it is supposed to do. I am not sure how it itself could be doing anything wrong unless it had a problem with its MAC address or had two MAC addresses on it (which it does not) like some servers do.

[Anonymous user]

We don't have any ARPACL's in place.  I did figure out something interesting.  If I manually put in the DHCP mapping through the command:

ip source binding 00c0.b7b2.b0cc vlan 152 10.150.2.82 interface Gi1/0/48

It showed up in the dhcp snoop binding table.  Also, any further DHCP renewals renewed the lease in the dhcp snoop binding table.  I think the initial conversation somehow isn't getting mapped properly, but all renewals are... which is interesting.  To be honest, we have just enabled DAI over the summer and are still learning about it.  We haven't encountered this specific issue with any other devices, so it's interesting to work on why this is happening.

I think for now, I'm going to try and put in the manual DHCP mapping, and then take them out to trigger DAI to get off its butt and work.  If I find out anything more, I'll add to the post.

[BillP · Accepted solution]

Yes, interesting. This may be helpful too for anyone else that is going to enable or has enabled this feature with the APC Management Cards.

Thanks for sharing the update and I'll be eager to hear if you learn anything new.