Error message "Discovery member is not a discovery polling node" when trying to enable discovery

[#1]

Hello,

I am struggling with a weird problem and hoping someone can provide some inspiration!

My NIOS 8.1.1 system has two network views, Network Insight is currently set up to discover several hundred networks in one of the network views (lets call it view "A").

The same networks are present in view "B" (don't ask, it's a long story). I now want to switch from discovering in view A to view B.

So firstly I have successfully used the API to disable discovery on all the relevant networks in view A, and I have modified the grid member discovery settings so that it is now syncronising with view B and all the seed routers are in view B (it wouldn't let me do this until all networks in view A had discovery disabled, so I know this bit works).

Now I have another script to re-enable discovery for all those networks, but in view B. However, I get the following error message each time I make the API call...

"Discovery member is not a discovery polling node"

Yet I can go into a network in the GUI in view B and manually enable it and it all works fine. I am using the FQDN of the discovery grid member, here's the snippet of code:

.
.
.
$network->enable_discovery("true");
$network->discovery_member("coeng-dc-m37-dd02.company.com"); # Hardcode the discovery member

my $response = $session->modify($network); # Write it back to Infoblox

if ($response) {
  print "Discovery enabled on $type: $network_id successfully\n";
} else {
  print "Error enabling discovery for $type: $network_id: ".$session->status_detail()."\n";
}

coeng-dc-m37-dd02.company.com is the name of the discovery member as it appears in the grid, and I can assign this node manually to a network if I do it through the GUI, so why isn't the API letting me do it?

I'm sure I'm missing something and just need an extra pair of eyes on this!

Cheers,

Paul

[#2]

Paul, the parts you're posting look good.  I came across the same error you did, when I didn't filter networks to just the appropriate view.  I suspect you might be trying to modify all networks?   So I added a filter with the search, so that it only returns & modifies networks in the appropriate view.

First I ran it on the old view to disable the discovery with "false" and remove discovery member with "".

Then I changed the Network Insight appliance's view.

Then I ran it agan on the new view to enable discovery in the new view and add the discover member back again.

Best,

Matt

#!/usr/bin/perl

use Infoblox;
use strict;

my $host_ip   = "10.20.30.40";
my $networkview   = "default";
my $ni_member = "discovery.example.org";
my $enable = "true";

my $session = Infoblox::Session->new(
     master   => $host_ip,
     username => "admin",
     password => "infoblox"
     );
 		   		
unless ($session->status_code() == 0) {
	die ("Error ", Infoblox::status_code() . ": " . Infoblox::status_detail());
}

my @retrieved_objs = $session->get(
	object => "Infoblox::DHCP::Network",
	network_view => "$networkview");

my $exit_status;
if ($session->status_code()) {
    $exit_status = sprintf("[%d] %s\n", $session->status_code(), $session->status_detail());
    print $exit_status;
    exit 255;
}

foreach my $network ( @retrieved_objs ) {
	my $view = $network ->network_view;
	printf "%s\n", $network ->network;
	printf "  net view:        %s\n", $view->name;
	printf "  discovery:        %s\n", $network ->enable_discovery;
    printf "  discovery member: %s\n", $network ->discovery_member;
}

foreach my $network ( @retrieved_objs ) {
	$network->enable_discovery("$enable");
	$network->discovery_member("$ni_member"); # Hardcode the discovery member
	my $response = $session->modify($network); # Write it back to Infoblox

	if ($response) {
	  print "Discovery enabled on " .$network->network." successfully\n";
	} else {
	  print "Error enabling discovery for " .$network->network.": ".$session->status_detail()."\n";
	}
}

foreach my $network ( @retrieved_objs ) {
	my $view = $network ->network_view;
	printf "%s\n", $network ->network;
	printf "  net view:        %s\n", $view->name;
	printf "  discovery:        %s\n", $network ->enable_discovery;
    printf "  discovery member: %s\n", $network ->discovery_member;
}

[#3]

Thanks for the reply, I'm still not sure what is going wrong, I'm probably doing something really dumb! I'll paste the whole script but will have to make a few edits for privacy reasons, you'll note I'm only looking at the first element in the results array, the print statements verify it is finding the correct network. The script reads in a CSV file containing a list of network containers and networks upon which to enable discovery and I am just doing this in the default view (I had problems specifying the view name, again the API barfed but as this is all happening in the default view I just left it blank in the end, maybe that is the root cause)...

#!/usr/bin/perl

# enable_discovery.pl
#
# Script to open the .disco CSV file produced by the merge_ipam.pl script, and enable discovery on the networks & containers in the default view

$ENV{PERL_NET_HTTPS_SSL_SOCKET_CLASS} = "Net::SSL";
$ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;

use strict;
use Text::CSV;
use Infoblox;

my $csv_input = $ARGV[0] or die "Please run as $0 <name of .disco CSV file>\n";
my $line_count = 1;
my $session = Infoblox::Session->new(
    master   => '192.168.1.2',
    username => 'admin',
    password => 'infoblox',
    timeout  => 600
);

if ($session->status_code()) {
    print "Failed to create Infoblox session: "
    . $session->status_code() . ":" . $session->status_detail();
    exit;
};

my $csv = Text::CSV->new({
        sep_char => ',',	# Set delimiter to "," - I think this is the default but no harm setting it anyway
        binary => 1,		# Treat as binary in case some fields have embedded <CR> inside them
        auto_diag => 1,		# Spits out an error if we find weird **bleep** we can't handle
#		eol => "\r\n"		# Make sure we set up the correct EOL termination (saves us having to do dos2unix and weird **bleep** like that)
		eol => "\n"			# Termination different since file was generated on Unix
});

my ($data, $fields, $network_id, $network, $type); # Define some global variables
my @result_array;

# Open the CSV disco file produced by the merge_ipam.pl script
open($data, '<:encoding(utf8)', $csv_input) or die "Could not open '$csv_input' $!\n";		# utf8 encoding required to handle some weird characters

print "Script is running, please wait...\n";

while ($fields = $csv->getline($data)) {
	$type = $fields->[0];

	if ( $type eq "networkcontainer") {	# Found a networkcontainer in the CSV
		$network_id = $fields->[1]."/".$fields->[2];
		@result_array = $session->get(
			object			=>	"Infoblox::DHCP::NetworkContainer",
			network			=>	$network_id	
		); # No view specified, we are going to use the "default" one
	} else { # All other entries in the disco file should be networks, but we are making an assumption here!
		$network_id = $fields->[1]."/".convert_mask_to_bits($fields->[2]); # Network definitions use dotted quads for mask so needs to be converted
		@result_array = $session->get(
			object			=>	"Infoblox::DHCP::Network",
			network			=>	$network_id
		); # No view specified, we are going to use the "default" one
	}
	
	$network = $result_array[0];
	unless ($network) {
		print "Cound not find $type: $network_id: ".$session->status_detail()."\n";
	} else {
		print "Found $type: ".$network->{'network'}."\n";
		$network->enable_discovery("true");
		$network->discovery_member("coeng-dc-m37-dd02.company.com");	# Hardcode the discovery member
#		$network->discovery_member($fields->[3]);	# Discovery member
			
		my $response = $session->modify($network);		# Write it back to Infoblox
				
		if ($response) {
			print "Discovery enabled on $type: $network_id successfully\n";
		} else {
			print "Error enabling discovery for $type: $network_id: ".$session->status_detail()."\n";
		}
	}
}

if (not $csv->eof) {
	$csv->error_diag();
}

close $data;
	
##############################################################################
# Usage         :   convert_mask_to_bits($subnet_mask)
# Purpose       :   Return the number of mask bits (0-32) from a dotted decimal mask 
# Returns       :   The number of bits in the mask
# Parameters    :   Dotted decimal mask
sub convert_mask_to_bits {
    my ($mask) = @_;

    # Define a hash of octet values to bits
    my %mask_lookup = (
        0   => 0,
        128 => 1,   192 => 2,   224 => 3,   240 => 4,
        248 => 5,   252 => 6,   254 => 7,   255 => 8,
    );

    # Split the mask into four octets
    my @octets = split(/\./, $mask);

    # Define the variable to store the bits
    my $bits = 0;

    # For each octet, add the appropriate bits
    foreach my $octet (@octets) {
        $bits += $mask_lookup{$octet};
    }

    return ( $bits ) ;
}

[#4]

The search you are performing for the network will return networks from all possible views, it's not limited to just the default view.  And then you're just taking the first response in an unordered list, so it won't be predictable which network from which view you are assigning the discovery member.

Here's what I would suggest:  Please get the view filter working for the search, so that you can be sure you are only returning networs from the expected view.  Exact case is important when specifying the view name.

Before attempting to change it, print out (for debugging purposes) the network contents, so you can be sure you're setting the proper network.  I like using Dataumper, it works nice for structured variables like Infoblox:HCP::Network objects.  for example, print Dumper($network) will display the whole network and all its attributes.

Best,

Matt

[#5]

Gah! Of course. I stupidly thought that not specifying the view meant it would only search the default view. I don't really know why I didn't set it, I had some other problems in another script updating objects in that view so probably got my knickers in a twist (British expression).

So as soon as I specified the view in my search it started working. I've recently started using Data:umper now too which is really handing for debugging stuff like this.

Thanks for your help, I think sometimes you look at something so hard you can't see it - an extra pair of eyes quite often helps. :-)

Cheers,

Paul