Reply
Highlighted
Accepted Solution

More on WAPI/DIW

[ Edited ]
Authority
Posts: 42
5113     0

So I've been progressing through my migration on a test grid, and I've gotten to the point where I create ranges.

These ranges exist in the ISC DHCO servers, and I am tasked with propagating them over to Infoblox.

 

Frm some of my previous questions, you may recall that the dhcpd.conf files have a general lack of consistency, which has made coding the migration a lot of fun.

 

As an example, I have this little snippet:

 

   

subnet 10.111.32.0 netmask 255.255.224.0 {
  option routers 10.111.32.1;
  option subnet-mask 255.255.224.0;
  option broadcast-address 10.111.63.255;
  boot-unknown-clients true;
:
  pool {
    deny dynamic bootp clients;
    allow unknown clients;
    allow known clients;
    default-lease-time 86400;
    max-lease-time 86400;

    range 10.111.1.5 10.111.1.250;
    range 10.111.3.5 10.111.3.250;
    range 10.111.5.5 10.111.5.250;
    range 10.111.7.5 10.111.7.250;
    range 10.111.9.5 10.111.9.250;
    range 10.111.11.5 10.111.11.250;
    range 10.111.13.5 10.111.13.250;

This continues all the way through 10.111.31.250.

A couple of interesting points.  First, if I run the DIW tool, it imports the subnet and the ranges.

The standard DHCP options assigned to the subnet are created.

I have absolutely no errors, and also no verification that the boot-unknown-clients true clause or any of the pool apply/deny clauses are applied.

 

Infoblox doesn't appear to recognize the concept of a pool, so it looks like it is ignoring the  allow/deny clauses.  The default-lease-time clause is applied to each range, however.  I don't care about the max-lease-time.

 

If I rewrite the file a bit, a la:

subnet 10.111.0.0 netmask 255.255.224.0 {
  option routers 10.111.0.1;
  option subnet-mask 255.255.224.0;
  option broadcast-address 10.111.31.255;
  boot-unknown-clients true;
  ddns-updates on;

  pool {
    range 10.111.1.5 10.111.31.250;
    deny dynamic bootp clients;
    allow unknown clients;
    allow known clients;
    default-lease-time 86400;
    max-lease-time 86400;

I get the same result.  Range is created, lease time is applied to the range.  The allow/deny clauses are not apparent.

 

If I delete the pool wrapper, it applies the lease time to the subnet, and still no client clauses.  The logs have no entries pointing tio any potential issues.

 

If I move on to the WAPI, and attemot to build it via python, I can use this:

 

def apiMakeNet():
    options = []
    template = 'Wired'
    data1 = {'options': [{'value': '10.111.0.1', 'num': 3}, {'value': '255.255.224.0', 'num': 1}, {'value': '10.111.31.255', 'num': 28}],\
     'template': 'Wireless', 'comment': 'test wireless', 'network': '10.111.0.0/19'} 
    i = InfobloxAPI(type='test',verbose=True,object='network',method='POST')
    i.data = data1
    i.username = un
    i.password = pw
    r=i.run()
    return r.text
    
def apiMakeRange(start,end,comment,bootp,known,unknown,net):
data={'start_addr':start,
'end_addr':end,
'comment': comment,
'deny_bootp': bootp,
'known_clients': known,
'use_known_clients': True,
'use_unknown_clients': True,
'unknown_clients':unknown,
'network': net,
# 'options': [{options}]
}

i = InfobloxAPI(type='test',verbose=True,object='range',method='POST')
i.data = data
i.username = un
i.password = pw
r = i.run()
return r.text apiMakeNet() apiMakeRange('10.111.1.5','10.111.31.250','test range create',True,"Allow","Allow",'10.111.0.0/19')

ran url https://w92-ibtest-1.mit.edu/wapi/v1.7/network
'"network/ZG5zLm5ldHdvcmskMTAuMTExLjAuMC8xOS8w:10.111.0.0/19/default"'
ran url https://w92-ibtest-1.mit.edu/wapi/v1.7/range
'"range/ZG5zLmRoY3BfcmFuZ2UkMTAuMTExLjEuNS8xMC4xMTEuMzEuMjUwLy8vMC8:10.111.1.5/10.111.31.250/default"'

This works at creating the range, but the GUI does not appear to be able to show that the client options exist or are applied.

 

Is this something I am doing incorrectly, or is it something that Infoblox is incapable of doing?  The WAPI documentation on ranges appears to support this.  I'm using 7.1.0 of the DIW, and v1.7 of the WAPI on v6.12.

Re: More on WAPI/DIW

GHorne Community Manager
Community Manager
Posts: 254
5114     0

The big question is "what are you trying to do?" What parts of the conf are you trying to get migrated that the DIW is dropping ?

 

The DIW is probably the best bet for an ISC file, but yes some configs are simply ignored because they don't apply in the grid (e.g. max-lease-time, deny dynamic bootp) 

 

The DIW does recognise the pool{} block, that's how the lease time got set on the range, and it should recognise the allow known/unknown lines. It probably dropped them because they are redundant. (your're allowing both known and unknown)

 

what you need to do is learn a bit more about using the DIW:

 - there is a log file, read through it, it will tell you what it did with file during parsing and importing

 - look at the page where all the DHCP options that it found in the file are listed. You can edit these and decide to keep them or move them from the pool to grid level etc

- look at the options on an individual range (right click on the range) you can also manually edit, remove, add things there.

 

Using the DIW as a blind import will never get you 100% of what you want, you are going to have to drive it a bit to tell it how you want the data to be processed

Re: More on WAPI/DIW

Authority
Posts: 42
5114     0

What I'm attempting to do is convert a bunch of ISC dhcpd.conf files to a single IB Grid.   Figure up to two class A networks being involved, and there is a great deal of variation in the ISC data.   The conversion should be virtually transparent to the users, in that if certain parameters are set on a subnet, range, etc. in ISC, the same parameters should be set in IB after the migration.

 

I've attempted to look at the log file, but it doesn't appear to any useful information in it.  It tells me that it imported the ranges, but once imported, there is no means of verifying that the non-standard fields

 

My preference is not not user the DIW at all, as I'm writing code for the WAPI to handle all this.  That being said,

I'm attempting to set fields that are not visible via the GUI, and I haven't yet figured out how to display or verify that it either did what I wanted it to do, or generated an error.

 

So here is an example:  First, a snippet from a dhcpd.conf file:

class "pxe-clients" {
match if substring (option vendor-class-identifier, 0, 3) = "PXE";
filename "kickstart";
option vendor-class-identifier "PXEClient";
boot-unknown-clients true;
}


shared-network 18.95.0.0 { subnet 18.95.0.0 netmask 255.255.0.0 { option routers 18.95.0.1; option subnet-mask 255.255.0.0; option broadcast-address 18.95.255.255; } subnet 18.2.95.0 netmask 255.255.255.0 { option routers 18.2.95.1; option subnet-mask 255.255.255.0; option broadcast-address 18.2.95.255; option domain-name-servers 10.72.0.47; default-lease-time 120; max-lease-time 120; boot-unknown-clients true; } pool { range 18.95.7.1 18.95.7.250; allow members of "pxe-clients"; allow known clients; } pool { range 18.2.95.65 18.2.95.250; deny members of "pxe-clients"; deny dynamic bootp clients; allow unknown clients; } }

The lines in green are successfully imported into the grid as objects or data associated with objects.  The lines in red appear to be completely ignored, or if they are operated upon, I have no means of verifying that they are in place.  There is noting in the DIW logs, nor in the DIW GUI, or in the Infoblox GUI to indicate that any of it is retained.  The crossed out lines I don't care about, and they also appear to be ignored.

 

 

Re: More on WAPI/DIW

Authority
Posts: 42
5114     0

I'm making a bit more progress on this, and thought I'd attempt to document said progress.

 

Imagine if you will, this following ISC dhcpd.conf snippet:

 

shared-network 18.7.10.0 {
  subnet 18.7.10.0 netmask 255.255.255.0 {
    option routers 18.7.10.1;
    option subnet-mask 255.255.255.0;
    option broadcast-address 18.7.10.255;
  }
  subnet 10.7.10.0 netmask 255.255.255.0 {
    option routers 10.7.10.1;
    option subnet-mask 255.255.255.0;
    option broadcast-address 10.7.10.255;
    option domain-name-servers 10.72.0.47;
    default-lease-time 120;
    max-lease-time 120;
    boot-unknown-clients true;
  }
  pool {
    range 18.7.10.250 18.7.10.254;
    default-lease-time 300;
    max-lease-time 3600;
    allow members of "pxe-clients";
    allow members of "solaris9";
    allow known clients;
  }
  pool {
    range 10.7.10.65 10.7.10.250;
    deny members of "pxe-clients";
    deny dynamic bootp clients;
    deny members of "solaris9";
    allow unknown clients;
  }
}

The items in green appear to work in the DIW and also with python code I've written expressly for this  migration.  The objects in red, however are a little more problematic.

 

    allow unknown clients;
    deny unknown clients;
    allow known clients;
    deny known clients;

    allow dynamic bootp clients;
    deny dynamic bootp clients;

    boot-unknown-clients true;

    allow members of "AAA";
    deny members of "AAA";
    allow members of "BBB";
    deny members of "BBB";

The allow/deny known/unknown clients statements apppear to be handled with the following data applied to a range via the WAPI:

"known-clients": "Allow" OR  "known-clients": "Deny"
AND use-known-clients": True

"unknown-clients": "Allow" OR  "unknown-clients": "Deny"
AND use-unknown-clients": True

The allow/deny dynamic bootp statments appear to be a slight variation in the WAPI, as deny_bootp is a true binary variable, so instead of Allow/Deny, we have to go with True/False.  So, we appear to have this as a solution:

 

To deny bootp clients:

"deny_bootp": True
AND use_deny_bootp": True

To allow bootp clients:

"deny_bootp": False
AND "use_deny_bootp": True

I've not verified any of this yet, so stay tuned.

 

Moving on to the members of statements, I see in the DIW that it does actually create the filters, and where one could add Class Filter Lists to a range, along with Allow/Deny Rules, but this appears to need to be done manually for each range.  SInce I have literally thousands of ranges, this is not preferable.

 

Perhaps they are Logic Filters. Not really sure.  The DIW has a lot of explanation, but the explanation doesn' appear to go this deep.

 

In digging around in the WAPI documentation, there appears to be something called option_filter_rules that I'll have to look at more closely.  This option appears to be similar to the options field for the subnet object, using the filter rule struct.

 

Where in the subnet object I might have this to decribe the DHCP options:

    data = {'options': [{'value': '10.242.0.1', 'num': 3}, {'value': '255.255.0.0', 'num': 1}, {'value': '10.242.255.255', 'num': 28}], \
            'template': 'Wired', 'comment': 'BR549 (Building BR549 Network)', 'network': '10.242.0.0/16'}

It appears that I might be able to get away with:

    data = {'option_filter_rules': [{'filter': 'pxe-clients', 'permission: 'Allow'}, {'filter': 'solaris9', 'permission': 'Deny'}] 

on a creating or updating a range object that uses a different option set.

 

I do not see any examples of actually engaging these optional filters via the WAPI, and I can't believe I'm the first person attemoting such a migration.  I'll know more once I get some of this coded.

Re: More on WAPI/DIW

Authority
Posts: 42
5114     0

I've coded the program as I described, and I'm happy to say that it works as I hoped it would.

 

In the big picture, I'm kind of surprised that all of these types of fields cand be set and manipulated w/o being able to to actually view the results w/o the use of an API.  Kind of makes the GUI useless for anything except the simplest of operations.

 

When I clean up my code I'll post some of the important parts.

Re: More on WAPI/DIW

GHorne Community Manager
Community Manager
Posts: 254
5114     0

Go to DHCP->members->{select a member} -> View DHCP configuration.

 

That should show you what you are looking for.

 

But, you can't enable ALL the features of ISC in infoblox, we just don't let you, and some others are abstracted away in places that make more sense. 

 

A lot of what you want to do is better done with 'filters' that you then apply to a range. there is no direct ISC concept of this unless you use a macro pre-processor to build your conf file. (which is essentially what NIOS is doing)

 

Read the admin guide on both 'dhcp option filters' and 'vendor classes'

 

And yes, the DIW isn't great for processing filters, but you CAN do this quickly and easily with a CSV import (often better than futzing with an API script)

 

lastly the DEFAULT behaviour of a range is to allow ALL clients, so:

   'boot-unknown-clients true' is redundant (you can only DENY bootp)

   'allow known-clients' is logically the same as 'deny unknown clients'

 

   'allow unknown-clients' is redundant unless you are overriding a deny from a higher level

 

 

Re: More on WAPI/DIW

rstoutjesdijk
Techie
Posts: 1
5114     0

Hi Fitzie,

i'm having the same challenge as you did.

Looking for the class object and making use of that class with the rule allo members of....

 

Did you cleanup your code? and can you share it with us?

 

 

thx in advance

Showing results for 
Search instead for 
Do you mean 

Recommended for You