New 6020 and 6030 cameras not being auto discovered via medianet

[Scott Donahue]

In the process of installing 248 new 6020 and 6030 HD IP cameras and during testing of setting up the switch for auto discovering it is not finding the cameras.  Only way to see it is if we manually change the VLAN of the port to the desired VLAN.

Following is the macro created on the switch that is not working.

macro auto device ip-camera ACCESS_VLAN=4

macro auto global processing.

When it doesn't discover a configuration it defaults to last resort.

Also in VSOM version 7.0, under Cameras / Discover New Cameras and entering one of our media servers and Cisco Systems, Inc. for camera make,  I get the following error message: Operation failed, discoverCameras job on MS "servername" is already in process.

Also under manually add camera and in the Models list, the Cisco HD IP Camera 6000 series is not listed.  Is there an update that I'm missing.

Thanks,

Scott

[Scott Donahue]

Rather than just editing or deleting my previous post I figured I would add a reply to how I was able to get it to work.

Part of the problem was the drivers in VSOM and each media server were out of date.  I downloaded the updated drivers and from the management console under the Administration tab, select Manage Drivers and then select dp_cisco and then upgrade driver.  This added the drivers for the new 6000 series camera so they could be seen on the system.

The Macro we were using for the switches wasn't correct.  See the Maco we used below as an example of what worked.  Once this macro was in place on the switch and the camera plugged in, VSOM immediately auto discovered the cameras and configuration was easy to add the cameras.

-----Begin Maco-----

macro auto execute IP-Camera builtin CISCO_IP_CAMERA_AUTO_SMARTPORT ACCESS_VLAN=4

!

macro auto trigger IP-Camera

profile Cisco-IP-Camera

macro auto global processing

-----End Macro------

Once you turn on auto macro on the global command you have to disable auto macro on the interfaces that does not require it or other devices will try to change vlans.

Example

-----Begin Maco-----

interface GigabitEthernet1/0/1

switchport access vlan 40

switchport mode access

switchport voice vlan 110

no macro auto processing

spanning-tree portfast

-----End Macro------

These interfaces picks up the config automatically for the camera.

interface GigabitEthernet1/0/4

switchport access vlan 4

switchport mode access

switchport block unicast

switchport port-security

srr-queue bandwidth share 1 30 35 5

priority-queue out

mls qos trust device ip-camera

mls qos trust dscp

macro description IP-Camera

auto qos video ip-camera

spanning-tree portfast

spanning-tree bpduguard enable

!

interface GigabitEthernet1/0/13

switchport access vlan 4

switchport mode access

switchport block unicast

switchport port-security

srr-queue bandwidth share 1 30 35 5

priority-queue out

mls qos trust device ip-camera

mls qos trust dscp

macro description IP-Camera

auto qos video ip-camera

spanning-tree portfast

spanning-tree bpduguard enable

[Scott Donahue]

Still having problems... eventhough this worked on my test switch in my office it is not working on the cameras installed at the location with the same macro setup on the switch.  The macro is working and assigns a IP Address to the cameras through DHCP and I can access the cameras directly and ping the cameras from the VSOM server... yet VSOM is not auto discovering the cameras.  We have also upgraded from 7.0 to 7.01 and the drivers for the 6020 and 6030 cameras are loaded.

[Cory Blackman]

bump!

[slaanoi]

Scott,

Looks like you may be mixing the two discovery methods (server-initiated and camera-initiated). If you would like to use camera-init (a.k.a medianet), are you passing the MS host IP in Option 125 in response to the DHCPINFORM message? If you would like to use server-init (via bonjour) are all your endpoints on the same subnet as the discovery MS and have bonjour enabled (if not 1.3.x firmware shipped)?

[Scott Donahue]

Slaanoi,

Would like to use teh camera-init (a.k.a. Medianet) discovery and have attempted to set Option 125 but even Cisco support was not able to get it to work with a Microsoft DHCP server.  Have you been able to get that working correctly using Option 125 and if so can you share the details of what you did to get it to work?

[slaanoi]

Presently, we've validated this process to work with IOS DHCP servers; MS DHCP servers in particular are not responding with the correct option value in the DHCPACK (option 43 instead of option 125). In the past we looked into a method of rewriting the packet but at the moment it's not supported.

[Scott Olsen]

I find it interesting that anyone has been able to get either discovery options to work.

Cisco TAC still cannot resolve the proper IOS configuration for option 125 on our ASA DHCP scope. (slaanoi, I'd love an example of the DHCP option command you have functioning in IOS).

Scott,

After *several weeks* of having an open TAC case with Cisco regarding even manual discovery of NIB cameras, it all came down to the fact that the *bonjour service* (mDNS) needs to be enabled on the cameras in order to be discovered by the Media Servers.

The rub?  On the version of firmware that was shipping on the cameras, bonjour was disabled by default. (yeahhhhhh....)

Give it a go with/without bonjour, and see if the discovery results change for you.

Best of luck everyone.

[slaanoi]

Scott,

Both discovery options actually do work, but there are some important notes to be aware of.

For server-initiated discovery, all IP cameras need to be on the same subnet as the server and have bonjour enabled via the web interface. 6000 series endpoints that ship with firmware release v1.3.2 and later (~late-July) have this service enabled by default, so endpoints can be discovered right away without the need to touch each device.

For camera-initiated discovery, the value carried in DHCP Option 125 needs to be constructed based on the following pattern: 0000.0009.0b14.0901.x.0050.0001, where the the variable x holds the IP address of the Media Server in hex. So if your server IP is 10.20.30.5, the value would be 0a14.1e05, a la:

option 125 hex 0000.0009.0b14.0901.0a14.1e05.0050.0001

You can adapt for the ASA (dhcpd option 125 hex).

To further automate the configuration of discovered endpoints, it's important to configure autoprovisioning settings in VSOM _prior_ to initiating the discovery (server-init) or plugging in the devices to the network (camera-init), particularly if the camera is still in factory-default status.

This will allow setting a new password automatically to discovered endpoints from the one-time password, thus negating the need to manually initialize each. You can also apply a template and postpone the decision to distribute the endpoints across available media servers, thereby not enabling the endpoints just yet to prevent triggering device health alarms.

[Scott Olsen]

slaanoi,

Any additional information on what you mean by "adapt for the ASA"?  I just had a discussion with our Operations guy, and when I requested:

option 125 hex 0000.0009.0b14.0901.AC13.AB17.0050.0001

... he responded:

"

Regardless of what I type in, the firewall strips the dots:

000000090b140901ac13ab1700500001

"

If you are Cisco TAC, feel free to take a look at SR 626474623 if you wish.  We are kind of running out of options to test.

It should also be noted that, based strictly on the documentation provided via the VSOM User Guide section 7-34:

... users wouldn't be creating the proper syntax for an IOS DHCP Option 125 hex string?

Thanks!

[slaanoi]

Yes, by default IOS (at least the 12.2(33) and 15.0(1) trains) adds the dot-separators while ASA (at least 8.2.x) removes them. Primarily they make the TLV's slightly more human-readable. No spaces though - that will change the packet structure. I'll ask the team to correct that.

[Scott Olsen]

slaanoi,

Thanks again for this feedback regarding the IOS and  ASA versioning.  I'll continue to work with my TAC engineers, and will  confirm again in our own lab when I get the chance.  However, with  respect to the ASA, here's my concern...  We've tried a few different  strings now. Some with white spaces (first TAC recommendation), and  subsequent ones properly delimitted with dots on the 32bit word  boundaries (in constrast to the documentation, but matching your  confirmed working example above). 

If the ASA strips out both white spaces, and

the delimitting dots, have we not effectively tried the same string multiple times now?

[jeffreyhing]

Just want to share my experience. We got the microsoft DHCP server to work with Option 125. We used this http://sourceforge.net/projects/medianet/files/DHCPSD/ and followed the instructions. Then use this to create the service records for the registry http://sourceforge.net/projects/medianet/files/SDCAT/v_1_0_2/

After that, remove the option 125 from the microsoft dhcp server. The registry keys for option 125 will take over. To make all this work, make sure that the service record you create has the name "vsms". The registry should show vsms as the key with the value of AC13AB1700500001 where AC13AB17 is the hex value of the vsm server where the camera will connect.

I hope this helps

[Scott Olsen]

Thanks for reaching back to share this.  I certainly appreciate it.  We seem to be an almost non-existent community here.

Cheers

[Scott Donahue]

Has ANYONE been able to get the Auto discover to work with MS DHCP????  I'm now in the position of adding another 165 cameras and would be awesome if I could see an example of exactly how anyone else has been able to get this working.  Pretty disappointing that for something so simple as having a medianet enable CISCO camera and CISCO switches that the CISCO VSOM is not able to auto discover them like they do with Access points and phones.